Как пояснить клиенту что такое технический долг и рефакторинг?

Question

[nyann]

Прекращаю работать с некоторыми проектами уже не раз по причине того что плохая кодовая база с которой не хочется работать и изменить что-то я не в силах.
Пытался объяснять это клиентам и понял что это очень сложная тема, пока жареных петух не клюнет то никто не шелохнется.

В основном занимаюсь фулстек разработкой оригинальных продуктов, на Django/Ror, иногда это довольно сложные приложения, то есть не штампинг сайтов с использованием готовых решений.

Порой что-то на поддержку беру, иногда это проекты в которых сам код начинал писать, но из-за того что никогда не ведется работа по улучшению кода через полгода или год они становятся в обузой, появляются проблемы при оценке эстимейтов, непонятные баги которые трудно отловить и другие вытекающие, а все шишки валятся на голову разработчиков.

Хотелось бы узнать как вы с этим живете.

Answer 1

[Сергей Протько]

Клиент понимает только цифры, ему плевать на качество кода ровно до той поры, пока поддержка кода не станет ему в копеечку лишнюю. Приведите ему реальные доводы ЗА рефакторинг выражающиеся профитом в денежном эквиваленте и вуаля. Ну а если этих доводов нет - только личное мироощущение, то нужен ли рефакторинг?

Ну и коль уж мы про цифры, клиентов и технический долг, а как вы убедили клиента оплачивать вам время на написание тестов? Вы включаете это во время разработки при оценке стоимости? Что мешает заложить и рефакторинг критических мест. Вы не пишите тесты? Тогда о каком рефакторинге имеет смысл вести разговор? Тогда доводы должны быть просто железобетонные, что бы не тратить время на фул-тэст и поиск регрессий.

Comments

[nyann]

>Приведите ему реальные доводы ЗА рефакторинг выражающиеся профитом в денежном эквиваленте и вуаля.
Это не так уж и просто, допустим я назову какие-то цифры, но клиент вряд ли поймет откуда они возьмутся и за счет чего.
Тут похоже доверие играет важную роль.

>Ну и коль уж мы про цифры, клиентов и технический долг, а как вы убедили клиента оплачивать вам время на написание тестов? Вы включаете это во время разработки при оценке стоимости?
Именно так.

>Что мешает заложить и рефакторинг критических мест.
Обычно понимание того что нужен рефакоринг приходит спустя время, когда понимаешь что дело совсем плохо и все запущенно, тогда нужно значительное время на него, сложно просто так отвести на это хотя бы часов 10.

>Вы не пишите тесты? Тогда о каком рефакторинге имеет смысл вести разговор?
В более менее больших проектах которые я начинал они есть, но если проект я взял на поддержку и там нет тестов то приходится делать обычно еще и некоторый рефакторинг что бы можно было написать хоть какие-то тесты.

Answer 2

[Максим Кудрявцев]

Для начала скажите зачем Вы вообще хотите рефакторить код? Моральное удовлетворение?! Технический долг?! Вам что, приятнее трахаться с функциями в коде, чем со своей девушкой?

Работает код - не трогайте его, пусть дальше работает.

А вот если клиенту нужно сделать какую-то специальную фишку, для чего тебе нужно влезть в N*100 классов, добавить обработку новых входных параметров, прописать формирование и контроль выходных данных... Вообщем создает много гемороя, вот тогда ты говоришь клиенту, что это встанет в столько-то часов твоего времени и вот такой будет ценник и, если тот соглашается, уже начинаешь рефакторить.

Вообще где-то я видел мнение(тут на тостере или на codenet) что клиенту вообще не надо знать, что ты занимаешься рефакторингом, с чем лично я согласен. Ты показываешь ему свои почасовые отчеты, клиент видит что ты работаешь, все. Остальное уже те мелочи, от которых ты его избавляешь как специалист.

Comments

[nyann]

>Работает код - не трогайте его, пусть дальше работает.
Самой собой, хорошее правило, но не всегда...

>Для начала скажите зачем Вы вообще хотите рефакторить код? Моральное удовлетворение?! Технический долг?! Вам что, приятнее трахаться с функциями в коде, чем со своей девушкой?

Что бы иметь более менее четкую модульную архитектуру и четко понимать что как и где работает(что бы быть господином своего кода и управлять им, а не так что бы он мной... шутка), а не запутанную лапшу из кода и архитектуру похожую на бл****ий цирк, которую сложно дебажить и отлавливать баги.

За такой код сложно отвечать, никогда не знаешь что выкинет, отсюда ненужный стресс и все дела и о девушке уже и мыслей нет.

>Ты показываешь ему свои почасовые отчеты, клиент видит что ты работаешь, все.
Не всегда, клиент видит коммиты в рерозитории, но это ему мало о чем говорит, может я хренью занимаюсь.
Похоже тут опять доверие клиента важно.

[Максим Кудрявцев]

Анатолий K: Вы свою личную эффективность каким софтом отслеживайте? У меня лично стоит rescueTime и по запросу я клиентам скидываю скрины из личного кабинета, где видно сколько часов в сутки какие программы у меня открыты, сколько времени я провел на каких сайтах и т.д. Другими словами, я показываю клиентам что решаю их задачу, а не занимаюсь фигней...

Answer 3

[Евгений]

Рефачить или нет, исключительно Ваша инициатива, платить за нее Вам не будут, уговорить на это Вы никого не сможете. Так что если проект интересный или прибыльный, то нужно делать хорошо себе. Переписывать места с которыми больше всего проблем. Если нет(не интересный проект, не прибыльный), то не надо за него браться. И тут не особо важно сами Вы начинали проект, или взяли чужой на аутсорс.

