Мастерство техдолга
Тут на Кворе был дебильный вопрос "Может ли QA помочь с техдолгом?" и аналогично же дебильные ответы, из которых стало ясно, что народ не понимает, что такое техдолг. Клод справился даже лучше, чем я предполагал, в плане идей, но как обычно страдают writing skills
( Read more... )
Работа не планомерная, скорее в промежутках между удовлетворениями хотелок переключаемся на задачи по техдолгу.
> Собрать MVP из говна и палок, чтобы просто убедиться,
> что оно работает - это явно не техдолг.
Клод называет это intentional tech debt. В нашей ситуации -- это сделать балансы по технологии, которая заведомо не будет работать на большом трафике, и следить за уровнем жидкости в септике, чтобы при первых признаках проблем заняться переделкой.
Устаревшие версии всегда являются техдолгом, который просто не обязательно платить. Выплата становится обязательной когда к текущей мажорной версии перестают выходить обновления (для некоторых либ на ноде это сразу при выход новой мажорной, на поддержку старых мажорных многие забивают но не все). Ну и есть ещё SCA aka мониторинг уязвимостей в библиотеках. Который отдельная боль но то уж точно не техдолг.
Разработчики у нас достаточно слабые во всех смыслах (и это часть открытия, что это ни к каким бизнес-последствиям не приводит), и большая часть техдолга никогда не отдается, если только я на это не обращу внимание в ходе условно-ежеквартального ревью, потому что команде норм. Но на уровне "поддержки говна в септике на безопасном уровне" они справляются.
Саботеров нет, эти саботеры-луддиты конечно ужасные. Ну бывают моменты когда предлагаемое мной сияющее решение отвергается как слишком заумное и заменяется полумерой, но это даже к лучшему поскольку находится компромисс между качеством решения и его понимаанием командой.
Для любых рефакторингов отдельные задачи. У нас PCI DSS Change Control, там суровое проштамповывание любого пука по инстанциям, и откат несвязанных изменений даже если это удаление trailing space (но это постепенно устраняется инкрементальным внедрением линта).
Reply
Это может быть компенсировано на длительном пробеге при сильном лиде. Лид сильный?
Reply
Жестко с PCI DSS, конечно...
Насчет слабых разрабов. Что-то мне все больше кажется, что тот, кто экономит на разработчиках, потом кратно платит в других местах.
Слабость - понятие относительное, конечно. И это слово должно применяться в контексте конкретного проекта. Если у вас там действительно получилось нанимать слабых разработчиков для вашего проекта, и всё как-то неплохо едет, это прямо успех. Мне кажется, это еще прокатит, когда разработчиков максимум пять - лид за всеми успеет приглядеть. Если больше, то всё. А если скрам какой безлидовый, так кранты. ИМХО.
Reply
Leave a comment