Рефакторы - необходимая часть кодирования. Даже самый лучший код потребует обновлений при достаточном количестве времени. Такова природа программного обеспечения.
Рефакторы также становятся бездонными ямами. То, что казалось небольшим рефакторингом, внезапно заставляет вас смотреть в ту и другую сторону с большим количеством вещей для рефакторинга.
Это похоже на попытку распутать веревку. Вы можете потратить все это время на то, чтобы развязать узел, подумать, что вы его развязали, а потом найдете еще один.
Или, может быть, вы были автором обзора кода. У вашей работы есть крайний срок, и ваш менеджер требует от вашего менеджера как можно скорее завершить ее. Тем не менее, ваш рецензент упоминает, что, по ее мнению, вы можете что-то реорганизовать.
Вы находитесь между тем, чтобы получить работу, над которой вы много работали, вовремя объединить или провести рефакторинг "по справедливой причине". Однако вы видите точку зрения вашего рецензента, и предлагаемые изменения сделают код немного лучше. Однако вас беспокоит, сколько времени могут потребоваться эти изменения.
Возможно, вы работали над важной диаграммой, чтобы показать сервисную архитектуру вашей команды. Вы изо всех сил пытаетесь понять это «правильно» и с трудом выбираете конкретную компоновку компонентов.
Во всех этих случаях мы можем применить некоторые идеи из Agile, чтобы помочь.
Таймбокс 101
Timeboxing - это то же самое, что и звучит: вы ограничиваете время, которое вы работаете над задачей. Простой.
Вместо того, чтобы работать до тех пор, пока что-то не будет «сделано», вы работаете над чем-то в течение фиксированного и согласованного количества времени и оцениваете выполненную работу. На этом этапе вы можете решить продолжить работу, предоставить то, что у вас есть, или отказаться от того, что вы сделали.
Определение, данное Agile Alliance, таково:
Вместо того, чтобы позволять работе продолжаться до тех пор, пока цель не будет достигнута, и оценивая затраченное время, подход с временными рамками состоит из остановки работы по достижении лимита времени и оценки того, что было выполнено.
Конечно, сейчас самое сложное - это не доводить дело до конца. Вместо этого новая трудность - это процесс оценки. Теперь вы должны решить, что делать с выполненной работой. Может возникнуть вопрос: «Достаточно ли хороша эта работа?».
Достаточно ли этого хорошо?
Один общий вопрос в любой форме ремесла: «Достаточно ли он хорош?».
И, к сожалению, это ТРУДНЫЙ вопрос.
При необходимости вы могли бы потратить ВСЕ свое время на создание лучшего дизайна. Вы можете просматривать и переписывать свою документацию каждый день и при этом находить лучший способ донести идею.
Музыканты хотят сделать, если эта мелодия достаточно хороша, чтобы передать нужные им эмоции. Художник также задается вопросом о цветах, которые он использовал. Писатель всегда задается вопросом, достаточно ли «настоящий» персонаж ...
Разрыв между «делать больше» и «достаточно хорошо» бесконечен. Вы все еще можете сделать больше.
Достаточно ли этого сейчас?
Однако у программного обеспечения есть уникальная временная составляющая. Мы постоянно вносим изменения. Создание программного решения - это все равно что рисовать картину, просматривая ее висящую на стене и зная, как ее перекрасят через несколько недель.
Имея это в виду, может возникнуть лучший вопрос о «достаточно хороших» проблемах. Вместо того чтобы спрашивать: «Достаточно ли этого», спросите: «Достаточно ли этого для прямо сейчас?».
Меня интересует этот вопрос. Когда я просматриваю пул-реквест, выполняю рефакторинг или даже проектирую архитектуру, этот вопрос определяет множество моих решений.
Я считаю, что этот вопрос наиболее полезен, и я ожидаю, что вы тоже ответите на этот вопрос, когда речь идет о реальном коде или документации, находящейся на рассмотрении. Кто-то написал код для пользовательской истории или ошибки и просит проверить код. Или, может быть, кто-то просит просмотреть свою диаграмму. Или кто-то писал RCA по проблеме, с которой вы столкнулись на прошлой неделе, и хочет получить информацию.
В таких ситуациях в игру вступает вопрос: «Достаточно ли этого на данный момент?». Предположим, рецензируемая работа выглядит неплохо. Он соответствует требованиям, но есть несколько вещей, которые могли бы быть лучше, но не обязательно должны быть. Вокруг одной конкретной темы могло бы быть больше ясности. Может быть более четкая абстракция. Может быть способ применить шаблон, который пригодится позже.
На этом этапе вы оцениваете компромиссы. Стоит ли переделывать или учитывать ваши отзывы? Возможно, вы сможете переделать - читайте: рефакторинг - эту функцию за несколько минут, но вашему коллеге может потребоваться больше времени. Возможно, переработка этого абзаца в документации отбросит остальные окружающие разделы, и тогда их придется переделывать и т. Д.
Теперь, конечно, много раз работу необходимо переделать! Это просто недостаточно . Ни сейчас, ни никогда!
Я обнаружил, что это особенно верно в области архитектуры. Многие решения просто не удовлетворяют потребности бизнеса. Если вам нужна высокая доступность, в вашей архитектуре не может быть только одного экземпляра. Даже если запустить одну из них проще, это не поможет.
Введите Timeboxing
Вернемся к тем решениям, которые достаточно хороши для отправки, но у вас все еще есть некоторые рекомендации. Как вы попросите автора, просившего ваше мнение, решить эту проблему? Как вы учитываете дедлайны?
Предложите временной интервал.
Вместо того, чтобы просто сказать «переделайте это» или «отправьте», вы можете договориться с автором о количестве времени, чтобы опробовать одно или два предложения. Может, несколько часов. Возможно, всего один. А может, это просто конец дня.
Какой бы временной интервал вы ни выбрали, помните, что это компромисс. Это между вами и автором. У них есть работа, которую они хотят выполнить, и ваши рекомендации технически удерживают их от этого. В этом разговоре можно принять во внимание, как долго они над этим работали, сроки и даже уровень квалификации.
Время историй
В качестве примера я просматривал пул-реквест от младшего разработчика. Мы создаем множество приложений Spring Boot, и я увидел способ изменить некоторые классы для более эффективного использования свойств Spring. У него был ограниченный опыт с этим. Когда я предложил переработать его, мы хорошо поговорили. Он упомянул, что у него есть крайний срок для завершения работы в конце дня, и он нервничал из-за попытки провести рефакторинг в конце игры.
Вместо того, чтобы принимать жесткое решение «да / нет», мы решили, что он проведет остаток дня, пытаясь выполнить рефакторинг в отдельной ветке после того, как он рассмотрит любую блокирующую обратную связь. Было около двух часов, когда он посмотрел на рефакторинг. Примерно в 4:30 он решил прекратить работу, так как у него возникли проблемы с выяснением этого вопроса. Мы договорились объединить его работу, и на следующий день мы сможем решить проблему рефакторинга.
На следующий день мы собрались вместе, чтобы посмотреть, чего он добился накануне. Я смог обсудить с ним сделанные мной предложения. В течение часа мы вместе разобрались. Мы открыли запрос на вытягивание, который включал только этот новый рефакторинг, и к обеду его объединили.
Временные рамки начальной работы привели к нескольким замечательным результатам:
- Приготовление рабочего раствора на месте. Удовлетворение неотложной потребности в первую очередь позволило нам уверенно уложиться в срок, прежде чем пытаться выполнить тонну переделки.
- Снятие стресса. Timeboxing позволил этому младшему разработчику сосредоточиться на обучении и экспериментах, а не беспокоиться о сроках.
- У нас все еще есть доработка до развертывания! Мы настроились быстро закончить переделку на следующий день, поскольку она находилась в отдельной ветке git. Выполнение и первоначальной работы, и повторной работы до развертывания происходит не каждый раз, но в данном случае это произошло.
В заключение, задачи с ограничением по времени могут помочь вам оставаться продуктивными. Timeboxing может быть особенно полезен для задач и работ, которые «достаточно хороши на данный момент», таких как рефакторинги или общая переработка идеи. Это также верно для многих других задач, таких как мозговой штурм, начало чего-то, что кажется пугающим, или завершение того, чем вы когда-то пренебрегали.
Удачного кодирования!
