Comments 62
Не просить время на рефакторинг...
Спорно.
Надо спросить. Получить отказ. Решить что руководитель идиот и зря получает деньги. А вот потом уже тратить на реф свои собственные ресурсы
Бывают разные проекты, разные команды, разные задачи. Наша команда получила легаси код в ужасном состоянии и начальство вполне понимая ситуацию дало нам достаточно времени на приведение кода в порядок, написание документации, рефакторинг и всё остальное, что было нужно. Это не мешает пилить попутно бизнес-фичи, а наоборот помогает. Если бы нужно было пилить бизнес-фичи поверх легаси, ничего не меняя, то просто бы все уволились в очередной раз и всё. А так работают, всё хорошо, всем интересно.
Свое время тратить не нужно. Нужно заложить время на рефакторинг при планировании следующей доработки.
Просто накидывать процентов 5 на риски их использовать потом.
Ну вот доработка типа "добавить еще один алгоритм расчета чего-нибудь". Вы понимаете, что уже реализованные алгоритмы - это дикая мешанина, без документации и тестов. Разобраться в этом болоте - работы на пару недель. Как вы убедите заказчика, что реализация простенького алгоритма из пары арифметических действий требует две недели?
Так я же пишу 5%, а не две недели. Тут просто много небольших попутных изменений, которые делают код чище.
То что чисто надо писать код нового алгоритма - ок. Со старыми алгоритмами из моего примера - что делать? Один новый алгоритм добавить - ну максимум 4 часа. Это с кодированием и тестированием.
5% от 4 часов это 12 минут. Что там за 12 минут можно в старых алгоритмах вычистить?
В общем, я пока сторонник мнения, что время на рефакторинг надо выделять отдельно.
Ну вот для примера мой сегодняшний кейс. У нас каждый день дейлик на 30 мин. Скрам - все дела. Вот пока тема меня не касается сижу и рефакторю код.
Вроде 20 мин не много, но оно каждый день. Главное иметь план рефакторинга. Это один из вариантов как найти время.
Ну или если доработка не 4 часа, а 20, тут тоже уже можно немного заложить на рефакторинг.
а потом тебя спросят почему ты не занимаешься основной задачей
Так это часть основной задачи. Только нужно делать не буквально то, что написано. А старать делать код немного чище, чем было до доработки.
Опять же это все будет проверно тестами при ввпуске доработки, т.е. риск регресса минимальный
Кто спросит? Чтобы определить чем я занимаюсь нужно быть ну весьма прошареным либо шпионить за всеми моими действиями. Со стороны даже разные среды разработки выглядят одинаково.
5% на рефакторинг легаси? даже не смешно. Обычно если лезешь в рефакторинг, то тратишь половину если не больше общего времени на задачу, по моему опыту.
так потому и тратите половину времени, что выделяете именно под рефакторинг время.
Если же проводить рефакторинг именно тех мест, что вы правите, то и рефакторинга будет немного (столько же, но сильно размазан по коммитам) и он будет проходить вместе с коммитами, а то, что правкам не подвергается, получается - не важно хорошо или плохо написано: итак работает.
Так обычно рефакторинг в рамках одной двух функций не получается, если заменять по уму.
Если потихоньку чистить локально по методу бой-скаута, тогда да, по сути это просто часть задачи на которую итак заложено копание в легаси и нахождение нужного места встройки. Но по опыту глобально проект это не выправляет.
По хорошему рефакторинг это отдельные задачи с покрытием тестами старого кода и переделывания в новый. Но за такое не заплатят да.
Вообще, если любой принцип довести до абсолюта, то будет получаться абсурд (об этом собственно в стате и спич, насколько я понимаю).
Соответственно можно говорить о принципе "в среднем придерживаемся такого подхода, но если что-то удобнее - не боимся выйти за границы".
Понятное дело, что если вы накопили сумасшедшее количество кода который НЕОБХОДИМО рефакторить и без этого не продвинуться - то вы просите время у начальства. Это нормально.
Но, если вы просто развиваете проект, как обычно, то можно рефакторить "по месту".
И здесь, кстати, вполне будут возможности обоснования "почему для добавления поля 2+2 надо 2 недели времени". Вы просто отвечаете: "потому что до этого наша система не была заточена на сложение чисел и эта задача - новая для неё".
Как-то так.
Ошибкой будет, как раз, добавить "2+2" быстро и костылём, а потом клянчить время у начальства на "поправить правильно".
Рефакторинг по мелочи вообще не эффективен
Иногда нужно поднять старые пласты говна. Вы будете делать это в своё время и на энтузиазме?
Мой вариант решения проблемы: правило бойскаута «оставь место стоянки чище, чем оно было до твоего прихода». В рамках любой задачи немного рефакторишь старый код. Бывают запущенные случаи и это длится годами
Да был у меня опыт получения премии раз в квартал, но за новые проекты. И написать для директора, что то вроде переписывания уже работающего процесса было не уместно.
А просто заложить время на рефакторинг, когда оцениваешь сроки?
Не надо, как менеджеры, умножать сроки на 3.14, но есть же ещё 2.71?! :-)
Да, функциональное программирование это новая штука
Ахаха
Кстати, а что это за видео?
Вы сейчас не пошутили?
Если вдруг нет, это Хуан Хойя Борха, ищется по словам Хохотун (есть даже статья в Википедии), Испанец-хохотун, Ризитас. А пародиям и мемам на его знаменитое видео-интервью несть числа.
Видел несколько "фэйковых переводов" этого видео. Один из лучших вот этот: https://youtu.be/AaESGrylj7k?si=vWsw690LZUCWstIM
Потом оригинал посмотрел --- ничем не хуже)
Не нужно просить отдельное время на рефакторинг. Делайте его в рамках реализации функциональности.
Зависит от объема рефакторинга. Еслти его много - сложно утаить
Это был «хорошо поддерживаемый код», а не «легаси-код». Пожалуйста, не гонитесь за новыми инструментами только потому, что они новые и блестящие
Есть очень простой и в тоже время важный фактор - наличие deprecated компонент. Если они есть - код уже legacy. И по фиг, если он прекрасен, покрыт тестами и может быть легко изменен. Хотя ... где-то в мире маленьких денег возможно это не так
Слепо следовать «лучшим практикам»
Я думаю, проблема в слове "слепо", а не 2следовать". Чаще всего, люди просто не понимают, в чем именно лучшая практика заключается
Чаще всего, люди просто не понимают, в чем именно лучшая практика заключается
Недавний хайп вокруг критики "чистого кода" заключался в том, что критик применил его к бутылочному горлышку, требующему оптимизации. Странно, что эта очевидная манипуляция так расфорсилась.
не хочешь узнать какие компьютеры используются в Европе для управления ЖД-транспортом? )))
Не нужно просить отдельное время на рефакторинг. Делайте его в рамках реализации функциональности.
Ужасно если в PR помимо задачи въехал ещё и рефакторинг. Ревьюить его будет одно удовольствие
А как же "правило бойскаута" ?
А в чем сложность? Если рефакторинг делается отдельным комитом, перед или после основной задачи
Но все равно это поедет в один PR. И ревьеру это придется смотреть все одной портянкой, пытаясь разделить бизнес логику и изменение функциональности с обычным рефакторингом
Ага, зато если его не делать, разработчик будет наслаждаться каждый день, пытаясь понять что вообще происходит в проекте. Один час времени проверяющего на десятки часов других разработчиков.
Вы не умеете смотреть отдельные коммиты? Обычно рефакторинг делают до бизнес кода 1 коммитом.
Обычно рефакторинг делают в отдельном PR.
Я не делаю ревью по коммитам. Это какая-то бессмыслица смотреть 10 коммитов в которых несколько раз одно и то же место могло меняться. Время слишком дорого стоит, чтобы заниматься ерундой.
если одно и то же место меняется 10 раз - повод сразу режектнуть PR
Почему? Человек думает, пишет и ему нравится комитить свои изменения. Итог получился хорошим. Вроде все нормально. Подделывать историю коммитов мало кто любит, это какое-то бесполезное занятие.
Подделывать историю коммитов мало кто любит, это какое-то бесполезное занятие.
это бесполезное занятие для тех, кто никогда не использовал систему контроля версий... по назначению.
кстати, для чего по Вашему нужна система контроля версий?
В начале расскажите когда и зачем вы смотрели коммиты из смердженных веток? И как часто вы этим занимаетесь?
занимаюсь нечасто, но когда этим приходится заниматься, то этот аспект становится безумно важным
а вопрос "зачем" это и есть вопрос, что я задал Вам.
итак, зачем по Вашему нужна система контроля версий?
Только в случае, если совершенно не понимаешь почему тут сделано именно так, и ищешь кто, когда и в рамках какой задачи написал именно так. Иногда просто отсутствие правки там, где надо, а иногда там есть хитрая бизнес логика.
А зачем он это пушит? Берешь коммитишь локально дальше делаешь, потом сделал возврат подлил изменения.
Любой коммит вашей системы должен быть рабочим, я беру тыкаю Любой и жму старт, проект запускается и полноценно накатил все нужные миграции на чистой БД и начал работать.
Чтобы код оказался более чем на одном компьютере. Или чтобы прогнать CI/CD поверх кода. В современном мире микросервисов там интересное бывает.
Откуда у вас такое требование? Мастер должен переходить из одного рабочего состояния в другое. Что там в фича ветке вообще все равно. Это касается только того кто ее делает.
Согласен. Нужно как минимум разносить в разные коммиты рефакторинг и фичу. А может даже и отдельными PR.
Пункт номер 0 - игнорировать ИИ )
Спасибо! Отличные советы. Особенно понравился совет про кодера и программиста, тк сейчас только понимаю, что это абсолютная правда - можно написать гениальное ПО, но если оно никому не нужно, твой "гений" меркнет перед этим. Свои знания необходимо сочетать с нашим миром, тогда ты сможешь максимально удачно существовать, применяя знания и умения на практике, а просто совершенствование в чем-либо, и в кодировании в т.ч., никому кроме тебя не нужно, программист или инженер - это, в первую очередь, помощник народа, а не бодибилдер (колабилдер). Ещё раз спасибо!
Более-менее правдоподобно, за исключением:
1) пункт наверное разработчики банковских интерфейсов на вооружение взяли. Ну ладно календарь в экран не лезет, можно масштабом спастись, в консоли куча нотисов и ошибок, так ещё и выкладывают токен.
4) не понял - там где уместно использовать ООП, так и с функциональным, иногда не имеет смысла лишние объекты создавать, если функция используется редко и в одном сегменте; в чём то перекликается с п 5)
Немного статей из тех что я лайкаю, лайкаю с удовольствием. Но это прям-прям хорошая.
Единственная ошибка:
Да, функциональное программирование это новая штука
вообще, с функционального проггинга как бы не всё начиналось. man LISP. Хювеньен, Сапеньян и прочие...
Номер 3. Отлично сформулировано то чего я не понимал. Спасибо.
Все такие умные, прям...
10) Быть «кодером», а не инженером
Будьте «решателем проблем», использующим код как инструмент.
Если бы я был решателем проблем, то я бы использовал тебя, а не код. Вся правда жизни заключается именно в моей фразе.
О, опять функциональное программирование...
Не понимать, что такое «легаси-код»
На работе уже 20 лет работает сервер на Win2003. Никто операционку не трогает, обслуживание сводится с редкой замене выпадающих дисков RAID и минимальной читски в случае стучания кулеров.
А так же сервер с Debian 6, PHP 5.2, которому вроде как 10 лет. На старых версиях PHP не все понимают как писать код - всё же многая логика сильно изменилась.
А всё почему - производство, остановка и апгрейд всего этого выльется в нехилый простой и убыток компании. Работает, пусть и легаси - не трогай.
А что будет когда проблема раком встанет.
Интересная логика. А когда у этого сервера сгорит материнка, (подчеркну - не "если", а "когда". То есть это произойдет непременно, вопрос только во времени):
Придется купить новое железо.
Win2003 на него не станет. Станет только современная Windows.
Половина того системного софта, что стояло на Win2003, не станет на современную Винду. Придется ставить современные версии.
Половина прикладного софта откажется работать с обновленным системным софтом, потребовав допиливания или переписывания с нуля.
...То в какой простой и убыток выльется это компании?
Причем, скажу еще раз - событие это произойдет обязательно и непременно. Похоже, у ответственного за это человека удивительно крепкие нервы.
Одно из важных особенностей обновлений - решение вопросов с найденными дырами в безопасности
На бессознательном уровне ваши всегда-никогда поставят вас раком рано или поздно. Это детская логика.
После утверждения, что "функциональное программирование это что-то новое", смысл в заголовке вообще теряется, не рановато ли говорить о том, чего не стоит делать другим?
Я работал разработчиком более двадцати лет. Это не делает меня экспертом, но я считаю, что начинающим стоит обратить внимание на пункт 8. А все остальное очень спорно и индивидуально.
Я часто ловлю себя на том, что переусердствую с проектированием, когда нахожусь в «потоке»
Потому что проектированием нужно заниматься до этого. Я когда нахожусь "в потоке" - просто механически пишу код как робот по заранее придуманной модели, а когда нужно проектировать и вообще думать мозгом - ни о каком "потоке" и речи быть не может.
я бы добавил пункт, говорить руководству когда тебя что-то не утраивает или про сломанные процессы.
А по рефакторингу, у нас тоже накопился огромный список, и мы разрабы ставим перед фактом ПМ, что мы можем забить, но когда будет задача которая коснется этого кода, будут большие проблемы и последствия. И сейчас тот самый случай, стали делать редизайн, а там такой треш в логике, что этот редизайн уже не просто ui поменять, а всю логику перекраивать
Что разработчик никогда не должен делать