В очередной раз, согласившись на фрилансерский заказ (а ведь обещал себе покончить с фрилансом раз и навсегда), я тяжело вздохнул, и при первой же возможности, сел изливать свои мысли на бумагу. Когда мы начинаем новый проект, часто у нас не хватает опыта сделать это правильно, иногда нам просто лень изучать новые технологии, но чаще всего, мы уверенны что и так все прекрасно спрограммируем, без всяких VCS, фрэймворков и миграций. Для тех, кто может найти в себе силы на что то большее, чем связка Denwer -> ftp client -> hosting, я набросал несколько рекомендаций, как можно сделать процесс разработки web-приложения немного более удобным.
Framework
«Начнём с элементарного», хотел я написать, и понял, что принимая уже начатые кем-то проекты, считанные разы встречал там фрэймворки. Толи мне не везёт с предшественниками, толи большинство программистов стараются фрэймворки не юзать. Слышал даже утверждение что: «Фрэймворки — для ламмеров, я все руками пишу». Я знаю, как минимум, две причины, из-за которых следует использовать фрэймворки:
- У вас есть каркас приложения, и куча библиотек, которые облегчают вам жизнь и экономят ваше время.
- Рано или поздно, в вашей команде появляется новый программист, который вольётся в проект гораздо быстрее, если уже знает как устроенно ваше приложение. В крайнем случае, он будет мучить не вас, а документацию фрэймворка, что, опять же, экономит ваше время.
Лично я всегда использую один из двух фрэймворков: Zend Framework или CodeIgniter, но это дело вкуса и личных предпочтений. По этим фрэймворкам: СI гораздо легче в смысле ресурсов, и проще в смысле изучения чем ZF, но ZF предоставляет куда больше возможностей. Если вы раньше не использовали фрэймворки, и понятия не имеете что такое MVC начните с CI.
Ну и небольшой бонус. Как вы знаете, самым главным минусом ZF являются его неслабые требования к ресурсам. Тяжеловат Zend, это правда. И тут, нашим китайским коллегам, пришло в голову написать Zend Framework на… Си! И они это сделали, называется Yaf, или Yet Another Framework. Написан Yaf на Cи, и подключается к апачу как модуль. Конечно пока он не содержит всего функционала ZF, да что там всего, половины не содержит, более того, есть документация на китайской, есть совсем немного документации на английском, нет документации на русском. Многие классы, правда, знакомы по ZF, но многие и отличаются, и тогда, либо изучать их методом тыка, либо копать исходники на Си. Надо признать, Yaf действительно быстр, хотя и заставляет понервничать в процессе разработки. В общем, советую, только если вам стало невыносимо скучно, и хочется… драйва чтоли.
Русская документация по CodeIgniter'у находится тут:
http://code-igniter.ru/
Ну и конечно, оригинальная на официальном сайте:
http://codeigniter.com/user_guide/
Про Zend Framework на английском почитать можно тут:
http://framework.zend.com/docs/overview
На русском здесь:
http://framework.zend.com/manual/ru/
И, наверняка, вы найдёте по нему пару книжек в ближайшем книжном магазине.
Документацию Yaf можно почитать здесь:
http://www.php.net/manual/en/book.yaf.php
И здесь:
http://www.php.ru/manual/book.yaf.html
А для знатоков китайского тут:
http://yaf.laruence.com/manual/
Система управления версиями
Так же известная как «VCS», «Version Control System», «Репозиторий», «SVN», «Git» и даже «Вот эта фигня, где хранится главная копия программы». Систем контроля версий существует немало, но по своим ощущениям, скажу, что главные игроки: Subversion (SVN) и Git. Что выбрать? Я использую Git, но говоря по честному, SVN меня тоже во всем устраивает. Немало крови было пролито в священных войнах между сторонниками обоих систем, так что выбор за вами. Почитайте статьи в сети, и попробуйте обе системы, благо, это сделать очень просто. Существует немало on-line сервисов, предоставляющих доступ к репозиториям. Во многих можно переключаться между разными VCS. Лично я использую набравший в последнее время нереальную популярность GitHub. Для поклонников сервисов от гугла есть Google code, а так же, некогда очень популярный, но ныне совершенно захламлённый, и немного тормозящий sourceforge.
Однако, стоит помнить, что большинство сервисов бесплатно предоставляют только публичные репозитории. Что неплохо если вы разрабатываете open source проект. Для коммерческих проектов, когда не хочется светить код, нужно платить денюшку.
И ещё, очень важный нюанс. Ради Бога, не коммитьте в публичный репозиторий ваш config.php с реальным доступом к БД! Думаете смешно? Я вот я встречал таких…
Для работы с VCS чаще всего используют консольные команды (мой выбор), есть так же GUI клиенты или плагины для популярных IDE.
Что бы определится с выбором конкретного для вашего кода, можете почитать неплохую статью «Сравнение: проектов» в майском номере Linux Format'а.
Неплохой, очень наглядный гайд по Git'у
http://rogerdudler.github.com/git-guide/
Две отличные статьи по Git'у
http://habrahabr.ru/post/60030/
http://habrahabr.ru/post/60347/
Ну на самом github.com в документации все довольно неплохо объясняется
https://help.github.com/
Database migrations
Ох, кто бы только знал, как меня раздражает файлик «dump.sql»! Если системы контроля версий для файлов проекта, худо-бедно, но начинают приживаться среди разработчиков, то системы контроля версий для базы данных — огромная редкость (не считая Ruby on Rails).
Ведь когда над проектом работают несколько человек — довольно сложно вносить изменения в структуру БД, обычно их записывают в специальный файлик, и рассылают каждому члену команды по почте… Это конечно работает, но во первых: нельзя откатится до конкретной версии БД, во вторых, никогда не знаешь кому из разработчиков оторвать руки за «гениальную» организацию той или иной части БД. Я уже не говорю о ситуации, когда один из разработчиков внёс изменения в структуру БД локально (ну например через phpmyadmin), и забыл рассказать об этом остальной команде. В общем, у такого подхода слишком много узких мест, рано или поздно, вы и без меня бы задумались, что должно быть другое решение. И оно, конечно есть.
Что мы получим используя миграции:
- Изменения в БД представлены в виде файлов, содержащих sql команды, а значит имеем возможность коммитеть изменения прямо в VCS (прощай dump.sql на почте).
- Видим текущую версию БД и можем откатиться до любой другой версии.
- Видим кто и когда вносил изменения.
- Исключены конфликтные ситуации. Система не даст вам провести миграцию, если найдёт конфликт.
Ну и т.д. Перечисленные плюсы уже стоят того, что бы всерьёз задуматься о системе миграций. В CodeIgniter'e для этого существует специальный класс, в Zend Framework, к сожалению, ничего такого нету, однако я, например, написал свою небольшую систему (в принципе, работы там на день максимум). Так же, миграции неплохо представлены в doctrine, которую я часто использую в паре с ZF, и, конечно, есть сторонние модули.
Кроме уже выложенных выше ссылок, можно ещё почитать отличную статью «Database Version Control».
P.S.
Ну и в заключение, перечитывая статью, понимаю, что получилось несколько скомкано, но я не пытался научить вас программировать с помошью framework'ов, не пытался научить коммитеть в VCS, и тем более, не пытался объяснить все тонкости database migrations. Я хотел просто рассказать про эти технологии, показать вам их, посоветовать, что почитать, и надеюсь, что помог кому-то открыть для себя что-то новое.
Автор: voff
