Есть такое понятие: «технический долг». Когда ты создаешь и поддерживаешь программу, ты неизбежно допускаешь архитектурные просчеты. Некоторые ты допускаешь по неопытности, некоторые делаешь сознательно, чтобы уложиться в бюджет и сроки. Не бывает идеальных решений, всегда есть какой-то компромисс. Сумма этих просчетов и называется — технический долг.
Он неизбежен. Он растет при любых изменениях в программе, при каждой доработке мы добавляем капельку технического долга. О нем не знает лишь разработчик, который бросает свои программы после первого релиза. Этот долг, как и любой другой требует обслуживания. Чем он больше, тем сложнее вносить изменения в программу, мы платим за сами изменения и за тот долг, который мешает их внести безболезненно. Этот долг, как и любой другой можно погасить. Превратить свое время и знания в поиск и устранение долга. Найти слабое место и провести рефакторинг.
Но не всегда мы ловим момент, когда это необходимо. Иногда ощущение эйфории, того, как все здорово и хорошо получается, заставляет нас думать, что мы ничего за это не платим. И тогда, ты ощущаешь этот долг в тот момент, когда у тебя недостаточно ресурсов его погасить. Твои изменения в одном месте влекут ошибки в другом. Тесты не помогают. Написание кода становится похоже на поход по минному полю с тачкой гравия. Каждый релиз напоминает природный катаклизм и тебе остается только гадать, каким он будет на этот раз. Изменения теперь стоят столько, что ты понимаешь: твоя программа настолько плоха, что дешевле ее переписать.
Тебя захватывает эта мысль, ты бросаешься в нее с головой. Новая программа легка, ты представляешь ее фичи идеальными, а сервисы соответствующими чудесным новым стандартам. Код ложится легко, как весенняя симфония. Можно даже не писать тесты, и так все работает! Новые фичи похожи на горячие пирожки, а релиз напоминает пиршественный зал в Валгалле. Программа прекрасна, пользователи в восторге, ты счастлив как никогда. Будущее видится простым и безоблачным. И лишь маленький червячок грызет тебя изнутри, смутное ощущение, что ты про что-то забыл.
Спасибо, тем кто дочитал. Для меня технический долг одно из важнейших понятий в разработке и высшим искусством архитектора я считаю умение балансировать, играть с техническим долгом. Сделать его своим помощником, способным в нужное время спасти дедлайн и бизнес, сохранить приятные впечатления от работы над программой.
Z>Каждый релиз напоминает природный катаклизм и тебе остается только гадать, каким он будет на этот раз.
Это не долг. Это банкротство уже… Коллекторы уже стучат в дверцу.
Z>КИзменения теперь стоят столько, что ты понимаешь: твоя программа настолько плоха, что дешевле ее переписать.
Угу… Переписать блин.
И наплодить нового технического долга. Потому как в заново переписанном будут учтены просчеты прошлого, но в новом варианте будут внесены аккурат новые. Ибо вместо старого минного поля, мы, решив "а ну его нафиг, пойду на соседнее минное поле" мы опять начнем с нуля, ловя новые мины, ибо поле новое.
Играться с техническим долгом можно и нужно. Но не каждый раз с нуля.
Нужно не просто исправлять, избавляться от технического долга. А анализировать причины, по которым он появляется. Причем не сферически в вакууме, "мол вот жисть моя жестянка", мол "мы все лажаем" — это и так ясно. А почему конкретно, в этом самом конкретном месте, что именно нас сподвигло на "кривоватый" код (копи-паста, и прочие ружья чтоб стрелять себе в ногу).
Что именно спровоцировало!?! И как писать так, и как проектировать, чтобы избегать этих провокационных моментов.
Вот тогда появляется опыт, и результат будет лучше.
А так, "переписать всё нафиг", особенно в архитектурном смысле, это бесконечный бег по кругу.
Если мы налажали на первом круге, бросили и пошли на "другой стадион", а потом опять бросили и уже на третий "стадион" — откуда, вот откуда мысль, что на круге Икс всё будет отлично!?!
Здравствуйте, Ziaw, Вы писали:
C>>Угу… Переписать блин. C>>И наплодить нового технического долга. Потому как в заново переписанном будут учтены просчеты прошлого, но в новом варианте будут внесены аккурат новые. Ибо вместо старого минного поля, мы, решив "а ну его нафиг, пойду на соседнее минное поле" мы опять начнем с нуля, ловя новые мины, ибо поле новое.
Z>Ты верно уловил смысл. Чего ж тебя так бомбит-то?
Та не… Вспомнились всякие «детишки», которые без конца так делают. И каждый раз у них одно и то же. п.1. Получилось гуано п.2. Переписать всё заново п.3. Переписали с нуля. Красота да и только. п.4. Упс! Чего-то не то вышло. Опять гуано. п.5. Go To п.2 (переписать заново)
Главное в другом! У них этот круг п1-п2-п3-п4 — снова п.2 (переписать заново) десятками раз повторяется.
Потому как п2. должен быть не переписать, а "анализировать", потом п3. должен быть "попробовать изменить\поправить\доработать". Это нужно чтобы новых граблей прочувствовать, а вот только потом п.4 — переписать всё заново. Ибо после "анализировать" — понимаем чего мы изначально нагуанили, и главное почему. После следующего шага: "изменить\поправить\доработать" — мы наловим новых граблей пока всё будем улучшать. И вот после такого анализа и "разведки боём" (попробовать изменить\доработать) можно снова в бой.
Вот тогда и будет прогресс, причем в качественном смысле.
C>>А так, "переписать всё нафиг", особенно в архитектурном смысле, это бесконечный бег по кругу. Z>Тебе где-то почудился такой совет? Или вспомнил свои грабли? Ничего, на них очень многие наступали, это нормально.
Не-е-е, наступал я настолько по молодости, что шишки до сих пор на лбу Я скорее про другой опыт, обратный: когда я не стал переписывать с нуля всё нафиг, хотя руки чесались. А вот когда я начал править, изменять, переделывать архитектуру иначе — вот тогда это была даже не ступенька вверх, а целый "эскалатор" вверх. Появились сомнения во многом. Здравые сомнения. Ушло юношеское "резать не дожидась перитонита" и всякие "что тут думать, прыгать надо" .
Здравствуйте, Carc, Вы писали:
C>Это не долг. Это банкротство уже… Коллекторы уже стучат в дверцу.
Именно.
C>Угу… Переписать блин. C>И наплодить нового технического долга. Потому как в заново переписанном будут учтены просчеты прошлого, но в новом варианте будут внесены аккурат новые. Ибо вместо старого минного поля, мы, решив "а ну его нафиг, пойду на соседнее минное поле" мы опять начнем с нуля, ловя новые мины, ибо поле новое.
Ты верно уловил смысл. Чего ж тебя так бомбит-то?
C>Что именно спровоцировало!?! И как писать так, и как проектировать, чтобы избегать этих провокационных моментов. C>Вот тогда появляется опыт, и результат будет лучше.
Да, и последний абзац тоже.
C>А так, "переписать всё нафиг", особенно в архитектурном смысле, это бесконечный бег по кругу.
Тебе где-то почудился такой совет? Или вспомнил свои грабли? Ничего, на них очень многие наступали, это нормально.
C>Если мы налажали на первом круге, бросили и пошли на "другой стадион", а потом опять бросили и уже на третий "стадион" — откуда, вот откуда мысль, что на круге Икс всё будет отлично!?!
Z>Спасибо, тем кто дочитал. Для меня технический долг одно из важнейших понятий в разработке и высшим искусством архитектора я считаю умение балансировать, играть с техническим долгом.
Эмм... всё ок как бы, но вообще-то техдолг и прочие отложенные риски есть (ок, должны быть ) в большинстве курсов для QA/PM
Работают с техдолгом точно так же, как со всеми прочими ресурсами проекта: мониторим, по заранее расписанным критериям добавляем в бэклог, рано или поздно берём в работу и чиним.
Не, можно игнорить, но это из разряда "никто в проекте не следит за бэкапами / сертификатами / проч". Кому-то хватает одного факапа, кто-то наступает на грабли до последнего.
Здравствуйте, Ziaw, Вы писали:
Z>О нем не знает лишь разработчик, который бросает свои программы после первого релиза.
Неправда ваша. Самые ловкие горе-разработчики сбрасывают проект на кого-нибудь другого после первой же альфы, и уж они то о техническом долге совершенно точно ничего не знают
Ничего личного, но, дочитав, получил только одно ощущение — "ещё один апологет переписки с нуля".
Считаю, что если речь не идёт о переходе на принципиально другую организацию программы, как GUI с хэндлерами вместо построчного вопрос-ответ, решение о переписке с нуля это капитуляция.
Даже переход на другой язык без смены организации это не с нуля, а перенос существующего.
Z> Изменения теперь стоят столько, что ты понимаешь: твоя программа настолько плоха, что дешевле ее переписать.
Видел я такие переписки. В opensource есть несколько замечательных примеров — Sendmail X, BIND 9, BIND 10 (это чтобы не строить примеры, например, на Microsoft). От тех же авторов, ЧСХ.
Если проект вообще взлетал, то на восстановление функциональности уходили годы.
Z>Тебя захватывает эта мысль, ты бросаешься в нее с головой. Новая программа легка, ты представляешь ее фичи идеальными, а сервисы соответствующими чудесным новым стандартам. Код ложится легко, как весенняя симфония. Можно даже не писать тесты, и так все работает!
Уже по этим словам ясно, что речь идёт о какой-то нереальной фантастике
Z> Новые фичи похожи на горячие пирожки, а релиз напоминает пиршественный зал в Валгалле. Программа прекрасна, пользователи в восторге, ты счастлив как никогда. Будущее видится простым и безоблачным. И лишь маленький червячок грызет тебя изнутри, смутное ощущение, что ты про что-то забыл.
Именно. Всего лишь пользователей и функциональность.
Z>Спасибо, тем кто дочитал. Для меня технический долг одно из важнейших понятий в разработке и высшим искусством архитектора я считаю умение балансировать, играть с техническим долгом.
В которое не входит переписка с нуля.
Z> Сделать его своим помощником, способным в нужное время спасти дедлайн и бизнес, сохранить приятные впечатления от работы над программой.
Что только люди ни придумают, чтобы не сопровождать как следует...
PS: на RSDN есть пометка "" к сообщениям, но давно не хватает пометки "пожать плечами".
.
Часто разработчики думают, что могут упростить (заплатить меньше). Но по факту они просто берут технический долг.
Но полная аналоги с финансами говорит о том, что заплатить меньше без взятия долга всё-же возможно. Талант архитектора заключается в том, чтобы определить где упрощение, а где взятие долга.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, Sinix, Вы писали:
S>Эмм... всё ок как бы, но вообще-то техдолг и прочие отложенные риски есть (ок, должны быть ) в большинстве курсов для QA/PM
Возможно. Я работаю в небольших командах, совмещаю ПМ и архитектора.
S>Работают с техдолгом точно так же, как со всеми прочими ресурсами проекта: мониторим, по заранее расписанным критериям добавляем в бэклог, рано или поздно берём в работу и чиним. S>Не, можно игнорить, но это из разряда "никто в проекте не следит за бэкапами / сертификатами / проч". Кому-то хватает одного факапа, кто-то наступает на грабли до последнего.
Исходный пост больше художественное произведение, не стоит относиться к нему слишком серьезно.
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, Carc, Вы писали:
C>>>>Угу…
MTD>Зачетненько у тебя бомбануло, каким инфантильным чудаком надо быть, чтобы на минус обидеться и пойти минусовать последние сообщения другого человека. Бедолага
Та не, удивила твоя реакция, как-то раньше я тебя не очень здесь видел… Пошел почитать твои сообщения… Мама-мая Ну и чего-то я вдруг разминусовался. Пока не обратил внимание, что твои сообщения в основном это в форумах "священные войны", "политика"… Ну всё понятно: боксер-теоретик.
Извини, если задел, впредь учту, более не повториться. Ибо в политику, и иже с ними я редко заглядываю, этого в офлайн аккурат на завалинке и так хватает.
Здравствуйте, Ziaw, Вы писали:
Z>Инструменты для управления долгом дело десятое, главное научиться его видеть. Лично я до сих пор набираю этот опыт и пока края не вижу. Часто срабатывает интуиция, не знаю, на каких курсах ее дают.
Интуиция тут поможет несильно. Скорее пригодится опыт наступания на грабли (чтобы оценить опасность кода) + примерное представление о зависимостях и планах по проекту.
Если кусок кода с долгом не является проблемным в плане ошибок или производительности, и в нём не планируется никаких правок, то изолировать и пусть живёт как есть до посинения.
В противном случае (и плюс ситуации, когда ближайшие итерации потребуют значительных правок в этом куске) — код хороший кандидат на починку.
Здравствуйте, Sinix, Вы писали:
S>Конкретный набор примеров передать можно, с интуицией проблемы
Да, скилы в команде передаются, но очень медленно.
S>Мне обычно хватает просмотра планов по проекту и чтения бэклога. Скажем, если я знаю, что в проекте временами вылезают проблемы с отправкой писем (опять-таки из тикетов) и в бэклоге висит тикет о добавление промо-рассылок — время насторожиться.
Я бы попытался совместить рефакторинг и проморассылки в одну задачу или хотя бы одного исполнителя, чтобы он мог учесть обе задачи при выполнении каждой.
S>В худшем случае спасает разбор тикета, если он оказался тяжёлым. Что-то пошло не так? Самое время не воевать до последнего, а остановиться и полноценно разобрать проблему. Ну, т.е. воспроизвести, найти причину, набросать в уме план починки и только затем что-то делать.
Все это верно в краткосрочной перспективе. Когда цикл разработки идет на пятилетки, анализ пасует. Просто невозможно все запомнить или перебрать в трекере. У меня один 14 летний проект пережил 4 трекера.
Здравствуйте, Sinix, Вы писали:
Z>>Спасибо, тем кто дочитал. Для меня технический долг одно из важнейших понятий в разработке и высшим искусством архитектора я считаю умение балансировать, играть с техническим долгом. S>Эмм... всё ок как бы, но вообще-то техдолг и прочие отложенные риски есть (ок, должны быть ) в большинстве курсов для QA/PM S>Работают с техдолгом точно так же, как со всеми прочими ресурсами проекта: мониторим, по заранее расписанным критериям добавляем в бэклог, рано или поздно берём в работу и чиним.
Так и есть.
Мы, например, его сразу добавляем в TFS (но не сразу в итерацию) и периодически просматриваем список, не пора ли уже чинить.
Зачетненько у тебя бомбануло, каким инфантильным чудаком надо быть, чтобы на минус обидеться и пойти минусовать последние сообщения другого человека. Бедолага
Здравствуйте, vmpire, Вы писали:
V>Так и есть. V>Мы, например, его сразу добавляем в TFS (но не сразу в итерацию) и периодически просматриваем список, не пора ли уже чинить.
Инструменты для управления долгом дело десятое, главное научиться его видеть. Лично я до сих пор набираю этот опыт и пока края не вижу. Часто срабатывает интуиция, не знаю, на каких курсах ее дают.
Да, мне эта статья очень понравилась в свое время.
IB>Часто разработчики думают, что могут упростить (заплатить меньше). Но по факту они просто берут технический долг. IB>Талант архитектора заключается в том, чтобы определить где упрощение, а где взятие долга.
Согласен. Видеть тех.долг и не путать его с упрощением все таки искусство. Я не согласен с тем, что этому можно научиться на курсах или управлять им какими-то инструментами. Раньше я пользовался метриками кода, но теперь как-то забил, практически ничего нового они мне не сообщают.
Здравствуйте, Sinix, Вы писали:
S>Интуиция тут поможет несильно. Скорее пригодится опыт наступания на грабли (чтобы оценить опасность кода) + примерное представление о зависимостях и планах по проекту.
Интуиция это концентрированный опыт. Тебе не нравится ее использование в инженерном ремесле?
S>Если кусок кода с долгом не является проблемным в плане ошибок или производительности, и в нём не планируется никаких правок, то изолировать и пусть живёт как есть до посинения.
Чтобы понять, планируются ли в нем правки нужен опыт.
S>В противном случае (и плюс ситуации, когда ближайшие итерации потребуют значительных правок в этом куске) — код хороший кандидат на починку.
Или на переписывание в момент запланированных правок. Это тоже может быть дешевле. Сравниваем риск правок*стоимость переписывания и стоимость починки сейчас. Пока никаких численных методов точной оценки ни левой ни даже правой части мы не имеем, решение принимается на основе интуиции.
Здравствуйте, Ziaw, Вы писали:
Z>Интуиция это концентрированный опыт. Тебе не нравится ее использование в инженерном ремесле?
Тут не в "нравится-не нравится" дело. Проблема в распространении знаний в команде. Конкретный набор примеров передать можно, с интуицией проблемы
S>>Если кусок кода с долгом не является проблемным в плане ошибок или производительности, и в нём не планируется никаких правок, то изолировать и пусть живёт как есть до посинения. Z>Чтобы понять, планируются ли в нем правки нужен опыт.
Мне обычно хватает просмотра планов по проекту и чтения бэклога. Скажем, если я знаю, что в проекте временами вылезают проблемы с отправкой писем (опять-таки из тикетов) и в бэклоге висит тикет о добавление промо-рассылок — время насторожиться.
В худшем случае спасает разбор тикета, если он оказался тяжёлым. Что-то пошло не так? Самое время не воевать до последнего, а остановиться и полноценно разобрать проблему. Ну, т.е. воспроизвести, найти причину, набросать в уме план починки и только затем что-то делать.
S>>В противном случае (и плюс ситуации, когда ближайшие итерации потребуют значительных правок в этом куске) — код хороший кандидат на починку. Z>Или на переписывание в момент запланированных правок. Это тоже может быть дешевле. Сравниваем риск правок*стоимость переписывания и стоимость починки сейчас. Пока никаких численных методов точной оценки ни левой ни даже правой части мы не имеем, решение принимается на основе интуиции.
Да, конечно. Главное принять фактическое решение о "берём в работу", а дальше кто чинит — тот и выбирает способ.
Я скорее про другой опыт, обратный: когда я не стал переписывать с нуля всё нафиг, хотя руки чесались. А вот когда я начал править, изменять, переделывать архитектуру иначе — вот тогда это была даже не ступенька вверх, а целый "эскалатор" вверх. Появились сомнения во многом. Здравые сомнения. Ушло юношеское "резать не дожидась перитонита" и всякие "что тут думать, прыгать надо" .
