Очень-очень давно в нашей тогдашней команде. Разработка с тестированием бурно обсуждали всяческие соглашения: как тестировать задачи, какие шаги включать в подготовку релиза, кто должен выполнять процедуру A, обязательно ли следовать правилу B, и тому подобное.
Чтобы было легче говорить о таких штуках, я тогда напряглась и сформулировала что-то вроде манифеста: четыре вещи, о которых стоит заботиться в первую очередь, и систематически пренебрегать которыми нельзя.
Публикую этот манифест с минимальными правками.
В письме-оригинале этот раздел назывался “Лирическое оступление про приоритеты и вообще о жизни”
Когда мы обсуждаем какие-то процедуры, правила и т.п., то хочется иметь критерии оценки, более объективные, чем “нравится-не нравится”. Мы – разработка – полагаем, что в нашей с вами работе существенные ценности такие:
Эти ценности несравнимы между собой, их приоритет друг относительно друга может меняться в зависимости от конкретных обстоятельств, а другие ценности вторичны по отношению к этим.
Таким образом:
Если какая-то процедура позволяет сэкономить человеческие усилия, улучшает наше качество, не портит скорость и аудируемость – это отличная вещь, надо пользоваться.
Если для обеспечения приемлемого качества и скорости постоянно требуются нечеловеческие усилия (ненормированный рабочий день, неестественно повторяющиеся автоматические действия, необходимость “в голове” отслеживать слишком многое) – это повод к тому, чтобы улучшить рабочий процесс. Автоматизировать, распределить ответственность и т.п.
Если какая-то методика требует значительных затрат времени, не влияет на качество и ухудшает скорость – возможно, нам такая методика не очень нужна.
Мы стараемся устраивать нашу работу в соответствии с этими приоритетами. Для улучшения качества мы пишем тесты (они прогоняются после каждого коммита), перерабатываем устаревший код, делаем мониторинги. Код для крупных задач обязательно тщательно ревьюится, и весь код без исключения критически читается несколькими разработчиками. По возможности мы автоматизируем “нечеловеческую” работу.
Несмотря на все это и многое другое, в нашем коде бывают ошибки, и часть из них пробирается в продакшен, и это неизбежность, к сожалению. Но если у вас есть идеи, как мы могли бы эффективно расправиться с какими-то типичными проблемами – welcome. И если у вас есть предложения, как можно сделать тестирование более эффективным – тоже welcome. Вот лично у меня есть несколько мыслей. [дальше шла специфика сервиса]
Сейчас, спустя одиннадцать? двенадцать? лет, этот манифест все еще нравится.
В частности, мне симпатичны:
Вот такие принципы здоровой разработки программного обеспечения.
И большое спасибо всем моим тогдашним коллегам. Вдохновение для этого манифеста пришло из работы с вами. Это было круто!