В книге Закон малинового варенья и еще 103 секрета консалтинга, которую мне подарил замечательный друг Андрей Рынкевич, есть глава о важности развития способности мыслить парадоксально. Найти в старом, что-то новое, увидеть нестандартное решение, придумать что-то свежее можно только попав в условия парадокса. Для меня парадокс граничит с провокацией, которая также помогает выйти за границы сложившегося, расшатать устои. Я люблю подвергать сомнению привычные схемы, проверяя их прочность с помощью юмора и, да что уж тут скрывать, легкого троллинга.

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

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

На докладе я не врал, первые версии Учи.ру действительно были без тестов. Мы сделали не меньше пяти разных вариантов, ходили в школы, постоянно все переделывали, тестировали вручную и снова в школы. И я рад, что мы прорвались. Компания растет, задачи все интереснее и если бы не срезали углы, не факт, что получилось бы.

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

"A bad design with a complete test suite is still a bad design", @richhickey

— DHH (@dhh) April 29, 2014

Таким образом я и Дэвид. Или Дэвид и я, как будет менее провокационно? Мы вообщем с Дэвидом считаем, что хороший дизайн приложения важнее покрытия тестами. А что такое хороший дизайн? Хм. Кто знает.

PS: Чтобы пост был не совсем бесполезным поделюсь, что мы используем CirleCI - хороший, стабильный CI, есть бесплатный план с одним контейнером. Вообще я эпизодично пользовался и семафором, и трависом, и вексором, и дженкинсом, они сейчас все хорошие. Но для нас CircleCI - проверенно хорош.

Tweet