«Любая достаточно развитая магия неотличима от технологии». — перевернутый третий закон Кларка
Previously on Evercode Lab Advent
Были программистами. И везде было как-то не так и что-то не то.
Они делали дизайн, мы писали код.
Мы не просто пишем код, мы решаем проблемы или задачи конкретных людей.
…каждый коммит помимо автора просматривает хотя бы еще один программист.
«Ты ж программист»
В современном мире третий закон Кларка очень актуален: «Любая достаточно развитая технология неотличима от магии». Его обратный вариант тоже очень хорош и близок к истине.
Будем честны, в сознании большинства работа программиста непонятна, сложна, некатегоризируема, иногда страшна, иногда скучна. Несмотря на широчайшее распространение технологий, их внутреннее устройство и механизмы работы программ остаются загадкой для масс. Сами же программисты представляются обывателям этакими «мастерами на все руки» для всего, к чему подключен шнур питания и у чего есть какой-никакой экран. Это еще не говоря о том, что человек удаленный от мира технологий зачастую видит в программисте замкнутого в себе чудака не от мира сего, нередко зануду, говорящего на странном языке.
Конечно, большая часть этих предрассудков — чушь. Да, программист — профессия действительно особая, требующая соответствующего склада ума и характера. Но нюансы есть у всех профессий, не только у нашей.
Когда мы предоставляем свои услуги, мы знаем, что нас понимают далеко не всегда и не сразу. Поэтому учимся не только быть лучше в «своей теме», но и говорить на языке клиента. В сметах это обычно зашито в пункт «перевод с программистского на русский». Шутка)
История изменений
Написание кода — одна из основных задач в нашей работе. Та область, которую совершенствовать можно до бесконечности, если вовремя не остановиться.
Код всех наших проектов версионируется и ведется на Github. У нас есть аккаунт организации с возможностью создавать приватные репозитории. Для каждого проекта такой создается с самого начала.
При создании выдаются права на чтение-запись специально созданной группе EvercodeLab/team, в которой состоят все сотрудники фирмы. Т.е. у каждого сотрудника есть доступ ко всем проектам независимо от того, участвует он в нем или нет. Для проекта может быть создана еще одна группа доступа специально для клиентов и задействованных людей извне.
Помимо этого на все репозитории у нас подключены оповещения в специальную комнату Github в нашем рабочем чате. На любой коммит, пуш, комментарий к коду, форк и прочее падает сообщение, которое все видят.
Историю мы любим держать в порядке. Вот, например, некоторые рекомендации по коммитам:
- не стоит делать большие коммиты
- сообщения о коммитах должны быть на английском языке
- в сообщении о коммите желательно указывать номер задачи в YouTrack
- сообщение о коммите должно содержать короткое и понятное описание внесенных изменений
- правки code standards на весь проект стоит делать отдельным коммитом
Так же мы уделяем внимание и тому, что попадает в историю, а что нет. Для .gitignore есть такие советы:
- в .gitignore проекта должны быть только записи, специфичные для этого проекта
- файлы, относящиеся к локальному рабочему окружению должны оставаться в глобальном игноре (например, .idea или .DS_Store)
- в репозиторий не должны попадать пользовательские данные, кэш и логи
- в репозитории не стоит хранить специфичные для окружения настройки (доступы к базе, ключи к API и подобное)
Code Standards
На код мы смотрим много, причем не только на свой, но и на код коллег. Гораздо удобнее и приятнее, если стиль оформления кода при этом привычен и не отличается в рамках проекта и между проектами на одном и том же фреймворке. Поэтому у каждого проекта есть coding standards.
Например, для проектов на Symfony2 мы придерживаемся ее стандартов, которые в свою очередь полагаются на рекомендации PHP Framework Interop Group.
Чтобы контроллировать себя и не править оформление руками мы активно используем PHP Coding Standards Fixer.
Git workflow
За все время работы мы попробовали или посмотрели разные рекомендуемые и придуманные workflow для Git. Подобных алгоритмов для совместной работы в рамках одного репозитория довольно много и каждый из них имеет право на существование, так как в разных ситуациях удобство разных подходов различно. Сейчас у нас в состоянии подготовки-драфта-обсуждения свое полноценное и подробное описание рекомендаций по работе с ветками. Но пока опишу основные принципы.
- в основе процесса лежит использование feature branches и pull requests
- на каждую новую фичу или задачу мы создаем отдельную ветку от текущей основной
- если проект еще не запущен, то основная ветка — master
- после запуска мы как правило отделяем основную ветку для разработки — development, а в master код попадает перед релизом в прод
- в рамках ветки идет обычная работа над кодом, создаются коммиты
- когда фича готова, создается pull request и запрашивается code review и прочий фидбек; получить code review — обязанность автора pull request’а
- после обсуждения и доработок pull request мерджится в master или development, откуда уже деплоится на соответствующий сервер
Code review
Ревью кода — неотъемлемая часть процесса, которая сильно помогает избегать глупых ошибок и улучшать качество кода. Комментарии к коду мы оставляем непосредственно на github в коммитах или пулл реквестах. Тут же можно обсудить спорные решения, предложить альтернативные. Code review осуществляется любым другим человеком в команде, отличным от автора кода.
Очень хорошие «правила этикета» для ревью кода можно почитать в руководстве компании Thoughtbot
Deploy
Готовый и попавший в основную ветку код мы сразу заливаем на сервер. Как правило, сначала на тестовый для проверки и демонстрации, потом на прод. Все это делает непосредственно автор изменений сам.
Так как процесс этот может происходить часто, иногда по несколько раз в день, автоматизировать его было очень хорошей идеей.
Для Symfony2 проектов мы активно используем Capifony, для RoR и других соответственно ее предка — Capistrano.
Автоматизированные тесты
Признаюсь, с написанием автоматизированных тестов у нас все несколько хуже, чем хотелось бы. Но лучше, чем было раньше, и работа в этом направлении постоянно идет.
Мы активно используем PHPUnit и Behat, экспериментируем с PHPSpec.
Какие-то тесты есть у каждого проекта. Обязательным на сейчас является написание функционального теста на каждый action, т.е. по сути страницу. Но во многих случаях ребята идут дальше этого.
Проекты с тестами подключены к teamcity. Он прогоняет тесты после каждого пуша в репозиторий и выдает в чат статус, подкрашивая проваленные тесты красным, чтобы мозолило глаза и вызывало чувство стыда и неловкости.
Outro
Я уже довольно продолжительное время не называю себя программистом. Объективно, с развитием фирмы именно кодом я занимаюсь все реже и реже. Если я программирую, то это скорее исключение из правил. Тем не менее я до сих пор просматриваю большую часть кода, которую пишут остальные ребята, делаю ревью, даю советы, обсуждаю. Поэтому какие-то вещи я, возможно, раскрыл поверхностно или не до конца, что-то упустил.
Эта статья является частью Evercode Lab Advent 2014 — цикла из 24 статей о том, как появилась, устроена и работает компания Evercode Lab. Полный список статей можно посмотреть в анонсе Evercode Lab Advent.