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

Запуск не начинается с тестировщика.

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

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

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

Как мы создаем программное обеспечение сегодня

Мы так торопимся, что всегда опаздываем. Нет времени на испытания. Нет времени на модульное тестирование. Нет времени на рефакторинг.

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

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

Итак, мы создаем программное обеспечение следующим образом:

* Быстро и грязно

* Не быстро, все равно грязно

* Быстрый и счастливый диагональный путь протестирован

* Все остальное считается крайним случаем. (Нет такой вещи, как пограничный случай.)

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

Вы должны исключить из своих оценок объем, а не качество.

Что вы знаете о качестве компонента, над которым работаете?

* Вы знаете, что он хрупкий, но не хотите его трогать, потому что он очень хрупкий.

* Вы сделали это давно, вы едва коснулись этого, это должно сработать.

* Вы не знаете, что он хрупкий.

* Нет тестов, и никто не может протестировать и показать, насколько он на самом деле хрупок.

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

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

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

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

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

Вы никогда не исправите это позже

Вы готовы изменить ситуацию?

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

Какими должны быть ваши первые шаги к созданию более качественного кода?

Реализация ведения журналов и оповещений

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

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

Создайте групповой распорядок для просмотра предупреждений и сообщения о них

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

Просто нажмите кнопку «Сообщить о заявке» или кнопку «Отметить как известное». И если вы заинтригованы, вы, вероятно, исправите один или два из них.

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

PM будет кричать на нас, что мы работаем не над приоритетными задачами, а над мелкими предупреждениями.

Команда со всеми ролями "М" с этим согласна.

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

Вот и все, очень просто.

Начать очистку журналов и оповещений по одному

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

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

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

Удалите все пустые операторы Try-Catch и дайте ему упасть!

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

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

Начните писать модульные тесты прямо сейчас

Я серьезно. Вы сейчас работаете над каким-то кодом. Тогда ничто не помешает вам написать модульный тест.

О, я вижу! Нет готовой инфраструктуры для модульного тестирования, не так ли? Ну давай же! Вы все равно отложите эту функцию подражателя.

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

Запустить TDD для исправления ошибок

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

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

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

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

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

Нарисуйте дорожную карту покрытия

Автоматизация тестирования и технический долг имеют схожие трагические судьбы — они никогда не начинаются, потому что «мы никогда не сможем охватить все, мы никогда не сможем все очистить, это слишком много накладных расходов. У нас нет на это времени».< /p>

Послушайте: вам не нужно все автоматизировать!

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

Вы видите, к чему я клоню.

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

Соберитесь вместе перед вашими высокоуровневыми и низкоуровневыми архитектурными схемами. Их нет, не так ли? Или те, что существуют, это фотография доски, сделанная 2,5 года назад? Я знаю.

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

В конце концов, вы же команда разработчиков, верно?!

Не стремитесь к полному охвату — вместо этого стремитесь к низкому риску и высокой достоверности

Создавая схему современной архитектуры и инфраструктуры, добавляйте примечания или кружки, выделяйте жирным шрифтом или красной краской все места, которые находятся:

* Критично для вашего бизнеса и программного обеспечения

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

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

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

* Не попадайтесь в ловушку «это слишком много! Мы должны остановить всю остальную работу, чтобы покрыть все это!» Вам не нужно охватывать все это сразу. Но вам нужен план. Теперь откройте другую доску и начните писать свои цели тестирования. Примеры:

* Учитывайте все запросы API выборки данных на предмет успешных и неудачных, чтобы вы знали, что вы не отправляете неверные запросы, а в случае сбоя это происходит из-за поставщика.

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

  * Определите пробки и решите, как вы собираетесь их распутывать.

  * Планируйте делать это правильно. Ваш быстрый и грязный код останется грязным из-за грязных тестов.

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

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

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

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

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

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

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

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

Затем подумайте, как можно автоматизировать это тестирование.

Вы не можете прогрессировать в Quicksand, и только вы можете выбраться оттуда

Заканчиваем. Если вы полжизни работаете на месте без тестирования, код в плохом состоянии, и у вас нет времени, вы продолжаете идти на компромиссы, потому что «у вас нет времени». Вы не совсем довольны или, по крайней мере, довольно равнодушны — они платят, это их решение, а не ваше решение.

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

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

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

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