Немного о командной работе

    В очередной раз, согласившись на фрилансерский заказ (а ведь обещал себе покончить с фрилансом раз и навсегда), я тяжело вздохнул, и при первой же возможности, сел изливать свои мысли на бумагу. Когда мы начинаем новый проект, часто у нас не хватает опыта сделать это правильно, иногда нам просто лень изучать новые технологии, но чаще всего, мы уверенны что и так все прекрасно спрограммируем, без всяких VCS, фрэймворков и миграций. Для тех, кто может найти в себе силы на что то большее, чем связка Denwer -> ftp client -> hosting, я набросал несколько рекомендаций, как можно сделать процесс разработки web-приложения немного более удобным.


    Framework


    «Начнём с элементарного», хотел я написать, и понял, что принимая уже начатые кем-то проекты, считанные разы встречал там фрэймворки. Толи мне не везёт с предшественниками, толи большинство программистов стараются фрэймворки не юзать. Слышал даже утверждение что: «Фрэймворки — для ламмеров, я все руками пишу». Я знаю, как минимум, две причины, из-за которых следует использовать фрэймворки:
    1. У вас есть каркас приложения, и куча библиотек, которые облегчают вам жизнь и экономят ваше время.
    2. Рано или поздно, в вашей команде появляется новый программист, который вольётся в проект гораздо быстрее, если уже знает как устроенно ваше приложение. В крайнем случае, он будет мучить не вас, а документацию фрэймворка, что, опять же, экономит ваше время.

    Лично я всегда использую один из двух фрэймворков: 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://cidocs.ru/210/index.html
    Ну и конечно, оригинальная на официальном сайте:
    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. Я хотел просто рассказать про эти технологии, показать вам их, посоветовать, что почитать, и надеюсь, что помог кому-то открыть для себя что-то новое.
    Поделиться публикацией
    Комментарии 20
      +2
      Маловато до Level Up, да и не про все фреймворки рассказано. Из них вытекают Паттерны. Про IDE вообще ни слова.
        +1
        Рассказать про ВСЕ фрэймворки невозможно в принципе. Рассказал о тех, с которыми работаю. В плане IDE — немного другая тема, какую IDE использовать — личное дело каждого, в статье же, описаны технологии, которые влияют на командную работу.
          +2
          Паттерны вытекают не из них. ActiveRecord бал описан Фуллером еще в 2003 году, Zen только начал его использовать. Database Schema Migration тоже древний труд. Паттерны реализовываются в фреймворках, а не наоборот. Тот же REST, TDD и BDD использовались вне фреймворков в начале. Подобие MVC есть даже в 1C-бухгалтерия. Паттерны не вытикают из фреймворков. И любое изящное решение внутри фреймворка нельзя называть паттерном.
            0
            Я сужу по тому, как люди выходят на паттерны. Обычно это происходит после знакомства с фреймворком, тот же MVC.
              0
              Получается что люди мало читают фундаментальных трудов :(
          +3
          bitbucket.org тоже неплох. Более того, в отличии от того же GitHub, на bitbucket можно завести сколько угодно приватных репозиториев (на GitHub, если не изменяет память, лимит в 5 приватных). Речь, конечно же, идет о том, что достпуно в бесплатной версии.
            0
            На gitgub во free версии нет бесплатных репозиториев, только в версии micro (7$/месяц)
              +1
              угу… там кроме всего можно управлять доступом к своим репозиториям… создавать целые комманды разработчиков
              +2
              По CodeIgniter есть поновее документация.
                0
                Добавил ссылку в статью :-)
                0
                а ведь обещал себе покончить с фрилансом раз и навсегда

                Можно поинтересоваться зачем?
                  0
                  Времени не него совсем нет. А сидеть ночами — здоровье уже не то)
                  0
                  О Git на русском: GitHowTo. Для начинающих может быть большим подспорьем.
                    0
                    Вот если бы Вашу статью прочитали все все люди, относящие себя к программистам, и хотя бы чуточку задумались, возможно, мир бы стал лучше.
                      0
                      Изначально примерно такой расчет и был, но что-то невидно что бы кто-нибудь задумался :-)
                      0
                      Добавьте в статью информацию о VCS Mercurial.
                      Новички его оcвоят быстрее чем GIT.
                      Хотя Hg(Mercurial) гораздо ближе к GIT'у чем к SVN, т.к. системы контроля версий тоже распределенная.

                      Официальный сайт
                      Мануал
                      Mercurial для пользователей GIT
                        0
                        По миграции БД вот это www.antonoff.info/development/mysql-migration-with-php-project пробовал. Довольно простое.
                          0
                          DenisZ И как вам MMP? Пользуетесь? Есть предложения/замечания?
                            0
                            В реальных проектах не использовали, так что что-то дельное сказать не могу. Возможно, в новом проекте попробую.
                              0
                              Фичреквесты и багрепорты — welcome :)

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое