Саша Раковский

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

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

Тут есть несколько решений:

1. Найти команду единомышленников.

В общем случае, гиблое дело. Таких команд исчезающе мало. Как только они появляются, они за пару месяцев стаффятся на 100%, и народ там сидит годами, потому что обратно в дикий запад без тестов и внятного дизайна не хочет никто. Текучки нет, залететь в такую команду - редкая удача.

Тут можно ещё сходить на иностранный рынок, там с этим получше. Но и там это тоже долгие поиски, к тому же этот путь все же подойдёт далеко не всем.

2. Сделать команду единомышленников.

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

3. Огораживание.

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

Ещё лучше, если в этом есть архитектурный смысл, чтобы это был вообще отдельный микросервис. Не обязательно работать на этом сервисе в одиночку: если у вас есть единомышленник, попытайтесь затащить его к вам. Это позволит вам защитить команду от Bus Factor или просто сходить в отпуск, не влияя на расписание команды.

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

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

Что делать, если отгородиться не удаётся?

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

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

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

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

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

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

Про бюрократию 2

Пытался вчера уместить всю мысль в лимит поста в телеграме, но, по итогу, получилось скомканно. Поэтому немного раскрою мысль.

Для затравки расскажу историю, которая меня лично очень развеселила.

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

Десять дней до ответственных лиц пытались достучаться: заходили через разработку, потом через сопровод и, наконец, через бизнес достучались.

Сели решать. Ну очевидно, что делать - надо просто повысить rateLimiter. И тут неожиданное сопротивление от сопровода: говорит, только не пугайтесь, для таких RPS нужно 300 млн денег. Зачем? Ну, для троекратного резервирования на случай трындеца. Все в хохот: трындец уже случился, у банка огромные операционные риски. Тот ни в какую: у меня регламент - держать троекратный запас железа от максимальной нагрузки. Под ответственность бизнеса уломали.

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

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

Цирк? Не то слово.

В прошлом посте я написал, что бюрократия - это лишние процессы, люди, звенья и препятствия.

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

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

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

Чего нужного не оказалось в этом процессе? Банального мониторинга, который бы подсветил сотрудникам, что у них очень серьёзные проблемы. То есть, он по регламенту тоже был, но не работал, потому что ответственность была за то, чтобы он был, а не за его работоспособность.

Взрослые процессы.

Главная проблема бюрократии в том, что она часто воспринимается, как должное. Этакий "взрослый" процесс для серьёзных дядек и тётек. Бюрократию считают неизбежной и правильной в работе с финансами и иными "серьёзными" доменами.

Но не дайте себя обмануть, аура серьёзной взрослости тут совершенно незаслуженная. Гораздо ближе тут слово "цирк", где люди втыкают себе и другим палки в колёса, просто потому что.

Про Faux Agile.

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

Итог двух постов.

Социология и психология достоверно важнее техники. Нужны хорошие IT-процессы? Подождите с автотестами и архитектурой, исправьте лучше культуру и психологическую безопасность. Наша индустрия - это не столько про компьютеры, сколько про людей. Individuals and interactions over processes and tools.

Про бюрократию

Одна из самых вопиющих историй, известных мне - это история про катастрофу шаттла Колумбия. 15 января 2003 при взлёте шаттла кусок термоизоляционной пены оторвался от конструкции крепления внешнего бака и ударился о термоизоляцию крыла. Это было замечено на одной из камер, после чего была создана рабочая группа по расследованию инцидента, которая 2 недели пыталась выяснить, была ли безопасной дальнейшая миссия шаттла или нет. За это время разными сотрудниками НАСА было сделано 3 безуспешных попытки запросить снимок поврежденного крыла с телескопов и спутников, а всего комиссия по расследованию обнаружила 8 упущенных возможностей по предотвращению катастрофы.

После 2 недель безуспешных попыток подтвердить, что продолжение полёта не безопасно, рабочая группа была вынуждена прийти к выводу, что инцидент не несёт угрозы миссии. В итоге, 1 февраля 2003 года шаттл вошёл в атмосферу, где разрушился, унеся жизни 7 членов экипажа.

В чем секрет единорогов?

Когда-нибудь задавались вопросом, как маленькие компании "единороги" под орех разделывают гигантские корпорации на их же поле? Как лидеры компетенций с огромными бюджетами и наработанной клиентурой уступают в гонке небольшим новым коллективам?

Когда я работал в Dell, я слышал от топ-менеджмента, что даже самые смелые инновации аутсайдеров рынка очень быстро копируются лидерами и приводят лишь к росту рыночной доли лидера.

Звучит логично, но по этой логике условная Nokia должна была скопировать iPhone и оставить Apple позади. Почему этого не произошло ни со Space X, ни с Tesla, ни с Uber? Как эти компании выбились в лидеры рынка, когда на рынке так много уже состоявшихся конкурентов, которым было бы достаточно просто скопировать новые идеи?

О чем тогда говорили менеджеры Dell, если у единорогов получилось? Конкурентом Dell в тот момент был собственно этот самый "единорог", Amazon, который, вообще говоря, уже сам был огромной корпорацией и лидером рынка.

Так в чем тут дело?

Я уже замечал в предыдущем посте, что из всех замеренных Дорой метрик, самой важной оказалась орг. культура: в полтора раза важнее "элитных" IT-процессов. Как они мерили?

Существует замечательная типология организационной культуры, разработанная социологом доктором Роном Веструмом, где все организации делятся на три типа:
- патологические,
- бюрократические,
- творческие (creative).

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

Как это работает?

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

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

И именно отсутствие лишних действий, препятствий, людей, процессов так выгодно отличает творческие коллективы от бюрократических. В этом крылся секрет Lean Manufacture - процесса производства, который в 70-80 годы позволил японским автопроизводителям завоевать американский рынок.

В чем смысл слова Lean ("худой")? В том, что вы отрезаете всё лишнее. Заметная часть бюрократических организаций - это бывшие творческие коллективы, обросшие лишними процессами.

Вместо итога.

Это уже второй пост подряд про Lean-мировоззрение: про борьбу с человеческим расточительством и лишней работой. Именно идеи Lean-подхода лежат в основе Agile, XP, CD и всего другого хорошего, что произошло с нашей индустрией за последние 30 лет.

Для самостоятельного изучения: шедевральное интервью с Роном Веструмом от одного из авторов DORA (1, 2) смотреть обязательно.

Про лапки 🥰

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

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

Или всё-таки умеем?

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

Не хочу долго мусолить методы сравнения, но из уважения к читателям укажу основные метрики, которые мы знаем:

- строчки кода
- сторипоинты
- тест-кейсы
- количество фич
- соотношение новой работы и остальной работы
- business value
- dora-метрики
- интуиция.

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

Дурацкая импотенция

Вот эта вот скорость - это далеко не единственная штука, с которой у нас есть проблемы. Мы отвратительно оцениваем объём работ, плохо прикидываем business value той или иной фичи, ужасно справляемся с big upfront design, простите мне этот англицизм. И, если кто-то утверждает, что он все это умеет, то он или гений, или заблуждается, или просто врёт.

Про целеполагание

И во всей этой импотенции обязательно надо понимать: цель измерений-то какая?

Вот у вас есть быстрая команда, которая фигачит в два раза быстрее остальных. А толку, если она фигачит не туда? Это прям такая классика, когда 2/3 разработанных фич пользователями либо используются крайне редко, либо не используются вообще. Есть даже название такому софту: bloatware.

То же самое касается и оценки объёма работ. Вот вам дали ТЗ. Допустим, сами пользователи дали. Вы оценили: через год будет готово. Ну вот даже если вы прям угадали, и через год все готово. Вот даже если у вас супер быстрая команда, которая сделала это в 2 раза дешевле остальных. Ну вы все равно упираетесь в тот факт, что даже сами пользователи не знают, что им реально надо. И через год у них за пол стоимости есть функционал, 2/3 из которого можно было не делать.

Дежурный пинок водопада

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

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

К чему я это все?

Да к тому, что без качественной работы над скоупом все эти спекуляции про продуктивность, тесты, ДДД, рефакторинг, чистый код и т.п. - это все разговоры не туда, имитация бурной деятельности.

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

Куда копать дальше?

Три года назад, когда моя голова была забита всей этой экстремалкой, CD и прочим аджайлом, вот этот доклад для меня перевернул все. Gojko Adzic - самый главный амбассадор борьбы с работой не туда, поэтому рекомендую ознакомиться с его работами.

Эти же идеи транслирует и Эрик Рис в своём Lean Startup. У него есть одноимённая книга, но для быстрого ознакомления рекомендую вот этот доклад.

Ну и из всей горы экспертов, советов и методологий наиболее положительно, конечно, выделяется DORA со своими Accelerate и State of Devops. Эти  просто померили, что влияет на успехи компании и предикторы этих успехов, а что - нет. Никаких вам умозрительных пальцесосаний, сухая конкретика.

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

Ребята очень старались сделать всё по уму, подготовили опросник, тестировали его на добровольцах. Обещают выложить сырые данные, которые мы, быть может, даже сами потом поинтерпретируем как-нибудь.

Время прохождения опроса - небольшое, всего 20 минут. Залетайте.

Накатал статью про архитектуру приложений и про подходы в нашей команде.

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

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

Но я не раз видел, как людей раздражают вещи, которые я считаю хорошим кодом: люди злятся на маленькие методы по 3 строчки, на n^2 при обходе десятка объектов, на логику в доменных классах и сложные полиморфные иерархии классов вместо обычного процедурного спагетти. Более того, я не раз видел, как людей сначала раздражало одно, а через пару лет ровно противоположное.

Конечно, я уже не перестану верить в эти идеи, я видел, как они работают, своими глазами. Но абсолютно точно, я всегда буду рекомендовать всем сосредоточиться в первую очередь на том, что надежно работает: хорошая культура в организации, Continuous Delivery, слабосвязанная архитектура и автоматическое тестирование. А DDD всякие - да, круто, конечно, но лучше обратите внимание на тесты. Они - ваш залог того, что вы точно сможете к этому DDD прийти в любой момент.

В комментариях к прошлой статье один наш с вами коллега написал очень интересное про свою компанию, замечательный пример из лиги Elite-performers в терминологии Dora. Я списался с ним лично и расспросил про его работодателя поподробнее. И там прям есть, что обсудить.

Что выдающегося?

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

На всю компанию одна монорепа с одной веткой - мастером. Все пушат в мастер ежедневно без ПР (кроме новичков). После коммита сервис проходит е2е тесты и улетает в пром. Время от коммита до прома 3-4 минуты для маленьких сервисов. Для самых больших - от 40 минут до нескольких часов. В сутки компания выкатывает в пром 60+ релизов на все сервисы.

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

Почему это круто

Для большинства разработчиков во всем мире такие процессы покажутся какой-то несусветной дичью. Но весь цимес в том, что это дефолтные процессы для айти-элиты. Они давно описаны в литературе и зафиксированы в отчётах. Например, общее число респондентов State of Devops, которые подтвердили такие процессы в своих компаниях, составляет около 7% (2018 год).

Уже больше десяти лет мы видим в ежегодных отчётах State of Devops одну и ту же картину: чем меньше время от коммита до релиза и чем чаще поставки, тем выше стабильность систем и выше экономические и нефинансовые успехи компании.

В общем, в BrightData процессы топ, прям по книжечке Accelerate. Если хотите работать, как элита, ориентируйтесь именно на такие компании.

Как сделать такое же?

Вам нужны:
1. Архитектура, позволяющая командам тестироваться (и, как следствие, релизиться) независимо друг от друга. Если вы не можете задеплоиться, пока не потеститесь вместе с другой командой, никаких нескольких релизов в сутки не будет точно.
2. Полностью автоматическое тестирование. Успеть за час (да даже за день) руками протестить все, очевидно, невозможно.
3. Лидеры, которые умеют делать первые 2 пункта. Если они не умеют, то ничего не получится. Они будут нанимать не тех людей, организовывать не те команды, ставить не те задачи.

Ведро дёгтя.

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

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

Насколько это важно?

Для сотрудника - однозначно важнее, чем все эти элитные процессы. Лучше работать в психологическом комфорте, но в менее удачных процессах, чем в постоянном стрессе, но в лучших в мире процессах.

А для компании? Как выяснилось в разных независимых исследованиях, для компаний - тоже. У нас есть 2 основных источника, которые подтверждают, что культура важнее всего. Первый - исследование Гугла под названием "проект Аристотель", которое выяснило, что самый главный предиктор успеха команды - психологическая безопасность. Другой источник - тот же самый State of Devops, который показывает (см изображение), что коэффициент корреляции между культурой и успехами организации в полтора раза выше, чем между IT Performance и успехами организации.

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

Наткнулся недавно в очередной раз на не очень корректное использование термина CI/CD и опять расстроился. Я планировал отложить этот пост на попозже, когда публика, как мне покажется, будет готова. Но душа просит, поэтому накатал очередной разбор на хабр.

PS: ну, судя по комментариям, статья зашла, как надо.

Новое видео, где легенда выдаёт базу. 🔥

https://youtu.be/37bdV1Ibc74?si=30zzcEGjjMEDMxBO

Продолжение.

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

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

Можно ли выкарабкаться, если все тесты на моках, но вы осознали свою ошибку? Да, но заметная часть сьюта подлежит переписыванию. Это обычно очень много работы.

Итог.

Это 4 основных пункта, накосячив в которых, вы, скорее всего, выстрелили себе в ногу. Если хотя бы одно не выполнено, то не видать вам полного автотестирования ещё очень-очень долго.

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

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

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

1. Все виды тестов должны писать именно разработчики.

К этому экстремальщики пришли ещё в нулевые, о чем и написали в поворотной для индустрии книге Continuous Delivery. Потом это подтвердилось в исследованиях DORA. И, например, в гугле оно сейчас именно так.

Почему так? Потому что тест, поведение и код связаны между собой один к одному. Меняя одно, вы просто обязаны поменять другое

Я не раз видел, как технические директора нанимали автотестеров в надежде, что те полностью автоматизируют им регресс. К сожалению, ни в источниках, ни в своём опыте я не встречал устойчивого процесса поставки с полностью автоматическим тестированием, реализованным силами автотестеров. Там всегда часть регресса будет делаться руками.

Если вы признали ошибку, есть ли вариант выкарабкаться?

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

2. Тесты - командная практика.

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

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

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

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

3. Безукоризненная дисциплина.

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

Решение должно быть волевым: без тестов фича не готова. Но, если честно, я знаю всего 2 варианта, как этого добиться.

Либо адамантиевая дисциплина и несгибаемая воля лида и команды, не позволяющие, невзирая ни на какие опоздания по срокам, сдвинуться с места, если тесты не написаны.

Либо более надёжный, но технически менее простой вариант - тдд. С тдд вы никогда не попадёте в такую ситуацию, когда все работает, и осталось только покрыть тестами, но между тестами и новой фичей вы вынуждены выбрать новую фичу из-за давления сроков и бизнеса.

Есть ли возможность выкарабкаться, если вы признали свою ошибку, и теперь у вас, например, тдд? Только когда вы, наконец, добьете те тесты, которые вы не написали за все время до.

4. Несостоятельные тесты.

Вот допустим, что все разработчики пишут тесты, покрытие 100%. Значит ли это, что у вас полностью автоматическое тестирование? Нет.

Неделю назад меня один читатель попросил высказать мнение про оценки, сторипоинты и майки. Я начал писать и, как обычно, настолько увлекся душным обзором источников, что хватило на целую статью на Хабр.

Ну и, как обещал в статье, эксклюзивно для канала еще добавлю про личный опыт, связанный с оценками.

Что подсказывает опыт.

2 года назад нашей команде пришлось поработать в заказной разработке на бюрократическую организацию.

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

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

Сегодня в своей работе мы почти ничего не оцениваем. На горизонте в 2-3 недели нам и так все неплохо видно, а дальше планирование особо смысла не имеет, потому что слишком часто меняется скоуп работ.

Лишь периодически, чтобы понять, успеваем мы или нет, мы прикидываем прогресс больших фич. Ну и иногда короткий вопрос разработчику об объёме работы помогает нам понять, за что браться сначала. И тут как в школе: сначала быстрые задачи, потом те, что побольше.

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

Вот и вышла третья и заключительная часть из цикла по архитектуре.

Приятного чтения!

Только завёл канал и тут же нашлись единомышленники из России, которых я до этого годами не мог найти днём с огнём.

https://t.me/ergonomic_code/598

Про мой любимый рефакторинг.

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

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

Ребята сели переписывать логику и весь день убили на написание класса, который бы за один раз бы все нужное взял из базы.

В конце дня я по-дружески интересуюсь, как у них дела. Ответ: тесты красные - пока ничего не получилось.

Вот именно, говорю, поэтому и не получилось. При правильном рефакторинге тесты, если и краснеют, то очень ненадолго.

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

Уходя домой, один из них сказал, что мы с ним за полчаса сделали то, что они не сделали за целый день.

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

В чем секрет быстрого рефакторинга?

В комбинации быстрых надёжных тестов и маленьких шагов, "от зелёного к зелёному".

Что это даёт?

Это не сделает всю разработку быстрее в разы, но вот обширные рефакторинги - легко. В результате разработчики перестают бояться рефакторинга и больше не говорят "это невозможно" там, где раньше это значило "надо переписать все".

Что требуется, чтобы вот такое делать?

А очень дофига для этого требуется, на самом деле. К сожалению, друзья.

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

Во-вторых, так рефакторить надо уметь. Я учился по книжкам и докладам. Моя команда училась у меня. И далеко не сразу научились.

Где на это посмотреть?

Три года назад, работая в моей любимой Айтентике, я на их канале опубликовал видео про рефакторинг, набравшее 70к просмотров, где разобрал пример такого рефакторинга из книжки Фаулера. Там эта мысль видна, но, к сожалению, она утонула в том, какой код авторы книги считали хорошим, а какой - плохим. Обратите внимание на запуски тестов и стиль работы с кодом.

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

Во-первых, в отличие от самой команды, топ-менеджмент обычно может управлять ресурсами в некоторых пределах, иногда может даже передоговариваться об изменении объёма работ или сроков. И это, на самом деле, самый мощный инструмент, которого, как правило, нет ни у кого, кроме топ-менеджмента. Если топ-менеджмент имеет такой ресурс, но срок все равно сорван, то винить кого-то, кроме него, трудно.

И тут стоит помнить про закон Фреда Брукса:

Adding manpower to a late software project makes it later.

Добавление рабочей силы в запоздалый программный проект делает его позже.

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

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

Когда речь заходит о причинах из п.2, где виновата сама команда, то даже тут вина будет скорее коллективная.

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

Итого.
1. К сожалению, топы будут виноваты почти всегда - либо вместе со своими командами, либо сами по себе. Но даже в случаях, когда инструментов у них в реальности не было, их все равно во всем обвинят.
2. У команд и лидов есть целый набор способов, как облажаться и подставить своего руководителя и организацию.
3. Программисты - как котята: косяков много, а ругать бесполезно.

Короче, если вам кажется, что это не вы, а ваш начальник, то, скорее всего, вам не кажется.

Кого винить в срыве сроков разработки?

Если честно, я был бы рад ответить - никого. Все же no-blame policy - это важная часть психологической безопасности в любой организации. К тому же, мы все с вами - взрослые люди и прекрасно понимаем, что обычно не очень важно, кто виноват в срыве сроков, но очень важно понимать, что теперь делать, чтобы из трудной ситуации выкарабкаться.

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

Поэтому, для понимания инструментов, доступных для управления сроками, я этот неприятный и конфликтный вопрос все же затрону.

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

Начнём с самого низа и до самого верха.

1. Разработчик.

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

Как правило, это происходит, когда разработчик:
- не понимает, как ему сдвинуться с мёртвой точки;
- потерял мотивацию и прокрастинирует;
- увлёкся и городит какой-то космолёт;
- просто, по своей природе, работает сильно медленнее остальных.

Также разработчик может делать все по красоте, но просто элементарно не вывезти объём работ.

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

Есть ли у тимлида тут инструменты? Конечно! Увлекшегося - осадить, упершегося - поддержать, прокрастинирующего - разгрузить и увлечь другой задачей, медленного - поставить на не срочные задачи, а перегруженного - усилить.

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

2. Тимлид и команда.

Лидер команды или сама команда могут стать причиной срыва сроков.

Обычно причины тут такие:
- разрабы тормозят (см. п. 1)
- неправильно расставили приоритеты и делали не то;
- погрязли в багах и легаси;
- просто не вывезли объём работ.

Виноваты ли в этом команда или лид? Если по-честному, то в первых трёх случаях - да.

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

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

Виновата ли команда в том, что они не вывезли нагрузку? Только если они не просигнализировали заранее о том, что объём работ превышает их возможности. Если сигналы были, а реакции не было, то вряд ли у команды были какие-то инструменты решить эту проблему.

Сама по себе, обычно, команда не управляет ни объёмом работ, ни сроками, ни ресурсами, а, значит, ничего с избыточной нагрузкой сама сделать не сможет: какой-то частью работ команде придётся пожертвовать ради другой.

3. Топ-менеджмент.

Очевидно, что за срыв сроков топ-менеджмент отвечает всегда. И отвечает головой. Но всегда ли он виноват? Какие есть инструменты у топ-менеджмента?

Не успела выйти первая часть архитектуры, а уже готова вторая. Третья пока в редактировании.

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

Приятного прочтения.

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

В статье было рассказано про первые публикации о Водопадах, про первый Скрам и XP, про появление Agile и его деградацию, про Continuous Delivery и движение DevOps, про самые свежие научные данные в области нашей индустрии.

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

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

Помню, пару лет назад, набирая свою команду, я просто скидывал своим новым сокомандникам оригинальный PDF, чтобы они могли пройтись по основным источникам и поизучать базовые идеи.

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