Что вы делали для облагораживания разработки на php?
У заказчика есть довольно посещаемый сайт, используется фреймворк codeigniter, код заливается на php или правится сразу через ssh на сервере из под рута. Собственно куча проблем с разработкой от того что не делаются нужные вещи, нет контроля за исходниками, в код нагадил старый уволенный программист, иногда при обновлении кода сайт ложится, разработчики допускают гигантское количество ошибок.
Первое что сделал смигрировал сайт на новую машину с последними версиями php и apache, заблочил доступ по ssh, дал доступы по ftp, вычистил вредоносный код(не уверен что весь), исправил все небольшие ошибки вылезшие после обновления php с 5.1 до 5.3, с базой mysql теперь работают из под отдельной учетки не из под рутовой. Сразу отмечу что девелопили куча народу и код больше похож на быдло код, разобраться в части ошибок было не просто, код наполнен кучей комментариев с отладочным кодом.
Думаю надо ещё сделать тестовый сервер для обкатки изменений, перевести исходники на github, туда же перевести из экселя роадмап по разработке. Деплоить все на сайт гитом, сперва на тестовый, а потом на продакшен.
Что ещё можно сделать? Как вы девелопите для продакшена на php?
1) Тестовый сервер
Очень часто бывают ситуации, когда разработчик(в частности фрилансер) находится не за своим любимым рабочим местом, а где-то в гостях, в отъезде и т.д.
Когда появляется необходимость исправить баг или внести какие-либо изменения — разворачивать за чьим-то ноутбуком/стационарником все инструменты, ставить денвер, качать все целиком, разворачивать базу. Значительно проще поставить winscp¬epad++ и внести правки на продакшн. С увеличением частоты таких «правок» код превращается в то, что описано выше.
Для решения таких проблем в первую очередь введен регламент — запрета вносить правки на продакшн, но! одновременно с этим допускается работа на тестовом сервере! Все правки, мелкие большие с сервера коммитятся в свн(изучить консольные команды svn для разработчика не составляет проблемы… их нужно 2-3 в такой ситуации) и уже только после этого апдейт на продакшене. Для апдейта на продакшене даже сделан www-скрипт, который позволяет делать апдейт без подключения к ssh и т.д.
Изменения в БД все только через миграции!
Так что делайте тестовый сервер обязательно! ИМХО необходимая вещь любому проекту.
2) Трекер! Писать и общаться через трекер воспитывает и клиента и заказчика.
Мы на томже тестовом развернули редмайн. Позже добавили к нему tikiwiki, в которую пишутся полезные няшечки для других разработчиков и клиента. Трекер также отображает активность разработчиков для клиента. Клиенту приятно посмотреть, что вот была такая ошибка и по её исправлению был сделан такой-то коммит и вон чето поменяли.
3) Проведение рефакторинга. Очень сложно клиенту объяснить, что это такое и зачем он нужен. Почему он должен платить за «переписывание» кода? Пишите сразу правильно, скажет он. Практика показывает, что всетаки можно доказать клиенту необходимость этого действия.
4) Автоматические тесты.
На тестовом сервере далеко не всегда можно увидеть все проблемы- не поломался ли чужой код.
Использование фреймворков позволяют не разводить тотальную быдлятину и обложить код тестами.
1)Как делать миграции бд?
2)Все будет через трекер на гитхабе.
3)Попробуемс.
4)К сожалению засилие быдло кода самое сильное в этом проекте за всю мою жизнь.
1) Мы пишем в основном на Yii, там из коробки есть отличный инструмент для миграций. Насколько я вижу, для CI также он имеется
2) *THUMBS_UP*
3) + 4) Сделаете рефакторинг, параллельно можно навесить тестами. Потом не пожалеете!
Тестирование + документирование еще можно прикрутить. Ну и все это через continuous integration сервер какой-нибудь.
А тестовый сервер (ну или staging), я думаю, обязательно надо.
Тестирование + документирование + метрики кода + заливка на staging. Как-то так. У нас в компании не все эти слагаемые еще есть, поэтому я и сказал, что я бы не назвал то, что есть полноценным continuous integration.
Генерация документации по комментариям в коде через DocBlox. Сначала пробовал на phpDoc, но пишем на symfony2, у phpDoc с namespace проблемы оказались — как-то криво их обрабатывал. Метрики — это всякие проверки на соответствие стандартам кодирования (отступы, скобочки и т.п.), поиск дублирующихся участков кода и т.п. aaronbonner.tumblr.com/post/8380014964/creating-a-php-project-in-jenkins — статья про настройку этих утилит для jenkins.
Зависит от проекта. Юнит тесты (я подозреваю что их нет), Continuous Integration,… Кстати, заказчик то не против будет сорсов на гитхабе? или вы приватный репозиторий собираетесь создавать?
Репозиторий приватный.
Как прикрутить к этому быдлокоду юнит тесты я пока не могу придумать с ходу, но поговорю об этом с новым разработчиком, которого надеюсь скоро найду.
НУ так это надо ещё один сервер ставить, ставить гит и потом его админить постоянно. При цене сервиса 5-15 долларов в месяц это экономически не выгодно.
Сейчас скажу бесполезный совет.
Последнее моё облагораживание привело к переписыванию с нуля. Профит огромный — если писать сразу по плану и правильно, получается быстро, 500 строк быдлокода можно свернуть в 10 строк контроллера/модели в MVC.
Хм, получается вы берете код, смотрите что он делает, меняете его структуру, возможно где-то алгоритмы и логику так, чтобы в конце-концов получить такой же функционал. Этот процесс называется рефакторинг без TDD.
Его можно проводить поэтапно, модуль за модулем, а можно раз и сразу на всю систему.
Просто второй вариант часто бывает слишком долгим, заказчики часто не готовы столько ждать, особенно, когда им срочно потребовалось «добавить пару кнопочек».
Это может кончиться руганью с заказчиком из-за того, почему так долго, либо поддержкой старого кода, пока не внедрили новый. ИХМО, и то, и то плохо.
Я склонился ко второму варианту по той причине, что очень много времени пришлось бы выяснять имеющуюся функциональность и алгоритмы. То есть тупо не код писать, а документировать существующий. А так часть «причесывания», включая интеграционные тесты на имеющуюся функциональность и юнит на проведенную декомпозицию, можно сделать и без вникания в код и алгоритмы.
Согласен, всё зависит от проекта и от заказчика.
Может оказаться, что половина функционала вообще не нужна, ну то есть была нужна на момент разработки, но потом потеряла актуальность.
Такого у меня не может быть в принципе. Моя задача развитие существующего живого проекта, все части которого востребованы — как добавление новой функциональности, так и изменение существующей. Все эти тестирования и рефакторинги я делаю чисто для себя, чтобы, во-первых, быть (более) уверенным, что ничего не сломаю и, во-вторых, чтобы не плодить быдлокод дальше, чтоб не материться на себя же, когда окажется, что нужно уже свой код менять :)
Немного советов от человека, который на CodeIgniter собаку съел.
В CodeIgniter очень хорошая расширяемость, проанализируйте код, найдите общие моменты и сделайте рефакторинг кода, вынесите общие методы из моделей в свои типы моделей (можно унаследовать у MY_Model), с контроллерами так же.
Views файлы надеюсь разбиты на папки контроллеров, если нет, то надо разбить. Весь JS вынести так же в отдельную папку и по своим файлам так же.
Причесать код сведя контроллеры к минимуму действий.
На модели в CodeIgniter есть инструмент тестов, вполне хватающий для тестирования их.
Коллеги, присоединяюсь ко всему, что сказано выше.
От себя добавлю.
unit-тесты на старый код — это бесполезное занятие, т.к. там наверняка быдло код, его качественными тестами покрыть будет крайне трудоемко. я бы сделал так.
1. на весь новые функционал писать unit-тесты. программистам дать для просвещения макконела и что-нибудь по практикам TDD, SOLID, GOF.
2. старый и новый функционал покрыть интеграционными тестами.
Если есть какие-то фоновые взаимодействия, выгрузки и прочее, это можно проверять.
Пользовательский интерфейс тоже можно тестировать автоматизированно.
см. BDD. Пусть в браузере прогоняется автоматически весь функционал сайта.
3. в качестве CI-сервера я использовал hudson. Меня вполне всё устроило.
тот же Jenkins — это его форк
4. за продакшен должен отвечать только один человек.
можно организовать это так. делаем отдельную ветку, или бранч, или вообще отдельный реп.
это как организуетесь.
в него может комитить только один человек. Этот человек делает ревью всего кода перед тем как залить его в продакшен репозиторий.
соответственно этот человек «выпивает мозги» программистам, чтобы всё так было. Ну а случись что, есть за это дело ответственный, с которого спрашивается в первую очередь.
5. на счет www-скрипта — это уж слишком, если б программистов было человек 30 и функционал выкатывался бы каждый день(или хотя бы раз в неделю разными людьми), то да, а так я думаю оно лишнее.
бывают ситуации, когда приходится делать отладку на боевом комитами и www-скриптом. Кто-нибудь из программистов обязательно так сделает…
Тут спорный вопрос, все зависит от кода. Точнее от связей внутри.
По идее, надо чтобы каждый модуль был как можно более автономным, а количество связей минимально, но быдлокодеры об этом не знают, поэтому получается один большой кусок кода.
И ещё, есть такой antiparten — хрупкие тесты.
На практике бывает так:
1. выделяем модуль, на все связи пишем моки, связей дофига, поэтому моки иногда длиннее самого проверяемого кода
2. пишем тесты, поскольку связей дофига, то тестов тоже дофига, на каждую ситуацию
3. один модуль протестирован, убито дофига времени, осталось ещё 100, а то и 200 (реальная ситуация).
4. меняем пару строчек логики, отваливается штук 20 тестов, уходим ещё на 4 часа в отладку и починку этих тестов
Итог,
— программист делает кучу тупой и тяжелой работы,
— эта работа бесполезна, т.к. любое изменение в коде ломает чуть ли не половину тестов, тесты не учитывают все варианты, то есть баги ещё остались.
— программист (даже очень хороший) искренне думает, что TDD — это какая-то идеализированная штука, которую не реально применить в реальном проекте.
Кончается всё тем, что после долгих мучений все дружно забивают на тесты.
Когда проводите рефакторинг, на новый код нужно писать Unit-тесты. А то что ничего не сломалось,
просто поймите, TDD — это лакмусовая бумажка хорошей архитектуры приложения, если всё клево, то тесты писать легко и приятно, а если быдло-код, то тесты нормальные написать практически не возможно, а с ненормальными — умучаетесь. Решение проблемы, либо отказаться от unit-тестов на старый код и проверять его качество как-то ещё, либо всё перерефакторить (что в данной ситуации чуть быстрее чем переписать с нуля, но всё-равно тоже долно).
Ах да, ещё бывает так, что моки подпихнуть не представляется возможным.
В итоге, один и тот же код многократно запускается в каждом тесте, и при поломке этого кода ломаются все эти тесты.
Банальный пример, сломался у вас логгер. Отвалились все модули, которые что-нибудь пишут в лог.
Это в корне ломает половину идей TDD и тоже ведет к хрупким тестам.
Организовал так:
— исходники в репе под Mercurial
— клон репа на тестовом сервере, докрут указывает на нужный каталог
— на продакшен деплой производится capistrano
— если приходится править код в «экстремальных» условиях, то на сервере есть отдельный пользователь тоже со своим клоном репа и установленным capistrano, то есть даже срочная правка по ssh заключается в пулле свежих изменений с основного репа, внесение срочных, коммит в клон, пуш в основной, cap deploy
По сути capistrano это скрипт для деплоя, который сам подтягивает себе изменения из репа и заливает их на сервер (плюс миграции БД и прочие «мелочи»). Раньше для этих целей пользовался самописным на баше, работающим через rsync и т. п., но надоело переписывать его для каждого проекта, и только задумался о написании универсального, как статья на хабре о капе :) Получил кучу возможностей, о которых думалось, но руки не доходили, тот же автоматический запуск миграций. Причём навскидку не использую и половины возможностей капа, типа поддержания нескольких серверов в синхронном состоянии для распределенных приложений.
Трекер — редмайн, система контроля версия СВН.
Разработка ведется на 3-х серверах разработки на которых работают две команды. Два основных, один на случай если есть параллельные задачи. Все изменения хранятся в СВН. Тестировщики предварительно тестируют экземпляр прямо на серверах разработки. После успешного предварительного тестирования, Хадсон собирает экземпляр на тестовый сервер.
После успешного тестирования, пакет собранный из СВН устанавливается на пре-продакшн частично вручную, частично при помощи sh-скрииптов. После еще одного сокращенного цикла тестирования аналогично устанавливается на продакшн.
К сожалению модульное тестирование не внедрили, не хватает времени.
По поводу wiki.
Заводите в репозитории папку docs и кидаете туда текстовые файлы с описанием. github умеет красиво показывать определенное форматирование.
Но есть вариант лучше, попробуйте GoogleDoc.
Можно даже корпоративный сделать со своим доменом.
плюс по сравнению с wiki
1. одновременное редактирование несколькими пользователями
2. крутая история изменений
3. крутой редакторы, разные форматы офисным данных
4. экспорт данных в разные форматы
короче, такой вариант мне очень нравится ) сам пользуюсь )
Средний
