Comments 20
Подтверждаю, это очень сложно со стороны разработчиков продать высокому руководству идею о том чтобы «переписать» какую-то функциональность.
Руководство обычно более опытно в таких разговорах и обычно диалоги сводятся к таким:
— Михалваныч, пора рефакторинг делать!
— Да? А долго?
— Ну за три недели можно успеть.
— У, @$#%! А что поменяется?
— Ну для клиентов ничего, но…
— Так, никакого рефакторинга, давайте баги чините лучше!
Лучше действовать осторожнее:
— Семен, надо добавить кнопку чтоб сервера перезагружать удобнее.
— Михалваныч, три дня.
— @$%%";"%!!! Как три дня? Это ж просто кнопка! А если попрошу просто цвет поменять — ты скажешь что неделю?
— У нас очень сложный код. Если его переписать, то потом можно будет за полчаса все делать.
— Хмм, ну хорошо, сейчас не будем, но я подумаю.
Даже такой диалог полезен — на третий-пятый раз Михалваныч не выдержит и вам может повезти.
Вообще, в общении с начальством надо чтобы идеи приходили в голову ему, даже если первоначально они заходили к вам.
Руководство обычно более опытно в таких разговорах и обычно диалоги сводятся к таким:
— Михалваныч, пора рефакторинг делать!
— Да? А долго?
— Ну за три недели можно успеть.
— У, @$#%! А что поменяется?
— Ну для клиентов ничего, но…
— Так, никакого рефакторинга, давайте баги чините лучше!
Лучше действовать осторожнее:
— Семен, надо добавить кнопку чтоб сервера перезагружать удобнее.
— Михалваныч, три дня.
— @$%%";"%!!! Как три дня? Это ж просто кнопка! А если попрошу просто цвет поменять — ты скажешь что неделю?
— У нас очень сложный код. Если его переписать, то потом можно будет за полчаса все делать.
— Хмм, ну хорошо, сейчас не будем, но я подумаю.
Даже такой диалог полезен — на третий-пятый раз Михалваныч не выдержит и вам может повезти.
Вообще, в общении с начальством надо чтобы идеи приходили в голову ему, даже если первоначально они заходили к вам.
Пробовал, на деле Михалваныч как и вы, три-пять раз открещивается словами «подумаем».
Выбрал другой подход. Сейчас работаю с довольно запутанным веб-сервисом, код которого не рефакторился (как я понял) ни разу, тестов и документации тоже нема, благо хоть все писалось одним человеком и он все помнит. Весь новый функционал, который добавляется через меня я стараюсь покрывать тестами/документировать и писать так, чтобы разобраться в нем было просто и понятно. Избавляюсь от «запаха» в моем и «бижайшем» коде путем постепенного рефакторинга границ между тем что делаю я, и тем что уже имеется. Получается своего рода гамбургер, котлета в котором представляет не очень красивую границу между «чистым» и «грязным» кодом, но постепенно код сервиса становится все чище и пахнет ландышами.
Выбрал другой подход. Сейчас работаю с довольно запутанным веб-сервисом, код которого не рефакторился (как я понял) ни разу, тестов и документации тоже нема, благо хоть все писалось одним человеком и он все помнит. Весь новый функционал, который добавляется через меня я стараюсь покрывать тестами/документировать и писать так, чтобы разобраться в нем было просто и понятно. Избавляюсь от «запаха» в моем и «бижайшем» коде путем постепенного рефакторинга границ между тем что делаю я, и тем что уже имеется. Получается своего рода гамбургер, котлета в котором представляет не очень красивую границу между «чистым» и «грязным» кодом, но постепенно код сервиса становится все чище и пахнет ландышами.
То есть вы фактически делаете рефакторинг, но без одобрения руководства и включаете это время в разработку одобренных фич.
Это тоже способ и, наверное, самый спокойный для нервов. Пока не узнает начальство.
В моем опыте Михалваныч был в меру адекватным и раз в год время на рефакторинг по «техническому долгу» нам выделялось — недели три-четыре (целый спринт) на рефакторинг плюс пара мелких фич бонусом.
Это тоже способ и, наверное, самый спокойный для нервов. Пока не узнает начальство.
В моем опыте Михалваныч был в меру адекватным и раз в год время на рефакторинг по «техническому долгу» нам выделялось — недели три-четыре (целый спринт) на рефакторинг плюс пара мелких фич бонусом.
То есть вы фактически делаете рефакторинг, но без одобрения руководства и включаете это время в разработку одобренных фич
На практике затраченное на рефакторинг время окупается позже, а иногда и в кратном размере, потому на скорость работы это не сильно влияет. С другой стороны начальство за рефакторинг, просто оно не хочет делать его как отдельный таск.
Принцип «проще получить прощение, чем разрешение» хорошо работает как раз в таких случаях нерешительного начальства.
Ну то сам выступаешь с инициативой, а то подталкиваешь начальство к дозреванию во вопросу…
Остается вопрос — кто виноват.
Это как учебники в школе, получаешь исписанные и порванные а возвращаешь чистые и подклеенные. И это не прекращается ни для тебя, ни для тех кто после тебя.
Это как учебники в школе, получаешь исписанные и порванные а возвращаешь чистые и подклеенные. И это не прекращается ни для тебя, ни для тех кто после тебя.
Если каждый год новый легаси-проект, то только идти с евангелистикой — писать книжки, статьи на хабр :), на конфах выступать — и всех убеждать, что надо писать чистый код.
Если продукт более-менее надолго, то тут проще — жёсткое ревью кода, почаще встречаться и обсуждать архитектуру, юнит-тесты, опять же. Короче, сделать систему, в которой писать плохо просто не получится. И, да, это сложно, неблагодарно и не всегда понятно, с какой стороны подходить.
Если продукт более-менее надолго, то тут проще — жёсткое ревью кода, почаще встречаться и обсуждать архитектуру, юнит-тесты, опять же. Короче, сделать систему, в которой писать плохо просто не получится. И, да, это сложно, неблагодарно и не всегда понятно, с какой стороны подходить.
UFO just landed and posted this here
Разработчику от рефакторинга выгода тоже есть.
Меньше рутинной работы, меньше времени на разбор говнокода, быстрая реализация адекватных решений, развитие себя как разработчика, стремящегося к хорошему коду, навыки разбора чужого кода и облагораживания его.
Когда я вижу узкие/стремные места, я хочу привести их в порядок, хочу отрефакторить их. В том числе потому, что не хочу, чтобы в задачах, которые на меня делегируют, находили кучу багов, так как я не смог нормально разобраться в море непонятно чего, а сроки уже поджимали, и я налепил что-то сверху, просто чтобы как-нибудь там держалось.
Меньше рутинной работы, меньше времени на разбор говнокода, быстрая реализация адекватных решений, развитие себя как разработчика, стремящегося к хорошему коду, навыки разбора чужого кода и облагораживания его.
Когда я вижу узкие/стремные места, я хочу привести их в порядок, хочу отрефакторить их. В том числе потому, что не хочу, чтобы в задачах, которые на меня делегируют, находили кучу багов, так как я не смог нормально разобраться в море непонятно чего, а сроки уже поджимали, и я налепил что-то сверху, просто чтобы как-нибудь там держалось.
UFO just landed and posted this here
Мы видим что вы слегка троллите, но почему бы и не возразить, тем более, что аргументы еще есть.
Разработчику платят за время — соглашусь. Но разработчик стремится упростить жизнь и себе. Так называемая «чистота кода» — не просто эстетический принцип.
Есть разница как реализовать задачу «добавить кнопку»:
1. Нарисовать кнопку на форме (поиграться со стилями чтоб не съехало из-за таблиц), добавить обработчик на UI, добавить получатель события на бэкенде, захардкодить семь констант, отправить три сообщения и добавить sleep'ов чтоб получить ответ, реализовать саму операцию (документацию читать некогда, сделаю все сам), отладить, мат, починить, отладить, кофе, отладить, мат-кофе-мат-кофе, починить, починить, починить…
2. Просто добавить тип операции «reboot» в массив операций на UI (нарисует кнопку само, отрендерит, добавит стандартный обработчик), а на бэкенде из очереди сам заберет демон и все отработает (эта операция поддерживается движком, еще полгода назад с Серегой сделали).
В результате во втором случае мы помним что все нужно сделать в одном (максимум двух) местах.
А в первом случае мы затронули половину файлов проекта, голова пухнет — все не запомнить, местами лапша из таких же if'ов, которые остались от прошлого разработчика (интересно почему он уволился так быстро?), один тест не проходит (его пока отключим), а в комнату входит Михалваныч с задачей по еще одной кнопке.
В итоге получаем дергающийся глаз и недовольное начальство (первый случай) или грамоту за быструю работу (второй).
Разработчику платят за время — соглашусь. Но разработчик стремится упростить жизнь и себе. Так называемая «чистота кода» — не просто эстетический принцип.
Есть разница как реализовать задачу «добавить кнопку»:
1. Нарисовать кнопку на форме (поиграться со стилями чтоб не съехало из-за таблиц), добавить обработчик на UI, добавить получатель события на бэкенде, захардкодить семь констант, отправить три сообщения и добавить sleep'ов чтоб получить ответ, реализовать саму операцию (документацию читать некогда, сделаю все сам), отладить, мат, починить, отладить, кофе, отладить, мат-кофе-мат-кофе, починить, починить, починить…
2. Просто добавить тип операции «reboot» в массив операций на UI (нарисует кнопку само, отрендерит, добавит стандартный обработчик), а на бэкенде из очереди сам заберет демон и все отработает (эта операция поддерживается движком, еще полгода назад с Серегой сделали).
В результате во втором случае мы помним что все нужно сделать в одном (максимум двух) местах.
А в первом случае мы затронули половину файлов проекта, голова пухнет — все не запомнить, местами лапша из таких же if'ов, которые остались от прошлого разработчика (интересно почему он уволился так быстро?), один тест не проходит (его пока отключим), а в комнату входит Михалваныч с задачей по еще одной кнопке.
В итоге получаем дергающийся глаз и недовольное начальство (первый случай) или грамоту за быструю работу (второй).
Это не выгода разработчика. Рутинная или не рутинная работа — разработчику всё оплачивается одинаково, а выгода тут бизнесу.
Ну мы же с вами не обезьяны, правда? Мы же не только за еду работаем. Я, к примеру, пытаюсь еще стремиться к таким вещам, как саморазвитие и профессиональная раскачка как мегакодера. Оперируя вашими словами — чтобы получать больше бабла в дальнейшем.
Да, деньги, разумеется, имеют значение. Но и тут я на коне, реализуя задачи в два-три раза быстрее коллег по соседним проектам за счет высокого качества кода. Мое начальство видит, сколько делаю я, помнит, сколько делали до меня, и оценивает это. В том числе финансово.
Ага:) Навык рефакторинга, чтобы потом доказывать бизнесу, что ему нужен рефакторинг. Замкнутый круг.
Это не навык рефакторинга. Это стремление к чистому понятному коду, который понимаю не только я один, и в котором я смогу разобраться и через год. Обратная ситуация — помнишь код, пока помнишь костыли, которые там понаписал.
Я об этом и говорю. Рефакторинг проталкивают разработчики, и бизнес должен бы радоваться, что кто-то готов разгребать говнокод, но вместо этого разработчикам вставляют палки в колеса.
Все зависит от подачи.
«Мэмэмэ, мне тут нужно отрефакторить, чтобы мэмэмэ» — конечно будут палки в колеса. Бизнес не понимает, нафига это вообще надо.
«Коллеги, мне нужно потратить два дня на рефакторинг функционала расчета прайсов, но зато мы с вероятностью в 80% перестанем ловить постоянные баги, плюс время модернизации функционала (а мы его модернезируем постоянно) увеличится примерно на 40%. То есть затраты на рефаторинг отобьются в течении месяца, и в дальнейшем будем только экономить.» — и вперед.
На расчеты всех этих процентов и ожидаемой прибыли от рефакторинга уйдет больше времени, чем на сам рефакторинг )
мы с вероятностью в 80% перестанем ловить постоянные баги… время модернизации функционала (а мы его модернезируем постоянно) увеличится примерно на 40%
Честно говоря, больше похоже на речь ясновидящего, а не программиста) Не очень люблю давать такие громкие обещания менеджменту, потому что потом, чуть что, обязательно будут фразы «ну ты же говорил...», «уже два бага за неделю, а ты обещал...».
А если, действительно, сидеть и подробно анализировать, что время разработки увеличится именно на 40%, а не на 30, то как тут уже писали, на это времени может уйти как на сам рефакторинг :)
Я считаю, что лучший вариант — это когда бизнес и разработчики знают, как найти общий язык и хоть немного вникают в проблемы друг друга, а не живут в параллельных измерениях.
Боюсь, что какие-то количественные оценки вы все-таки должны будете выдать. Качественные оценки не катят.
Бизнес не устроит фраза «будет лучше», их всегда интересует «насколько лучше».
Бизнес не устроит фраза «будет лучше», их всегда интересует «насколько лучше».
Ну, лучший вариант — да. А что, если не знают пока, не нашли общий язык? Можно, конечно, работу поменять. Или всё-таки искать тот самый общий язык. Но только для того, чтобы он появился нужно понимать язык, на котором говорит бизнес. Тогда и своему, разработческому, языку научить его будет легче. Об этом примерно половина статьи :)
Только «подавать» вы будете не «бизнесу», а конкретному «манагеру» и не факт, что он мотивируется стратегическими бизнесовыми потребностями. И с позиции разработчика эти потребности скорее всего тоже не видны (зачастую они конфликтуют с потребностями разработки). Рационализм всей этой истории: нужно учиться аргументированнно обозначать проблему.
Не любая выгода имеет денежное выражение — сохраненные нервы это тоже выгода. Хотя, и от рефакторинга выгода тоже есть денежная разработчику — меньше тратить своих денег на восстановление нервов :)
Бизнес в общем случае не знает, а) что такое рефакторинг б) сколько он будет стоить в) сколько от него пользы.
Бизнес в общем случае не знает, а) что такое рефакторинг б) сколько он будет стоить в) сколько от него пользы.
спасибо за интересную статью! Имхо, самый безопасный в ожидаемой ситуации способ — закладывать стоимость рефакторинга в стоимость change request'а. Но, на моей практике были и случаи, когда непосредственно заказчику приходилось объяснять, почему нужно прямо сейчас делать рефакторинг, почему не через 2 месяца и к чему приведет обратное. В условиях наличия «компьютерной грамотности» со стороны заказчика, убедить в целом можно. К сожалению, для многих заказчиков (которые этой КГ не имеют), внедрение информационных систем и их разработка — это есть большой черный пузырь, который внешне не отличается, например, от строительства бань или продажи товаров по интернету. Построили вам баню, а потом приходят и говорят «вы знаете, архитектура этой бани недолговечна, нужно бы перелопатить все бревна». Тут ни о каком рефакторинге лучше вообще не упомянать.
Sign up to leave a comment.
Техобслуживание кода. Как «продать» рефакторинг бизнесу