Comments 6
Как это вдруг не отлаженный код стал тех долгом? Это просто работа не сделана и не более того.
Если кодер не пишет комменты то это его лень, а вовсе не необходимость ускорить процесс
А вот тухлая архитектура это тоже не тех долг. Чаще она не потому такая, что не проработали. А без реального запуска было не понятно.
И часто ничего потом улучшать не надо. Проект умер или ему и так норм. Но если проект жив, то у него будет ресурс на переделку.
Сейчас команда решает сделать упрощенную архитектуру, а нюансы и улучшения «сделают потом»
Это сознательный обман Заказчика вызванный сознательным/не сознательным желанием качать с него деньги.
Еще один пример — отсутствие документации. Очевидно, что без нее доработка и поддержка становятся очень сложными.
Это технология "писать на коленке", каком бы в коллективе любого размера и проэкте любой сложности она не применялась. Суть IT разработчики не желают работать в строгом соответствии к требованиям производственного процесса.
Я бы разделял техдолг по приоритетам. Что быстрее и больнее начнет отражаться:
на скорости разработки
на качестве приложения, что менее важно.
Я специально отформатировал цитату чтобы яснее стали понятны Ваши приоритеты - "качество не важно, лишь бы сдать заказчику". А потом Вы начнете качать из заказчика деньги. В подтверждение этого своего вывода я приведу еще одну Вашу же цитату:
Регулярно добавлять связанные с этим задачи в разработку, обосновывать и защищать перед заказчиком необходимость таких изменений.
Другими словами, вначале мы сознательно закладываем "упрощенную архитектуру", а когда заказчик начинает понимать, что проект "ходит по граблям" начинаем ему объяснять, что устранение этих граблей это серьезная работа, которая делается за отдельные (серьезные) деньги.
Хотите продемонстрировать страдающее качество кода, представьте бизнесу сколько багов находят клиенты.
А причем тут прикладной бизнес, если это Вы заложили эту кучу багов, которые находят клиенты прикладного бизнеса и от которых страдает не Ваше, а его лицо?
Вначале вы портите своему клиенту репутацию, а потом объясняете что за исправление ее появления, надо отдельно заплатить.
Если технической долг есть на уровне архитектуры, можно замерить максимальную нагрузку, которую выдержит приложение. Эта цифра наглядно покажет заказчику, что можно выжать из текущего приложения. Если бизнесу нужно больше пользователей, потребуются вложения.
Собственно еще раз Вы демонстрируете, что не создаете инструмент для который решает его задачи. А все строго наоборот Вы создаете инструмент для решения своей задачи - доить заказчика.
Как написал предыдущий комментатор: Техдолг это несделанная работа.
Я продолжу его мысль, несделанная работа за которую получены деньги. что в свою очередь означает оказание услуг не надлежащего качества и теоретически уголовно наказуемо.
P.S. И не надо писать про сложность и трудоемкость процесса разработки ПО и сложности общения с Заказчиком.
Просто представляйте, что вам в автосалоне продадут автомобиль с таки же техническим долгом, какой вы своим заказчикам оставляете. И да, работать с этим техдолгом, будут строго по принципам описанным в Вашей статье.
Это сознательный обман Заказчика вызванный сознательным/не сознательным желанием качать с него деньги.
Нет, это может быть стандартный MVP. А потом решения, принятые в MVP, остаются надолго и перестают соответствовать новым реалиям. Сомневаюсь, что создатели Инстаграма изначально закладывали в архитектуру миллионы пользователей
Суть IT разработчики не желают работать в строгом соответствии к требованиям производственного процесса.
Зачем так плохо думать о людях? Да, можно собрать много причин, почему они так делают. Например, всегда так делали раньше, у них никогда не было описанных требований производственного процесса, не было хорошего ментора. Либо в компании так не принято или не было принято. Поэтому продолжают делать в том же стиле. Может быть, требования есть только в голове архитектора, один он владеет этими сакральными знаниями. И еще масса причин, почему не пишут документацию.
Я специально отформатировал цитату чтобы яснее стали понятны Ваши приоритеты - "качество не важно, лишь бы сдать заказчику". А потом Вы начнете качать из заказчика деньги.
В процитированном сообщении как раз написано обратное. Скорость и качество — это критерии отбора «важное»/«не важное».
Другими словами, вначале мы сознательно закладываем "упрощенную архитектуру", а когда заказчик начинает понимать, что проект "ходит по граблям" начинаем ему объяснять, что устранение этих граблей это серьезная работа, которая делается за отдельные (серьезные) деньги.
Да, сознательно, на основании функциональных и нефункциональных требований. А потом, когда заказчик понимает, что за прошедшие 5 лет его требование «сделать приложение для 5 человек в день за 10 рублей» превратилось в «хочу 24 на 7 систему с 1млн запросов в день», придется переписать архитектуру и часть приложения.
Собственно еще раз Вы демонстрируете, что не создаете инструмент для который решает его задачи. А все строго наоборот Вы создаете инструмент для решения своей задачи - доить заказчика.
Как написал предыдущий комментатор: Техдолг это несделанная работа.
Я продолжу его мысль, несделанная работа за которую получены деньги. что в свою очередь означает оказание услуг не надлежащего качества и теоретически уголовно наказуемо.
По-моему, вы путаете понятия. Если вы сдаете проект, который не удовлетворяет требованиям (функциональным и нефункциональным) заказчика, это не техдолг. Это просто не сделанная работа, ее никак нельзя считать техдолгом.
Если вы не написали документацию к одному приватному методу в классе или используете устаревший класс, то это станет техдолгом, когда из-за вас будет страдать будущая разработка. Если не страдает — это все лишь некрасивый «пахнущий» код, он глобально и отрицательно не скажется на проекте. Хорошего в этом тоже, впрочем, мало.
С такими критериямии, весь наш текущий проект - это развитие и наращивание техдолга. Но величина его роста ограничена, например сейчас куски написанные на COM+ уходят, и списываются все связанные с ними долги.
Это вы только вершину айсберга поскребли, а техдолг может и с другой стороны расти, не только со стороны неопытности руководителей или исполнителей.
Ошибки управления проектом
Слабое владение или отсутствие владения тех. деталями со стороны руководителей приводит к неверной оценке трудозатрат, что выливается в "сжатые сроки"
Те же "сжатые сроки" получаются, когда руководители пытаются откусить кусок больше, чем могут проглотить. Списывать только на неопытность? Этим и люди с большим стажем страдают в первую очередь из-за оторванности от коллектива.
Неумение переложить требования бизнеса на язык заказчика - классика, всегда и везде. Это экономия на сотрудниках (аналитиках), которая приводит к тех. долгу. С одной стороны сиюминутные затраты меньше, с другой стороны отложенные затраты больше.
Попытки воспитать "универсальных солдат" в компании приводят к размыванию ответственности, и в итоге даёт ситуацию, когда вроде бы все всё умеют, но никто ни за что не отвечает.
Тех. культура, опыт и т.п.
Недостаток - конечно приводит к тех. долгу. Пока люди учатся, пока они набьют шишки в поле с граблями - долг неизбежно растёт. Контролировать можно только установлением стандартов в компании, или, хотя бы, в отделе.
Никакие тесты не спасут от техдолга. Более того, избыток тестов сам по себе начинает создавать техдолг, т.к. зачастую тесты представляют собой код более низкого качества, чем то, что они проверяют. Этим страдают абсолютно все, даже бигтехи на Западе. Только стандарты и только кросс ревью, но это замедляет процесс разработки, и если руководство не согласно на увеличение сроков... ну вы сами понимаете.
Архитектура - основной источник техдолга. Не код, а именно архитектура. Код может быть идеален, вылизан, покрыт тестами в хвост и в гриву, но если архитектура система убогая, то никакой код не спасёт. Неизбежно будут нагорожены костыли со всеми вытекающими.
Переусложенние (overengineering) - ещё один массовый источник техдолга. Многие любят велосипеды изобретать, и на определённом этапе это даже хорошо, для научения, но плохо для перспективы. Этим даже многие т.н. сеньоры грешат.
Это тоже далеко не исчерпывающий список.
Самый действенный способ уменьшить техдолг — не допускать его.
Совсем не допускать не получится, только если вы не вселенский гений, который ещё до начала работы над проектом видит все итоги реализации, внедрения, и поддержки. Техдолг неизбежен, именно поэтому существует отладка, тестирование, рефакторинг и т.п. Работа над проектом включает в себя работу с техдолгом. Это только hello world можно написать с ходу без "долгов", а что-то посложнее - не выйдет. Не допускать здесь это видеть, контролировать, не давать расти, и даже уменьшать. Техдолг это двигатель качества пока у вас нет 20+ лет разнообразнейшего опыта.
А бизнесу надо просто показывать план. Вот сейчас так, вы хотите это, значит займёт столько-то, потому что изначально не предусматривалось и т.п. Тут нечего добавить.
О причинах технического долга, том, как с ним бороться и убедить бизнес, что это проблема