Технический долг

[denver]

Вардом Каннингемом, под техническим долгом понимается осознанное компромиссное решение, когда заказчик и ключевые разработчики четко, понимают все преимущества от быстрого, пусть и не идеального технического решения, за которое придется расплатиться позднее… речь идет об использовании .NET Remoting вместо WCF, использовании Sybase, вместо SQL Server, использовании DataSet-ов вместо Entity Framework (**), однако никто не говорит о «забивании костылей», грязных хаках, плохом коде, связной архитектуре

Вот на этой фразе на мой взгляд неточно либо туманно. На мой взгляд (и на беглый гуглинг) технический долг это когда используешь технически идеальное (!) решение (SQL вместо файлов, Redis вместо MySQL, MVC вместо макарони), но при этом прикручиваешь его быстро либо лишь в одном боттлнеке, тем самым размазывая «критичность» на несколько месяцев. При этом не чураешься долговременных хаков (FIXME), долговременного нарушения SRP и даже грязного кода (правда выделенного в функцию с понятным именем).

[pyatigil]

Вот неплохая статья на тему: www.m3p.co.uk/blog/2010/07/23/bad-code-isnt-technical-debt-its-an-unhedged-call-option/ для тех, кто немного разбирается в финансовых инструментах. Коротко: с точки зрения финансиста долг это не плохо, поэтому попытка объяснить клиенту финансисту проблему через метафору «долга» может и не сработать. Для этого случая гораздо удачнее метафора «кол-опциона».

[sleepytomcat]

Рискну высказать мысль, что даже технический долг — не всегда плохо. В качестве примеров «хорошего» технического долга я готов рассматривать все виды прототипирования, а так же некоторые краткосрочные проекты, в которых макасимально быстрое получение полезного результата превалирует над долгосрочной перспективой.

[aspect]

Про долги впервые прочитал у Бындю
blog.byndyu.ru/2008/12/blog-post.html

[tranquil]

Если посмотреть на индустрию ПО вцелом, похоже программисты задолжали больше, чем создали.

[scorched]

Хорошая книга на эту тему: «Managing Software Debt: Building for Inevitable Change»


Вот подкаст с обсуждением этой книги (для тех, кто будет её читать): ru-studygroup.livejournal.com/3924.html

[scorched]

ссылка на книгу на амазоне

[binariti]

В курсе pluralsight приводили такую метафору долга: представьте, что вы повар и приготовили вкусный обед. Сами сервировали стол, усаживали гостей и т.д. Т.е. по отношению к клиенту вы вроде бы выполнили работу идеально. Но можете ли вы считать теперь свою работу законченной? Для повара правильный ответ — нет. Когда он возвращается к себе на кухню, он видит там все эти горы грязной посуды, испачканную плиту и т.д. Работа повара еще не окончена, когда клиенты накормлены. Вот и работа программиста тоже как правило не кончается в момент выпуска продукта — часто там, за сценой, остаются еще горы немытой посуды.