Задать вопрос

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

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

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

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

Хотелось бы узнать как вы с этим живете.
  • Вопрос задан
  • 3719 просмотров
Подписаться 19 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 11
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
Клиент понимает только цифры, ему плевать на качество кода ровно до той поры, пока поддержка кода не станет ему в копеечку лишнюю. Приведите ему реальные доводы ЗА рефакторинг выражающиеся профитом в денежном эквиваленте и вуаля. Ну а если этих доводов нет - только личное мироощущение, то нужен ли рефакторинг?

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

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

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

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

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

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

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

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

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

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

Мотивация здесь - исключительно оплата, как и в практически любой работе. И самое лучшее решение для того, чтобы не приходилось мучиться - просто не брать на поддержку самописные проекты, которые делались не вами.
Ответ написан
@iliyaisd
1. Если рефакторинг объективно нужен для дальнейшей жизни проекта (т.е., дальнейшая разработка крайне затруднена без рефакторинга), то это обсуждается и закладывается во время. Аргумент: я потрачу 2 дня на рефакторинг и 3 дня на разработку, вместо того чтобы потратить 7 дней на разработку и дальше ещё хуже.
2. Если рефакторинг так критично не нужен, но жалателен, то какие-то отдельные наиболее запущенные классы правятся по ходу дела. Время разработки сильно не возрастает.
3. Во всех остальных случаях рефакторинг сильно и не нужен.
4. Если код с самого начала не нравится, то лучше не начинать проект.
Ответ написан
Комментировать
codingal
@codingal
Front end и не только
Качество кода - это один из наименее важных факторов для 90% клиентов, исключение составляют клиенты-разработчики.
Сначала определитесь для чего вам самим нужен рефакторинг: из морально-этических побуждений или есть более конкретный "выхлоп" от рефакторинга - вы повыбрасываете все лишнее и вырастет производительность самого кода или вы будете добавлять новый функционал быстрее? Если и то и другое маловероятно и других конкретных причин нет, то может и не стоит ввзяываться в рефакторинг.
Хотелось бы узнать как вы с этим живете.

Иногда занимаемся "партизанщиной" - рефакторинг ведется за счет других задач.
Ответ написан
Комментировать
SV0L0Ch
@SV0L0Ch
Разработчик специализируюсь на Bitrix и Wordpress
Надо смотреть по ситуации. Если нужна какая-то разовая небольшая доработка и потом этот код еще год никто не будет трогать, то проще сделать за пару часов костыль решающий проблему. Если же планируются серьезные доработки и придется вносить много изменений, то надо просто честно объяснить клиенту, что вложение сейчас в рефакторинг поможет ему сэкономить потом на доработках.
Т.е. клиент должен видеть выгоду для себя.
Я в такой ситуации объяснил клиенту, что текущий код не предусматривает нормальное расширение для добавления нового функционала и образно говоря или мы сейчас тратим 30 часов на рефакторинг и переписывание кода, чтобы он был гибким и его можно было развивать и легко внедрять новый функционал, или мы за 20 часов делаем все с помощью костылей и потом еще пару месяцев ловим всплывающие в неожиданных местах баги и тратим на их исправление (скорее всего очередными костылями) еще 20 часов.
Ответ написан
Комментировать
Mephistophele
@Mephistophele
Есть 2 варианта:
1. Обсудить с клиентом и обосновав ему, что после рефакторинга для него 2+2 будет равно 3, а не 5 как сейчас.
2. Спрятать эти работы, размазав их тонким слоем по другим задачам. Заказчику в этом случае вы ничего не сообщаете.
Ответ написан
Комментировать
zo0m
@zo0m
full stack developer
ИМХО, рефакторинг нужен, главное понимать зачем он нужен и решает ли это ваши проблемы или проблемы клиента. Если ваши - тогда делаете "по тихому", закладывая в эстимейты, если решает проблемы клиента -- можно попытаться это дело продать "отдельно", но и ответственность придется брать "отдельно", а оно вам надо?

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

Войдите, чтобы написать ответ

Похожие вопросы