11 Jul 2014

Корпоративные стандарты или Мама анархия?

Резюме: многие компании (а часто и команды) в какой-то момент пытаются выработать свои соглашения и стандарты по строению и оформлению кода/документов, процесса разработки, использованию инструментов и пр. В большинстве же ситуациях этого делать не нужно. Но если нужно, то как?

Стандарты и Соглашения (СиС) можно разделить например так:

  • СиС по написанию кода

  • СиС по процессу разработки и доставки

  • СиС по оформлению UI (UI приложений и документов)

Некоторые, возможно, подумают что СиС пропорциональны размеру компаний, мол, чем она крупней, тем больше “бюрократии”. Чтоб развеять сей миф, вот несколько примеров с моих мест работы:

  • Место1 (~60K человек, ~15K приложений). Есть СиС по UI документов и приложений, по возможным фреймворкам и библиотекам, а также по тому как должен выглядеть конечнный бинарник.

  • Место2 (похожие цифры: ~60K человек, ~15K приложений). Есть СиС только по оформлению документов.

  • Место3 (>1K человек, ~20 приложений). Есть СиС по: Оформлению документов, Инструментам и процессу сборки, Процессу проверки артефактов, Версионированию приложений, Версионированию баз данных, Хранению кода, Конфигурированию приложений, Процессу релиза.

Корпоративные СиС - вредители

Усложняют введение новых людей. Т.к. корпоративные стандарты отличаются один от другого в разных компаниях (командах), то новый человек прийдя к вам в проект, будет вынужден тратить усилия на то, чтоб влиться в процесс. Вам прийдется объяснять ему как что нужно делать, затем проверять. Ну и для упрощения процедуры конечно нужно описать ваши СиС.

Разным командам подходит разный стиль. Разработка у многих - творческий процесс, да и посредники современных методологий (Agile) утверждают что процесс нужно подстраивать под свои конкретные нужды, не усложняя его без реальной необходимости. Поэтому создав корпоративный стандарт, которому должны подчиняться все, вы скорей всего ухудшите эффективность конкретных команд и/или личностей, этот процесс им будет просто не подходить.

СиС сложно внедрять. На свете есть очень много упрямых людей, каждый из которых считает свое мнение самым весомым и свое виденье - самым верным. Если они будут не согласны с вашим мнением, вам прийдется потратить уйму усилий на переубеждения. А еще у команд есть свои сроки за несоблюдение которых можно поплатиться деньгами, у вас должно быть достаточно обоснований и авторитета чтоб увеличить нагрузку на без того опаздывающую команду.

Стандарты нужно поддерживать. Это большой, и что тоже важно, - нудный кусок работы. Найдутся люди, которые не до конца поймут ваш документ, либо в нем найдутся баги, несовместимости с некоторыми ситуациями. А еще - через год у вас может сложиться другое мнение, стандарты прийдется обновлять, а затем заново внедрять.

Стандарты меняются с людьми. Сейчас эти СиС разрабатываете вы и все идет своим чередом, но вы уйдете и на ваше место прийдет кто-то другой с мнением, отличающимся от вашего. И вся катавасия вероятно начнется сначала. Стоило ли оно того?

Оправдания-неудачники для стандартов

Чтоб все унифицировать. Это плохой довод, скорей всего какому-то четкому пацанчику, кто прыгал между проектами и завоевал авторитет у руководства, захотелось сделать их похожими. Тем не менее унификация не должна быть самоцелью. Нужно унифицировать, потому что… И только если определили почему, стоит задумываться о том чтоб тратить на это усилия.

Чтоб проще было ротировать людей. Это как правило тоже неудачный довод (хотя по-моему встречается чаще всего). Во-первых, люди часто сами хотят ротироваться чтоб сменить обстановку, попробовать новые подходы, чтоб скучно не было. А тут вы со своей унификацией. Во-вторых, повторюсь, проекты разные и требования к ним тоже могут быть разными. Если вы, к примеру, унифицируете используемые фреймворки и технологии, вы можете сильно усложнить эффективную разработку, например, будут проблемы с производительностью или архитектурой, народу прийдется вставлять костыли только ради унификации.

Оправдания-удачники для стандартов

Интерфейс между командами. Разработку могут поддерживать несколько команд, например, вашими окружениями заведует отдельная DevOps команда, или ваше приложение тестирует отдельная QA команда, или релизят продукт какие-то левые люди, или кто-то для вас настраивает CI, или… Для таких команд вы можете быть не единственными, они могут изменять вам еще с 10ю проектами. И если каждый из этих проектов - уникальный, то такие команды-сервисы будут страдать и работать неэффективно. Т.е. будет разумно если такая команда напишет документ, которому будут следовать все остальные. Как пример, CI команда может потребовать чтоб все работали только с Maven.

Чтоб продукты были похожи для клиентов. Иногда да, есть требование, чтоб продукты были похожи с точки зрения UI, чтоб пользователи понимали, что это один и тот же поставщик или один и тот же ресурс.

Уменьшить кол-во поддержки в будущем. Если разные команды владеют одним инструментом (Nexus, JIRA, CI, etc.) так может случиться, что все они по-разному его настраивают и в какой-то момент произойдет коллапс. Чтоб этого не произошло, либо у каждой команды должны быть свои инструменты, либо стоит задуматься над общими соглашениями.

Имеется экспертиза. Допустим есть ИнструментА, которым на очень хорошем уровне владеют N людей. И есть возможность использовать альтернативный ИнструментБ, о нем вчера вахтерша рассказала. Понятно, что любой инструмент не идеален, но учитывая обстоятельства использовать ИнструментБ - значит повышать риски. Да, нам хочется разнообразия. Да, истину постигают в сравнениях. Конечно имеет смысл поэкспериментировать если этому способствует обстановка, вдруг ИнструментБ окажется намного удобней. Но важно не переборщить, один новый инструмент/фреймворк на проект - достаточно, чтоб не забыть о сладостном геморрое. За сим, если у вас есть экспертиза в компании, логично если все команды будут использовать по возможности ИнструментА.

Какими должны быть стандарты

Если уж вы решились стандартизировать что-либо в своей конторе, то вот несколько советов.

Возможности не следовать стандарту быть не должно. Для этого здорово если все проверки автоматизируются. Хотите, чтоб commit message начинался с Issue ID? Сделайте hook который будет проверять формат и отвергать коммит если он не соответствует стандарту. Код должен следовать соглашениям? Настройте проверки, которые будут валить сборку если правила не соблюдены. Если же стандарт существует только на словах/в документе, то всегда будет находиться кто-то, кто ему будет не следовать. Это чревато тем, что народ будет тратить время на разбирательства и пояснения, а делать это не захочется уже на 3ий раз. В какой-то момент начнут забивать все.

Отдельно тут хотелось бы отметить логирование потраченного времени. Это тоже своего рода соглашение-стандарт относящийся к процессу, когда руководитель проекта к примеру просит всех отмечать сколько времени было потрачено и на что. Почему это неудачная затея можете почитать тут.

В данном случае критерием можно сделать следующее: если команда не будет придерживаться установленных правил после того как инициатор ушел в отпуск, значит стандарт не был внедрен успешно или эти правила не поддаются внедрению и пробовать этого даже не стоит.

Способы автоматизировать проверки:

  • VCS hooks

  • Maven Enforcer Plugin

  • PMD

  • Доп. проверки на CI сервере

Нужно иметь возможность обойти ограничения. Это противоречит предыдущему пункту, но иногда, в каких-то критических ситуациях, все-таки полезно иметь обходной путь. Вот знать его ВСЕМ не обязательно :)

Обратная связь от автоматизации должна быть информативной. Т.е. если какое-то правило нарушено и проверка не прошла, сообщение об ошибке должно содержать пояснение, предложения (как исправить ситуацию), возможно ссылки на доп. ресурсы и, на худой конец, контакты людей кто может проконсультировать.

Документы должны легко читаться. Они должны быть небольшими (максимум - пара страниц) и простыми, желательно в неофициальном стиле. Это кстати часто не соблюдается, народ любит позаковыристей написать, особенно если за этот документ нужно будет отчитываться перед начальством. Не будешь же объяснять начальству почему ты потратил 2 дня на документ в котором есть смайлики. Однако нужно понимать кто ваша целевая аудитория и подстраиваться под них, а не под руководство.

Для разработки и поддержки стандартов нужны выделенные люди. Это если вы реально хотите чтоб им следовали. Потому что работы тут очень много, вполне возможно что таких людей должна быть целая команда. Если же вам следование стандартам не критично, см. следующий пункт.

Гайдлайны - выгодней стандартов. Гайдлайны отличаются от стандартов необязательностью. Вы можете описать какие-то требования к проектам/процессам, но лишь как советы, мол, так будет лучше и проще для всех, следовать им желательно, но не обязательно. Так, например, поступают Atlassian, у которых есть UI гайдлайны. Большинство, стоит заметить, им следуют, даже учитывая что следование этим правилам никто не проверяет.

Используйте официальные практики инструментов. Проще не писать свои документы, а использовать уже описанные соглашения на сайте самого инструмента. Такие соглашения разработчики смогут использовать и на других проектах и в других компаниях. Это хороший способ стандартизировать везде.

Плюсы в таком случае в том, что замарачиваться над внедрением этих правил нужно будет намного меньше. И по идее многие будут им следовать хоть в какой-то мере без пинков.

Выводы: как бы некоторым не хотелось все унифицировать - сделать это до конца может далеко не каждый. Поэтому либо разрабатывайте гайдлайны, либо готовьтесь посвещать унификации все свое рабочее время, либо готовьтесь к тому что следовать вашим стандартам и соглашениям будет небольшая группа людей.