Представьте ситуацию. Вы со своей командой, после очередной итерации, обсуждаете слабое покрытие кода тестами и решаете что с понедельника текущего момента все пишут тесты как для нового кода, так и для всплывающих багов. Это кажется разумным (кто-то вспоминает последний неудачный деплой), все поддакивают и довольные расходятся с мыслью, что ну вот теперь то у нас точно все будет отлично. Приходит время следующего собрания на котором во время вопроса «а как у нас с тестированием» большинство отводит глаза. Результат ясен, все осталось по старому.
Можно конечно попытаться вычислить тех кто этого не делает, выяснить почему так происходит, провести воспитательную беседу) и это даже поможет на какое-то время. А потом пройдет время и все станет по прежнему. Причем те люди которые следуют соглашениям по данному вопросу, в другом вопросе могут делать все по своему и наоборот.
Другая ситуация. Для проекта понадобилась система прав доступа и ее реализовал один из участников команды. Библиотека получилась мощная, гибкая и в целом удобная. Ее начинают активно использовать и спустя какое-то время замечают что многие игнорируют правила работы с библиотекой (соглашения) в результате чего код запутывается, появляется много дублирования, постоянно возникают ситуации что доступ к функционалу имеет не тот кто должен и никто не в состоянии быстро разобраться в хитросплетениях правил доступа.
Что объединяет эти ситуации? Недостаточный контроль за процессом. Контролировать можно совершенно по разному и ниже я хочу поделиться своими мыслями по поводу того как лучше это делать и почему.
Начнем с того что контроль условно можно разделить на две категории (в контексте данной статьи): внутренний и внешний. Внутренний контроль — это автоматизированные проверки и ограничения с помощью определенных архитектурных решений как на уровне проекта в целом, так и при проектировании конкретных библиотек (проектирование интерфейсов). Внешний это проверка проверяющим (в том числе инструментами статического анализа) по факту готовности.
Примеры:
Внешние ключи в базе данных — внутренний контроль.
По умолчанию «все запрещено» с помощью acl — внутренний контроль.
Менеджер смотрит коммит к тикету — внешний контроль.
Статический анализ кода — внешний контроль.
Оба вида контроля важны. При этом, все что можно контролировать автоматически, нужно автоматизировать и превращать внешний контроль во внутренний. По сути статья о том как «добиться максимального качества кода при минимальном контроле и устранить человеческий фактор». Это сбережет вам нервы и поможет максимально исключить влияние человека на качество программного продукта.
— База должна самостоятельно поддерживать свою целостность (fk, check) и быть максимально строгой в отношении входных данных. Тогда большинство ошибок разработки будут выявлены на самых ранних этапах.
— Всегда используется принцип «все что не разрешено — запрещено».
— При проектировании внутренних компонентов нужно стремиться к минимизации правил которых придется придерживаться в процессе и спользования. Иногда даже ценой потери гибкости (но так чтобы это не стало проблемой и препятствием). И философия python в помощь.
— Пользуйтесь моками в тестах только в случае острой необходимости (внешняя служба), иначе на каждую строчку в реальном коде придется менять несколько строк в тесте, и в конце концов это станет невыносимым бременем для всей команды.
— Внутренние библиотеки (в отличие от кода самого приложения) можно менять только при согласовании с главным разработчиком. Тут без контроля не обойтись, но можно частично решить проблему создав хуки в системе контроля версий, которые не будут давать закоммитить код по нужным вам условиям.
— Когда при разработке постоянно приходится держать в голове вещи которые «нельзя забыть» то скорее всего что-то не так. Если невозможно сделать рефакторинг который позволит об этом не думать, то нужно сделать хотя бы так чтобы код сам проверял свои требования и сообщал о них (например выкидывая исключения).
— Код который пишется или используется первый раз (первый демон, первое использование acl или любого другого компонента) должен быть написан очень качественно, ведь в дальнейшем все будут ориентироваться именно на него.
— Программирование в парах повышает качество кода.
— По мере возможностей нужно меняться задачами и не попадать в ситуации когда «понимает только Вася, но он болеет вторую неделю».
— Организуйте процесс разработки так, чтобы весь код проходил через «главного разработчика». Используйте не соглашения, а правила самой VCS, дающие доступ на запись в trunk (master) только ему.
— Используйте непрерывную интеграцию. И красный флаг не должен становиться нормой.
— Выработайте требования к коду и проводите ревью.
Конечно же это не все. Ниже несколько примеров применения описываемого подхода в реальном коде.
У нас в проекте куча демонов, фреймворк предлагает наследовать класс и переопределить метод run. Естественно, что в этом методе можно написать целиком код небольшого демона (что на практике часто и делали). Добраться до такого кода и протестировать его — почти нереально. Логичное решение — попросить всех писать отдельные классы для каждого демона, а в методе run делать только вызов. Но это работает только при максимальном внешнем контроле, поэтому лучше перекрыть прямой доступ к этой части фреймворка и требовать передачи класса демона в свой прокси-код. Всю работу по запуску сделает он, а написать неправильно — просто нельзя либо очень трудно. Наверное это и есть «синтаксический уксус ©».
В другом проекте вся бизнес-логика находилась внутри базы данных и доступ к ней осуществлялся исключительно через вызовы процедур. Организация доступа к базе данных была реализована в ограниченном варианте который не позволял делать обычные sql команды. Поэтому за этим аспектом не нужно было следить.
В целом можно сказать так: Создавайте свои системы таким образом чтобы правильные вещи делались легко и естественно, а нежелательные были невозможны или делались с большим трудом.
upd Здесь идет речь не о контроле за людьми! Это очень важно. Не нужно их держать на поводке и контролировать каждый их шаг. Пусть они спокойно коммитят свой код, а вот уже на ревью, выявив недостатки, код можно отправить на доработку.
Я думаю что у многих найдется что сюда добавить. Буду рад услышать ваш опыт.
p.s. vasfed спасибо за правки и доработки.
Можно конечно попытаться вычислить тех кто этого не делает, выяснить почему так происходит, провести воспитательную беседу) и это даже поможет на какое-то время. А потом пройдет время и все станет по прежнему. Причем те люди которые следуют соглашениям по данному вопросу, в другом вопросе могут делать все по своему и наоборот.
Другая ситуация. Для проекта понадобилась система прав доступа и ее реализовал один из участников команды. Библиотека получилась мощная, гибкая и в целом удобная. Ее начинают активно использовать и спустя какое-то время замечают что многие игнорируют правила работы с библиотекой (соглашения) в результате чего код запутывается, появляется много дублирования, постоянно возникают ситуации что доступ к функционалу имеет не тот кто должен и никто не в состоянии быстро разобраться в хитросплетениях правил доступа.
Что объединяет эти ситуации? Недостаточный контроль за процессом. Контролировать можно совершенно по разному и ниже я хочу поделиться своими мыслями по поводу того как лучше это делать и почему.
Начнем с того что контроль условно можно разделить на две категории (в контексте данной статьи): внутренний и внешний. Внутренний контроль — это автоматизированные проверки и ограничения с помощью определенных архитектурных решений как на уровне проекта в целом, так и при проектировании конкретных библиотек (проектирование интерфейсов). Внешний это проверка проверяющим (в том числе инструментами статического анализа) по факту готовности.
Примеры:
Внешние ключи в базе данных — внутренний контроль.
По умолчанию «все запрещено» с помощью acl — внутренний контроль.
Менеджер смотрит коммит к тикету — внешний контроль.
Статический анализ кода — внешний контроль.
Оба вида контроля важны. При этом, все что можно контролировать автоматически, нужно автоматизировать и превращать внешний контроль во внутренний. По сути статья о том как «добиться максимального качества кода при минимальном контроле и устранить человеческий фактор». Это сбережет вам нервы и поможет максимально исключить влияние человека на качество программного продукта.
Внутренний контроль
— База должна самостоятельно поддерживать свою целостность (fk, check) и быть максимально строгой в отношении входных данных. Тогда большинство ошибок разработки будут выявлены на самых ранних этапах.
— Всегда используется принцип «все что не разрешено — запрещено».
— При проектировании внутренних компонентов нужно стремиться к минимизации правил которых придется придерживаться в процессе и спользования. Иногда даже ценой потери гибкости (но так чтобы это не стало проблемой и препятствием). И философия python в помощь.
— Пользуйтесь моками в тестах только в случае острой необходимости (внешняя служба), иначе на каждую строчку в реальном коде придется менять несколько строк в тесте, и в конце концов это станет невыносимым бременем для всей команды.
— Внутренние библиотеки (в отличие от кода самого приложения) можно менять только при согласовании с главным разработчиком. Тут без контроля не обойтись, но можно частично решить проблему создав хуки в системе контроля версий, которые не будут давать закоммитить код по нужным вам условиям.
— Когда при разработке постоянно приходится держать в голове вещи которые «нельзя забыть» то скорее всего что-то не так. Если невозможно сделать рефакторинг который позволит об этом не думать, то нужно сделать хотя бы так чтобы код сам проверял свои требования и сообщал о них (например выкидывая исключения).
— Код который пишется или используется первый раз (первый демон, первое использование acl или любого другого компонента) должен быть написан очень качественно, ведь в дальнейшем все будут ориентироваться именно на него.
— Программирование в парах повышает качество кода.
Внешний контроль
— По мере возможностей нужно меняться задачами и не попадать в ситуации когда «понимает только Вася, но он болеет вторую неделю».
— Организуйте процесс разработки так, чтобы весь код проходил через «главного разработчика». Используйте не соглашения, а правила самой VCS, дающие доступ на запись в trunk (master) только ему.
— Используйте непрерывную интеграцию. И красный флаг не должен становиться нормой.
— Выработайте требования к коду и проводите ревью.
Конечно же это не все. Ниже несколько примеров применения описываемого подхода в реальном коде.
У нас в проекте куча демонов, фреймворк предлагает наследовать класс и переопределить метод run. Естественно, что в этом методе можно написать целиком код небольшого демона (что на практике часто и делали). Добраться до такого кода и протестировать его — почти нереально. Логичное решение — попросить всех писать отдельные классы для каждого демона, а в методе run делать только вызов. Но это работает только при максимальном внешнем контроле, поэтому лучше перекрыть прямой доступ к этой части фреймворка и требовать передачи класса демона в свой прокси-код. Всю работу по запуску сделает он, а написать неправильно — просто нельзя либо очень трудно. Наверное это и есть «синтаксический уксус ©».
В другом проекте вся бизнес-логика находилась внутри базы данных и доступ к ней осуществлялся исключительно через вызовы процедур. Организация доступа к базе данных была реализована в ограниченном варианте который не позволял делать обычные sql команды. Поэтому за этим аспектом не нужно было следить.
В целом можно сказать так: Создавайте свои системы таким образом чтобы правильные вещи делались легко и естественно, а нежелательные были невозможны или делались с большим трудом.
upd Здесь идет речь не о контроле за людьми! Это очень важно. Не нужно их держать на поводке и контролировать каждый их шаг. Пусть они спокойно коммитят свой код, а вот уже на ревью, выявив недостатки, код можно отправить на доработку.
Я думаю что у многих найдется что сюда добавить. Буду рад услышать ваш опыт.
p.s. vasfed спасибо за правки и доработки.