«Любая достаточно развитая магия неотличима от технологии». — перевернутый третий закон Кларка

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.