Разработка через тестироваие для PHP программистов. Теория.

Сегодня я хочу поделиться подходом, который сделал работу над сложными PHP проектами проще, который дал мне больше свободы в написании моих программ, который спасает мои нервные клетки и делает жизнь веселее. Этот подход называется TDD, а говоря простым языком — разработка через тестирование. Об этом сказано немало, много копий было сломано в спорах, но тем не менее в среде php-разработчиков это до сих пор не стало частью процесса разработки. Я думаю основной причиной этого является специфика веб-приложений, ориентированных на интерфейсы, итеративная разработка по сценарию «пишу-смотрю-пишу-смотрю». Отдельная история это то что львиная доля разработчиков это «вебмастера», зачастую знающие о программировании «PHP за 24 часа», либо студенты с опытом написания лабораторных работ на С (эта категория настолько сурова, что даже книг не читает, именно им мы обязаны тысячам изобретенных велосипедов). С другой стороны, подкупаемые простотой написания приложений для веб и огромным спросом на них в PHP, в разработку подтянулись разработчики с опытом в Java, С, Delphi начав продвигать TDD (там юнит-тесты стали давно неотъемлемой практикой разработки). Так в чем же дело? Почему преимущества написания тестов на код не очевидны на столько, что бы все разработчики начали использовать их? Думаю всё дело в опыте. Именно с опытом приходит понимание преимуществ, которые дают ОПП, паттерны, а вместе с этим и использование TDD. Действительно, традиционный винегрет из HTML и PHP с трудом поддается тестированию и, как правило, попытки привести в порядок такой код выглядит больше не как рефакторинг, а как переписывание.

Мой путь к тестам лежал в первую очередь через осознание того что мой код хрупок. Это не так просто, как может показаться на первый взгляд, — дело в том что в программистах очень живуч миф о «совершенности» их кода. Действительно, каждый раз когда в коде находится баг, программист в первую очередь думает о том где ошибся тестировщик, а уж потом, ищет проблему в программе. Если же в вас живет скептик, критикующий производимый вами код, у вас появляется сильное желание «успокоить его», подписав логгирование, обработчики ошибок и постоянно тестируя всё что пишите. В какой-то момент, когда бизнес начинает требовать от вас радикального поворота в логике вашего приложения, и вы понимаете что для поддержания целостности приложения и уверенности в том что оно всё еще работает «как надо», вам нужно проделать такой же объём работы, который вы уже проделали, и вы понимаете — будь у вас под рукой что-то типа тестов, это спасло бы ваши выходные. То есть понимание необходимости в модульных тестах приходит именно через сложности в разработке больших и сложных приложений. Я не напрасно написал «больших и сложных», — именно так. Для простых это может показаться лишним, так как если у вас нет большого опыта работы с тестами, вы будите писать медленнее, но если опыт есть, то и для небольших проектов модульные тесты это хорошая практика, так как «большие и сложные» проекты часто вырастают из небольших, и поэтому если ваш небольшой проект спроектирован должным образом и покрыт тестами это будет отличной площадкой для развития проекта и наращивания функциональности. Если же проект большой и несложный, для веб-приложений, это как правило, большое количество пользовательских форм, простая логика сохранения и отображения информации модульное тестирование также не будет «спасательным кругом», безусловно, тесты на основные классы должны быть написаны, но главной составляющей качества вашего продукта будет скорее всего функциональное тестирование интерфейсов. А вот в случае «больших и сложных» проектов тесты, неотъемлемая составляющая проекта. В противном случае «вертолет» может «не взлететь».

Итак, вы стоите на пороге нового проекта, понимание важности тестов у вас есть, и вы хотите знать, как «сделать правильно». Теперь самое время уделить вашему пониманию ООП, и умению использовать паттерны проектирования. Для того чтобы систему было легко тестировать, легко изменять функциональность, без постоянного переписывания тестов систему нужно проектировать хорошо. Если у вас в команде есть архитектор или разработчик с большим опытом, то вам крупно повезло — на множество «граблей», присущих новичкам, вы не наступите. То есть «грабли» конечно же будут, но это будут уже более «высокоуровневые» просчеты в архитектуре, а не глупые ошибки. Вы будете постигать нюансы построения бизнес логики для более простого тестирования, будете открывать секреты построения красивых интерфейсов для своих классов, предоставляя максимум свободы внутри классов и позволяя кардинально менять логику классов без переписывания тестов. Вы будете учиться оптимизировать тесты и вплетать их в ваш процесс разработки и на этом пути никогда не будет скучно или неинтересно. Модульное тестирование это увлекательный процесс и я гарантирую что если вы пойдете по нему, он отблагодарит вас новым уровнем качества вашего кода и ваших приложений. Пробуйте, интегрируйте запуск тестов в свою IDE и расскажите мне о ваших успехах.

Comments

comments

1 comments On Разработка через тестироваие для PHP программистов. Теория.

Leave a reply:

Site Footer

Sliding Sidebar

About Me

About Me

Для кого этот блог?

Для тех кого интересуют современные интернет технологи, IT бизнес, стартапы, менеджмент, контроль качества, личная эффективность, мотивация. Здесь я буду писать о том, что в первую очередь будет интересно мне, о проблемах и решениях. О том что пригодилось мне, и возможно будет интересно Вам.

Что заставило меня создать его?

Желание совершенствоваться. Достигать успеха. Находить людей со схожими проблемами и задачами, вместе искать выходы и решения.

Немного о себе.

Мой первый серьезный опыт в IT это работа над desktop приложениями в компании «Эксперт-Софт». У истоков её стояли несколько амбициозных и талантливых молодых людей, с огнем в глазах и желанием работать «как майкрософт». То чем мы там занимались вполне могли бы сегодня назвать «стартапом». Рук было откровенно мало, поэтому приходилось заниматься всем: кодированием на Delphi, написанием скриптов на VBA, дизайном, вёрсткой и поддержкой вебсайта, работой над рекламной полиграфией, проектированием интерфейсов и БД. Работы было много, но запал был велик, команда очень разношерстная, гармонично дополняя друг-друга в решении нетривиальных задач. Благодаря тому что пришлось попробовать многое, постепенно вырисовалось понимание того чем хочется заниматься, и как. Софтверным программированием я был сыт по горло. Массы проблем десктопного софта в вебе просто не было, по определению. Зато был четкий фокус на дизайне, юзабилити, скорости. Поэтому когда пришла пора уходить из «Эксперт-Софт», я без всякого сожаления стал искать работу как разработчик для web. Поскольку городишко у нас не очень большой, выбор был практически предопределен. Так я стал работать в «Оникс-Системз», где и продолжаю работать поныне. За время работы в компании я как разработчик принимал участие в работе над несколькими десятками проектов. Несколько десятков проектов было сделано мною как фрилансером. Самым большим проектом в котором я сыграл роль менеджера, считаю свою семью. Также довольно большой проект мы сейчас поднимаем с командой разработчиков (на данный момент команда состоит из четырех php разработчиков, одного flex кодера и тестировщика). Отсюда, большой интерес к современным практикам и методологиям, разным подходам в управлении командой, повышению эффективности и качества работы. По мере сил, вдохновения и свободного времени, я буду писать об этом.

Если у Вас возникли какие-то вопросы ко мне лично, буду рад если Вы свяжетесь со мной:

e-mail:
skype: denis.sheremetov
Старый сайт, с музычкой и флешом

Прочая онлайновая деятельность: