Как стать автором
Поиск
Написать публикацию
Обновить

Человеческий фактор или «соглашения не работают»

Время на прочтение4 мин
Количество просмотров3.7K
Представьте ситуацию. Вы со своей командой, после очередной итерации, обсуждаете слабое покрытие кода тестами и решаете что с понедельника текущего момента все пишут тесты как для нового кода, так и для всплывающих багов. Это кажется разумным (кто-то вспоминает последний неудачный деплой), все поддакивают и довольные расходятся с мыслью, что ну вот теперь то у нас точно все будет отлично. Приходит время следующего собрания на котором во время вопроса «а как у нас с тестированием» большинство отводит глаза. Результат ясен, все осталось по старому.

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



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

Что объединяет эти ситуации? Недостаточный контроль за процессом. Контролировать можно совершенно по разному и ниже я хочу поделиться своими мыслями по поводу того как лучше это делать и почему.

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

Примеры:
Внешние ключи в базе данных — внутренний контроль.
По умолчанию «все запрещено» с помощью acl — внутренний контроль.
Менеджер смотрит коммит к тикету — внешний контроль.
Статический анализ кода — внешний контроль.

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

Внутренний контроль



— База должна самостоятельно поддерживать свою целостность (fk, check) и быть максимально строгой в отношении входных данных. Тогда большинство ошибок разработки будут выявлены на самых ранних этапах.
— Всегда используется принцип «все что не разрешено — запрещено».
— При проектировании внутренних компонентов нужно стремиться к минимизации правил которых придется придерживаться в процессе и спользования. Иногда даже ценой потери гибкости (но так чтобы это не стало проблемой и препятствием). И философия python в помощь.
— Пользуйтесь моками в тестах только в случае острой необходимости (внешняя служба), иначе на каждую строчку в реальном коде придется менять несколько строк в тесте, и в конце концов это станет невыносимым бременем для всей команды.
— Внутренние библиотеки (в отличие от кода самого приложения) можно менять только при согласовании с главным разработчиком. Тут без контроля не обойтись, но можно частично решить проблему создав хуки в системе контроля версий, которые не будут давать закоммитить код по нужным вам условиям.
— Когда при разработке постоянно приходится держать в голове вещи которые «нельзя забыть» то скорее всего что-то не так. Если невозможно сделать рефакторинг который позволит об этом не думать, то нужно сделать хотя бы так чтобы код сам проверял свои требования и сообщал о них (например выкидывая исключения).
— Код который пишется или используется первый раз (первый демон, первое использование acl или любого другого компонента) должен быть написан очень качественно, ведь в дальнейшем все будут ориентироваться именно на него.
— Программирование в парах повышает качество кода.

Внешний контроль


— По мере возможностей нужно меняться задачами и не попадать в ситуации когда «понимает только Вася, но он болеет вторую неделю».
— Организуйте процесс разработки так, чтобы весь код проходил через «главного разработчика». Используйте не соглашения, а правила самой VCS, дающие доступ на запись в trunk (master) только ему.
— Используйте непрерывную интеграцию. И красный флаг не должен становиться нормой.
— Выработайте требования к коду и проводите ревью.

Конечно же это не все. Ниже несколько примеров применения описываемого подхода в реальном коде.

У нас в проекте куча демонов, фреймворк предлагает наследовать класс и переопределить метод run. Естественно, что в этом методе можно написать целиком код небольшого демона (что на практике часто и делали). Добраться до такого кода и протестировать его — почти нереально. Логичное решение — попросить всех писать отдельные классы для каждого демона, а в методе run делать только вызов. Но это работает только при максимальном внешнем контроле, поэтому лучше перекрыть прямой доступ к этой части фреймворка и требовать передачи класса демона в свой прокси-код. Всю работу по запуску сделает он, а написать неправильно — просто нельзя либо очень трудно. Наверное это и есть «синтаксический уксус ©».

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

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

upd Здесь идет речь не о контроле за людьми! Это очень важно. Не нужно их держать на поводке и контролировать каждый их шаг. Пусть они спокойно коммитят свой код, а вот уже на ревью, выявив недостатки, код можно отправить на доработку.

Я думаю что у многих найдется что сюда добавить. Буду рад услышать ваш опыт.

p.s. vasfed спасибо за правки и доработки.
Теги:
Хабы:
Всего голосов 56: ↑53 и ↓3+50
Комментарии42

Публикации

Ближайшие события