Архив за месяц: Февраль 2021

Избавляемся от лишнего

 Есть очень полезная практика, с которой можно столкнуться в различных областях нашей деятельности. В практиках доведения дел до конца, он заключается в регулярных ритуалах просмотра списка дел и безжалостного выбрасывания тех из них, которые утратили свою актуальность или по которым мы понимаем, что делать это мы все равно не будем. В отношении вещей в доме, действует тот же совет, если вы какую-то вещь не использовали уже лет 5, то не захламляйте ей шкаф (гараж, сарай), а безжалостно выкидывайте. В разработке ПО этот подход применяется, например, в рамках Backlog grooming. Логика та же самая, смотрим, что устарело и нам больше не потребуется и удаляем соответствующие требования (пользовательские истории). Но, несмотря на известность практики, мы ее почему-то не используем по отношению к коду. А может и не нужно? Давайте обсудим под катом.

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

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

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

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

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

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

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

Мнение о книге "Распределенные системы. Паттерны проектирования"

 

Книга совсем небольшая, порядка 220 страниц. Мне понравилась структура. Есть три части, в каждой дается вводная часть, описывающая группу паттернов, а затем главы посвящены отдельным паттернам. Каждый паттерн рассматривается теоретически, описываются случаи когда он может быть применен и, самое главное, приводится пример как его реализовать (докер, кубер и kubectl).

Выбор паттернов, как по мне, достаточно специфичен. Здесь нет той же Саги, зато есть очень много советов, как сделать контейнеры реально переиспользуемыми. Одноузловые паттерны это вообще тема, очень мало кто знает про них в достаточном объеме. Тот же прицеп еще на слуху, а амбасадор, уже вызовет вопрос, а что это такое :)

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

Мнение о книге "Распределенные системы. Паттерны проектирования"

 

Книга совсем небольшая, порядка 220 страниц. Мне понравилась структура. Есть три части, в каждой дается вводная часть, описывающая группу паттернов, а затем главы посвящены отдельным паттернам. Каждый паттерн рассматривается теоретически, описываются случаи когда он может быть применен и, самое главное, приводится пример как его реализовать (докер, кубер и kubectl).

Выбор паттернов, как по мне, достаточно специфичен. Здесь нет той же Саги, зато есть очень много советов, как сделать контейнеры реально переиспользуемыми. Одноузловые паттерны это вообще тема, очень мало кто знает про них в достаточном объеме. Тот же прицеп еще на слуху, а амбасадор, уже вызовет вопрос, а что это такое :)

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