Вы сталкивались с таким сценарием раньше?
- Команда разработчиков продолжает сокращать сроки поставки функций
- Он отвечает, отправляя код, нагруженный техническими долгами.
- Этот технический долг никогда не выплачивается, потому что нет времени на его очистку.
- Перейти к 1 несколько раз
- Технический долг становится все хуже, пока не начинает фактически блокировать новые изменения или ломать вещи в производстве
- Команда разработчиков проводит кампанию по серьезному изменению дизайна, потому что текущая система уже не подлежит сохранению.
- На это уйдет много времени, но бизнес-команде обещают в конце концов технологии, неотличимые от магии.
- Повторная арка выполняется путем приостановки всего остального.
- Это занимает гораздо больше времени, чем предполагалось, и дает гораздо менее впечатляющие результаты.
- Перейти к 1 несколько раз
- Бизнес-команды теряют всякую веру в команду разработчиков и возвращаются к использованию Excel / Компания закрывается
К сожалению, описанная выше последовательность событий слишком распространена. Хотя существует множество причин и множество соответствующих способов предотвращения этого, я хочу посмотреть, что могут сделать команды разработчиков. Самая большая проблема для меня - это повторяющиеся большие перестановки. Как и в случае стартапов, большие редизайны в большинстве своем терпят неудачу. Им не удается ограничить объем, они не могут выполнить свои обещания, они терпят неудачу в повышении уровня возможностей организации, часто они вообще не могут быть завершены. По-настоящему гибкая организация должна быть удивлена, если обнаружит, что нуждается в таком крупном разовом изменении - что бы ни случилось с поиском и постепенным внедрением решений!
Однако есть кое-что, что команды разработчиков могут сделать, чтобы предотвратить это, а именно принять культуру непрерывного рефакторинга. Непрерывный рефакторинг может сделать команду разработчиков более гибкой, чем спринты, схватки или ежедневные встречи, за счет улучшения того, с чем они работают, то есть базы кода.
Мартин Фаулер написал отличную книгу и множество статей о рефакторинге (включая это интересное в сторону об этимологии этого слова), поэтому я предполагаю, что мы все знаем, что это такое. Давайте разберемся, почему я рекомендую непрерывный рефакторинг.
Зачем проводить непрерывный рефакторинг
Постоянно поддерживает высокое качество кодовой базы
Для разработчика программного обеспечения хорошо поддерживаемая кодовая база - это его собственная награда - например, личная Monalisa или дзен-сад. В нем приятно работать, его легко понять и понять, и команда с таким единорогом, как правило, будет более продуктивной.
Делает всех знакомыми с кодом
Программное обеспечение никогда не бывает «готовым», поэтому важно постоянно обновлять его «текущую» форму, чтобы с ним эффективно работать. Если каждый член команды возится с базой кода в поисках возможностей для улучшения, велика вероятность того, что более одного человека видели неясные побочные эффекты этого и могут помочь в случае, если с этой частью что-то случится. Это особенно актуально для больших кодовых баз, которые создавались за долгое время и видели, как несколько членов команды приходят и уходят. Рефакторинг и готовность к работе - два самых мощных инструмента, которые я могу придумать для распространения обширных знаний обо всех аспектах кода среди всех членов команды.
Устанавливает новое поколение архитектуры
Всем нужны микросервисы, верно? Если вы оседлали монолит из большого глиняного шара, скорее всего, вам не терпится разобрать его на части. Но как это сделать безопасно? У большого волосатого зверя есть щупальца, о которых вы, вероятно, даже не подозреваете. Кто знает, что будет делать отламывание модуля? Фактическое разделение достаточно просто, это непредсказуемое выпадение, которого мы должны опасаться - мы не хотим в конечном итоге получить распределенный большой шар грязи!
Есть один верный способ настроить это - начать рефакторинг этой устаревшей базы кода. Вы узнаете о коде то, чего не знали, появятся ранее запутанные границы, зависимости между различными частями станут более ясными, ошибки будут обнаружены и устранены, и будет произведено незначительное улучшение производительности. Вы разовьете более глубокое понимание того, куда идти, чем это было бы возможно в противном случае. Кто знает, может быть, в конце концов, вам не понадобятся микросервисы, потому что у вас будет потрясающий, сверхэффективный монолит.
И что самое главное, бизнес все это выдержит!
Даже когда мы работаем с новым кодом, непрерывный рефакторинг выявляет новые границы и поведение в нашем коде, и это понимание делает более масштабные архитектурные изменения гораздо более вероятными, потому что мы не исходим из требований «это-отстой-давай». переписать все », но исходя из реальных признаков, возникающих в кодовой базе в результате попыток решения реальных бизнес-задач. Опытные разработчики обычно могут идентифицировать эти шаблоны и настроить команду на серьезные изменения (например, разделить этот модуль на отдельный сервис, давайте поместим автоматические выключатели в центральную клиентскую библиотеку). Когда все в команде занимаются рефакторингом, все больше и больше людей начинают получать шестое чувство ощущения предстоящих изменений.
Как проводить рефакторинг непрерывно
Есть много способов сделать это и множество советов в Интернете. Я хочу сосредоточиться на двух аспектах: техническом и организационном.
Напишите тесты
Часто игнорируемое дополнение к этому часто повторяемому совету - пишите тесты. Рефакторинг не находится в каком-то техническом вакууме - это средство для достижения организационной цели. Я читал об этом с разных точек зрения, но для меня цель - увеличить скорость доставки. То, что мы делаем сегодня, должно сделать будущие изменения быстрее / проще / безопаснее. Теперь, если мы согласны с тем, что рефакторинг сегодня облегчает будущие изменения, то нетрудно понять, что наличие тестируемого кода облегчает рефакторинг. Нам не нужно думать только об изменении кода, мы можем думать и о добавлении тестов. Возможно, мы не будем проводить рефакторинг, но из-за дополнительных тестов любой другой сможет безопасно сделать это завтра.
Написание тестового ИС рефакторинга
Как найти время
«У нас никогда не будет на это времени». Я согласен, и это печально, но факт. Чтобы получить эксклюзивное время на рефакторинг, требуется большое доверие, особенно в отношении частей кода, которые на самом деле не сломаны (но могут быть улучшены).
Я предпочитаю широко популярный подход «буфер ваших оценок». Попросите дополнительный день, чтобы закончить задание. В любом случае легче реорганизовать то, что вы собирались изменить, заинтересованные стороны с меньшей вероятностью будут жаловаться на день или два такой оценки, и мы сможем постоянно отказываться от мусора. Это проще, чем выделять время на «только технические» изменения отдельно.
Это также установило границы того, сколько времени мы потратим на рефакторинг - это улучшит ситуацию, но только в рамках данной бизнес-функции, через которую это финансируется. У нас гораздо меньше шансов вскипятить океан в таких ситуациях, потому что есть более крупная цель, которую необходимо достичь - вы реорганизуете только то, с чем вы работаете в данный момент.
Заключение
На мой взгляд, несправедливо ожидать, что команда очевидно будет проводить непрерывный рефакторинг. Это неочевидно и редко является приоритетом перед лицом необходимости предоставления функций. Это культура, и, как и все культуры, о ней следует открыто говорить, обсуждать и поощрять. Если мы можем интерпретировать нашу работу с точки зрения делать вещи немного лучше каждый день, выгоды складываются очень быстро.
Если вам понравилась эта статья, вы можете подписаться на мой список рассылки, чтобы быть в курсе последних новостей.
