2015-12-10: Технический долг - как работать с костылями

Материал из MaksWiki
Перейти к: навигация, поиск
(Новая страница: «Как говорил на одном из докладов Максим Дорофеев: "ИТ - единственная область, где с костыл…»)
(нет различий)

Версия 00:40, 10 декабря 2015

Как говорил на одном из докладов Максим Дорофеев: "ИТ - единственная область, где с костылями быстрее, чем без них". А кроме костылей есть еще много других способов сделать быстрее. Например, опустить документацию, не делать тесты, не реализовывать побочные ветви процесса, которые сейчас все равно не понадобятся. В результате вполне работающий софт может появиться гораздо быстрее, особенно у опытного разработчика. Проблемы вскрываются потом, когда этот код надо сопровождать, дорабатывать, рефакторить. Вот тут-то выясняется, что никто не знает, как этот код работает и как он должен работать, является ли какое-либо поведение фичей или багом. Даже сам автор. Даже если он доступен, через полгода-год работы на другом проекте подробности вытесняются из памяти.

Для работы с этим в отрасли придумано такая конструкция, как технический долг. И когда встрече по Agile для госпроектов в обсуждении в группах зашла речь об этих проблемах я бегло рассказал об этой практике. На уровне беглого рассказа это приняли, но потом некоторые участники у меня просили литературу, где бы это было описано подробнее. В литературе я не силен, поэтому переадресовал вопрос Алексею Пименову, но оказалось, что он тоже не знает хороших книг и смог вспомнить только доклад Антона Бевзюка на AgileDays-14 Эй, программистик, за тобой должок!

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

Поэтому я и пишу данный пост.