Comments 13
Интересная тема. Хотелось бы больше в нее углубиться и получиться больше информации.
Интересно написано про то, что заказчик никогда не поймет, что у разрабов есть техдолг))
связанные с пренебрежением к качеству при разработке программного обеспечения и вызывающие дополнительные затраты труда в будущем.
Не согласен. Это лишь один из факторов, и он не совсем связан с техническим долгом.
Технический долг это просто накапливающиеся проблемы, связанные с разными вещами.
Начали писать на джава 8, пора переходить на джава11, джава14, джава17, а денег на это не хватает. Вот и появился технический долг в идеальном коде
Как появился этот долг? Мы его взяли что бы поставить заказчику функционал раньше, чем мы бы смогли, если бы не "заняли". Так же как бизнесмен берет кредит для своей бизнес идеи.
В таком ключе техдолг является плохой метафорой. Бизнес берет в кредит чужие деньги, чтобы получить свои 20% прибыли сверху. Техдолг, который вы берете у себя же, под 20% времени в будущем, выглядит как какая-то беспросветная кабала, вынуждающая день ото дня иметь дело с легаси и говнокодом. Это не кредит, а антисанитария.
За эту кабалу вы получаете деньги от заказчика, которых возможно бы не было, если бы вы ему пытались объяснить как разрабатывать правильно и сколько времени это займет. Так что метафора вполне себе
Почему чужие деньги? Бывает он закладывает свой дом и свою машину, что бы вложиться в идею. А потом живет на съемной квартире за городом и добирается на маршрутке (вот и говонкод)
Есть третий метод борьбы с техническим долгом: всё равно лет через 5 то ли проект закроется, то ли работу сменишь. Главное продержаться это время.
Да и он повсеместно применяется... Ибо все хотят получить свои 80 за 20 и оставить 20 за 80 кому-то другому.
Как-то взял проект - устаревшие технологии, плохо написанный. Переписать с нуля бы - самое то. Но разве заказчику скажешь, что все его траты за последние 3 года были зря? Пришлось переписывать потихоньку, заплатками. В итоге этот рефакторинг обошелся заказчику в два раза дороже переписывания с нуля. Суровая правда жизни.
Вполне возможно что бизнес все равно больше заработал чем заплатил за этот рефакторинг. Он в процессе этих "заплаток" мог легко добавить задачу по новой фиче, которую надо срочно сделать как у конкурента, что бы заработать большие деньги. У него не было рисков, что команда, которая делает рефакторинг, распадется и после нее ничего не останется от нового проекта. И из закона убывающей предельной полезности, возможно первые заплатки принесли уже нужную выгоду по проекту в первый месяц рефакторинга и 80% багов были устранены и издержки стали минимальны. А весь остальной год бизнес платил за рефакторинг из денег, которые он получил за первые заплатки.
Основная проблема софтостроения (и не только). Так же недооценена, как и эта заметка. "Всё будет по-старому" (С).
P.S. +100500 в карму автору +спасибо Хабру за публикацию.
? Экстремальное программирование — это пример разработки с кредитом качества
Где вы прочитали такое определение?
Технический долг. Как не обанкротиться