Comments 25
Спасибо, отправил паре коллег с сопутствующими комментариями.
Сам по теме могу сказать одно: на техдолг тоже капают проценты, причём неслабые.
Капают, конечно. Но продукт оунеры тоже не вечные :) Велик шанс, что по твоим долгам будет расплачиваться кто то другой :)
А можно задуматься, например, о том, а почему вот у Стива Джобса не бело техдолга, а даже наоборот, выглядело так, что это ему все должны. Может дело то все в том, умеем ли мы адекватные современному техническому уровню задачи формулировать, хотя бы чуть выше этого современного уровня?
— А че? Cразу-то по-человечьи нельзя было сделать??? 👽 Но тут в едином порыве поднимались архитекторы и девелоперы
Ну, если менеджемента нет, то и смысл писать об отсутствующем управлении статьи.
Отсутствие менеджемента и "Техдолг" - одно ли это и то же?
вот у Стива Джобса не бело техдолга
С чего вы это взяли?)
Читается как честная исповедь продукт-оунера, а не методичка
Все так.
>> кастомеры всегда жаждут новых фич,
А юзеры — уходят, когда достали баги. По-моему, продукт овнер должен быть ближе к пользователям, а для кастомеров есть аккаунт или сейлз.
Работа архитектора сформулировать принципы построения информационной системы, т.н. ADR, в среднесрочной перспективе, вынув душу показатели качества и возможные пути развития продукта из PO. Каталог ADR не избавляет от долга, но делает его дешевле, растянутым по времени жизни, и снимает большинство флейма про идеальный код и архитектуру. Некоторые называют такой подход decision driven development.
Собсно, «все было модульным. Это скорее, не наша с Темой заслуга,а предыдущих поколений разработчиков».
Знакомая проблема. Особенно в крупных компаниях с тысячами микросервисов. Архитекторы тоже люди и за ADR нужно следить, это нужно читать, реализовывать. Попробуй на сотни-тысячи разрабов промасштабируй. Появляются дополнительные роли у сотрудников, появляются обязанности по трекингу, это болото всех душит. Пройдись по проектам, зайди в вики, зайди в 10 чатов, создай пару сотен задач, боль...
В одной из таких компаний на выслеживание и трекинг техдолга уходило такое неприличное количество времени, что в один момент запилил свой продукт на базе техрадара для автоматического контроля большого пласта техдолга. Хорошо, когда рутину на себя берет робот, а ты дальше делаешь свое дело. Это как CI, только с другого ракурса.
Можете просто копипастнуть Уважаемому айтишному изданию выдержку из Уважаемой ПедИи. Там всё исчерпывающе сказано об это странном и многогранном явлении:
Технический долг — метафора программной инженерии, обозначающая накопленные в программном коде или архитектуре проблемы, связанные с пренебрежением качеством при разработке программного обеспечения и вызывающие дополнительные затраты труда в будущем.
Технический долг связан с недостатками в сопровождаемости, тестируемости, понятности, модифицируемости, переносимости.
Причин технического долга может быть несколько:
Давление бизнеса, когда бизнесу требуется выпустить что-то раньше, чем будут сделаны все необходимые изменения
Сильное зацепление компонентов, когда декомпозиция системы выполнена неправильно
Отсутствие тестов — ускоренная разработкаПрименение быстрых рискованных исправлений («костылей») для исправления ошибок
Отсутствие документации, когда код создаётся без необходимой сопроводительной документации.
Отсутствие взаимодействия между командамиНеэффективное управление знаниями в организации.
Отложенный рефакторинг
Отсутствие опыта, когда разработчики просто не умеют проектировать программные системы или писать качественный код.
(с) педИя
Хочется пожелать, чтобы у разработчиков самолётов, атомных реакторов, водопроводных и газовых труб, и тормозов в автомобилях не было "технического долга". Ну, и у строителей высоток - желательно. Остальным - можно!
PS Кстати, "технические долги" можно конвертировать в долги по прибыли Уважаемых Акционеров и в долги по зарплатам Уважаемых айтишников. Правда, в первом случае Продьюкт Оунеры долго на работе не продержатся.
Куда ё девалась в имени Тёма?
@vvvphoenix Как текущий продукт оунер VTune, Валера, хочу сказать, долгов вы понаоставляли нам столько, что не только не рагрести сегодняшними ресурсами команды, но и вообще никогда уже. Так что, скороее всего, продукт переживет свой новый (и последний в жизни) цикл переписывания с нуля.
Володь, а размер команды какой сейчас? В мои времена человек 40-50 было
дело то не в количестве человек. Скорее всего изначально задачи были поставлены-сформулированы не правильно и, соответственно, эти задачи не имеют внятного решения адекватного той функциональности которую должна реализовать программа как продукт. Если новый руководитель пытается углубить и расширить эти уже практически доказанные кривые задачи, как обычно и бывает то он приходит неизбежно к осознанию что все надо переделывать, просто потому что понимает что с самого начала, еще до него, делали не то! Вопрос тут в том сколько времени понадобилось новому руководителю чтобы придти к этому осознанию, я подозреваю что это время в разы больше чем то что было потрачено на первую проверку формулировки задач без него. Скажем до него проект шел 5 лет, а с новым рукой-водителем 10, ну и что тогда жаловаться на долг который накопился за те 5 лет, вы уже 2 раза могли все по новой переписать!
У меня был такой показательный опыт когда ембедед программу на 3-х прерываниях на 500-1000 строк кода до меня пытались довести до ума минимум пол года и она все равно стабильно не работала, даже кандидаты наук приложили свою руку и все было бесполезно. Мне понадобилось буквально 2 дня чтобы решить проблему, потому что у меня эта проблема не только давно была сформулирована, но и варианты типовых решений давно были отработаны. Типовых решений в том числе по не прямой отладке в ембедед системе.
Володь (Сергей), Валера, раскройте тему как на самом деле обстоят дела в рабочей группе команде и с профайлером продуктом Intel VTune. Интересуют внутренние разборки, увольнения, провалы, сокращения оптимизации штата. Что вообще ждёт команду и продукт? Уважаемым хабровчанам будет интересно.
*
Из воспоминаний: "золотое время" профайлеров - конец 90-х - начало нулевых. А потом прошла такая дрянь - с глюками в работе и кривыми gui, что полноценно работать с ней было невозможно.
ну я то тут совсем не при чем :)! Я ушел в самом почти начале 2000-х до того как пришел VTune, насколько я понимаю.
Теперь профайлер есть полнофункциональный встроенный-интегрированный в вижал-студию, настолько навороченный что с ним надо месяц-два разбираться чтобы что-то серьезное делать. А если так по мелочи - то там тоже все видно, но это тема все равно сложная, без опыта и достаточно глубоких знаний туда не влезть, поэтому никто особо и не лезет как я понимаю, и спроса нет и экспертиза и компетенция средние фактически исчезли - это сложная тема, которая никому не нужна потому что не приносит быстрых дивидентов - все хотят новый фейсбук или однокласники на худой конец, забабахать. Я так понимаю до профилирования производительности дело практически ни у кого не доходит.
Валер, я думаю, что нарушу добрую кучу положений код оф кондакт, если начну рассказывать, сколько человек осталось в проекте и какие процессы в нем сейчас происходит. Но в целом, могу сказать, что у меня мало позитивных эмоций.
Я по сути видел только раз, когда проект полностью переписали (с Perl'а на Java), если не считать уж совсем маленькие решения. Важное уточнение, что переписывали те же люди, что написали изначальный, т.е. хорошо разбирались и в коде и в бизнес-логике предприятия. Остальные попытки переписать, особенно когда приходит энергичная сторонняя команда - все в стол. Поэтому рассчитывать, что наступит итерация, когда всё это перепишут с нуля я бы не стал (тем более, что скорость добавления новых фич может быть выше, чем переписывания существующего).
Поэтому я за итеративный подход почти всегда - так и с продактом проще договориться, т.к. эти итерации улучшений как правило небольшие.
Маленькое эссе о техдолге