Работаю в кровавом Java Enterprise. Тут рефакторинг не прекращается, он подобен ремонту в советской квартире. И влиять на заказчика получается только "бантиками", т.е. говорим, смотри какой клевый отчет мы забабахаем тебе! А сами думаем, под эту дудку, зарефачить наш механизм построения отчетов.
Как-то так)

Answer 4

[Артем Спиридонов]

Как объяснить? По-простому.

С первого раза хорошую вещь не сделаешь. Добиться качества можно только с двух, трех или большего количества разов.

Задача первого этапа - получить работающий образец. Хорошо, когда он полностью работоспособен, и даже находится в эксплуатации. Однако, для того, чтобы получить возможность *эффективного развития - нужна работа над качеством, в том числе и внутри.

Под *эффективностью подразумеваются большие результаты при меньших затратах. В этой связи сопровождение неоптимизированного кода влечет заведомо большие затраты, и главное - приводит к задержкам непредсказуемой длительности при отладке. Если есть намерение сделать разработку более линейной, и затраты предсказуемыми - нужен рефакторинг. А именно - приведение кодовой базы в стандартизированный вид, оптимизация структуры кода, возможно с избавлением от унаследованных неудачных решений.

Под затратами подразумеваются: финансовое обеспечение и временные затраты на разработку, а также количество работы, которое совершают руководители.

Answer 5

[Алексей Николаев]

Проблемы в целом не вижу. Если проект, который достался вам, состоит из говнокода, и ваша задача не глобальна, можно нагородить костылей в стиле предыдущего эксперта и закрыть задачу с чистой совестью. Если задач по проекту много, стоит вынести на повестку дня вопрос о рефакторинге, но так как задача глобальна, то вряд ли вопрос будет одобрен. Вариант - уйти и найти другой проект.

А если видно, что код и структура чисты, то конечно, костыли неприемлемы.

Мотивация здесь - исключительно оплата, как и в практически любой работе. И самое лучшее решение для того, чтобы не приходилось мучиться - просто не брать на поддержку самописные проекты, которые делались не вами.

Comments

[Армянское Радио]

Теория разбитых окон в действии

[Александр]

Ну или можно стоимость рефакторинга включить в доработку функционала если проект большой и работы там достаточно.

Answer 6

[iliyaisd]

1. Если рефакторинг объективно нужен для дальнейшей жизни проекта (т.е., дальнейшая разработка крайне затруднена без рефакторинга), то это обсуждается и закладывается во время. Аргумент: я потрачу 2 дня на рефакторинг и 3 дня на разработку, вместо того чтобы потратить 7 дней на разработку и дальше ещё хуже.
2. Если рефакторинг так критично не нужен, но жалателен, то какие-то отдельные наиболее запущенные классы правятся по ходу дела. Время разработки сильно не возрастает.
3. Во всех остальных случаях рефакторинг сильно и не нужен.
4. Если код с самого начала не нравится, то лучше не начинать проект.

Answer 7

[codingal]

Качество кода - это один из наименее важных факторов для 90% клиентов, исключение составляют клиенты-разработчики.
Сначала определитесь для чего вам самим нужен рефакторинг: из морально-этических побуждений или есть более конкретный "выхлоп" от рефакторинга - вы повыбрасываете все лишнее и вырастет производительность самого кода или вы будете добавлять новый функционал быстрее? Если и то и другое маловероятно и других конкретных причин нет, то может и не стоит ввзяываться в рефакторинг.

Хотелось бы узнать как вы с этим живете.

Иногда занимаемся "партизанщиной" - рефакторинг ведется за счет других задач.

Answer 8

[Илья Воропаев]

Надо смотреть по ситуации. Если нужна какая-то разовая небольшая доработка и потом этот код еще год никто не будет трогать, то проще сделать за пару часов костыль решающий проблему. Если же планируются серьезные доработки и придется вносить много изменений, то надо просто честно объяснить клиенту, что вложение сейчас в рефакторинг поможет ему сэкономить потом на доработках.
Т.е. клиент должен видеть выгоду для себя.
Я в такой ситуации объяснил клиенту, что текущий код не предусматривает нормальное расширение для добавления нового функционала и образно говоря или мы сейчас тратим 30 часов на рефакторинг и переписывание кода, чтобы он был гибким и его можно было развивать и легко внедрять новый функционал, или мы за 20 часов делаем все с помощью костылей и потом еще пару месяцев ловим всплывающие в неожиданных местах баги и тратим на их исправление (скорее всего очередными костылями) еще 20 часов.

Answer 9

[Mephistophele]

Есть 2 варианта:
1. Обсудить с клиентом и обосновав ему, что после рефакторинга для него 2+2 будет равно 3, а не 5 как сейчас.
2. Спрятать эти работы, размазав их тонким слоем по другим задачам. Заказчику в этом случае вы ничего не сообщаете.

Answer 10

[Igor Kalashnikov]

ИМХО, рефакторинг нужен, главное понимать зачем он нужен и решает ли это ваши проблемы или проблемы клиента. Если ваши - тогда делаете "по тихому", закладывая в эстимейты, если решает проблемы клиента -- можно попытаться это дело продать "отдельно", но и ответственность придется брать "отдельно", а оно вам надо?

Ставьте сроки повыше, объясняя повышенной запутанностью кода, и предлагайте, что можете навести порядок за столько то, и клиент выиграет уже через столько-то.

Answer 11

[Дмитрий Чернов]

Порой мы называли это тестированием и закладывали на это время.
Порой прямо говорили, что сложную вещь с первого раза не сделаешь, любое ПО выпускает постоянно обновления, ваше не исключение.
Но в любом случае, нужно объяснять какой будет результат и зачем. Просто так порефакторить если все работает и клиенту нравится не получится :)