У меня время от времени появляется необходимость добавить новый функционал к коду, написанному лет восемь назад. И тогда довольно часто возникает дилемма: переписывать ли старый код целиком, либо добавлять к нему одну заплатку за другой.
Старый код написан неграмотно, и если его переписывать с нуля, избегаешь прошлых ошибок – это как строить город по заранее составленному проекту, с большими проспектами. Но переписывание кода с нуля – большая работа, и поэтому часто я выбираю просто добавление к коду разных заплаток. И чем больше этих заплаток, тем легче в них окончательно запутаться. Проблему частично решает изобильное написание комментариев, которые служат “картой” в лабиринтах запутанного кода.
Как вы для себя решаете эти проблемы?
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, Khimik, Вы писали:
K>У меня время от времени появляется необходимость добавить новый функционал к коду, написанному лет восемь назад. И тогда довольно часто возникает дилемма: переписывать ли старый код целиком, либо добавлять к нему одну заплатку за другой. K>Старый код написан неграмотно, и если его переписывать с нуля, избегаешь прошлых ошибок – это как строить город по заранее составленному проекту, с большими проспектами. Но переписывание кода с нуля – большая работа, и поэтому часто я выбираю просто добавление к коду разных заплаток. И чем больше этих заплаток, тем легче в них окончательно запутаться. Проблему частично решает изобильное написание комментариев, которые служат “картой” в лабиринтах запутанного кода. K>Как вы для себя решаете эти проблемы?
Надо переписывать. Чтобы ничего не сломать — надо сначала написать тесты, полностью покрывающие старый код. Заплатки — только если нужно срочно сделать исправление и на качественную работу нет времени.
Комментарии лучше не писать. Это первейший признак плохого кода. Бывают исключения, но редко. Хочешь написать комментарий — вынеси код в функцию с названим, отражающим то, что ты хотел написать в комментарии.
Здравствуйте, vsb, Вы писали:
vsb>Комментарии лучше не писать. Это первейший признак плохого кода. Бывают исключения, но редко. Хочешь написать комментарий — вынеси код в функцию с названим, отражающим то, что ты хотел написать в комментарии.
Вот эта фраза зацепила. Мне кажется, это неверное мнение.
Писать комментарии, которые могут быть записаны в названии функции, действительно, не следует. Но это не значит, что их не нужно писать вообще.
Например, могут быть комментарии:
— почему в этом месте кода используется именно этот алгоритм, а не другой, очевидный
— почему делаются нетривиальные вещи (например, обход бага библиотеки)
— отсылка к стандарту, который предписывает дклать именно так
да и многое другое. Что это всё в имена переменных записывать? Или писать отдельный документ с комментариями к коду?
Кроме того, если совсем все комментарии записывать в имена методов, то можно легко получить малочитаемый код с огромным количеством методов из одной-двух строк.
Здравствуйте, vsb, Вы писали:
vsb>Комментарии лучше не писать. Это первейший признак плохого кода. Бывают исключения, но редко. Хочешь написать комментарий — вынеси код в функцию с названим, отражающим то, что ты хотел написать в комментарии.
Уже не первый раз встречаю подобное заблуждение. Название даже функции в 20 строчек порой не отображает то, что она делает, а мне именно это и нужно. И даже если код написан идеально — для разработчика это является потерей времени читать чужой код, когда все нужная для него информация должна быть в комментарии, еще лучше — писать комментарии на языке, на котором думает команда.
Здравствуйте, vmpire, Вы писали:
vsb>>Комментарии лучше не писать. Это первейший признак плохого кода. Бывают исключения, но редко. Хочешь написать комментарий — вынеси код в функцию с названим, отражающим то, что ты хотел написать в комментарии. V>Вот эта фраза зацепила. Мне кажется, это неверное мнение. V>Писать комментарии, которые могут быть записаны в названии функции, действительно, не следует. Но это не значит, что их не нужно писать вообще. V>Например, могут быть комментарии: V>- почему в этом месте кода используется именно этот алгоритм, а не другой, очевидный V>- почему делаются нетривиальные вещи (например, обход бага библиотеки) V>- отсылка к стандарту, который предписывает дклать именно так V>да и многое другое. Что это всё в имена переменных записывать? Или писать отдельный документ с комментариями к коду?
Это нормальные причины. Это и есть редкие исключения. Можно и отдельный документ написать, если реализован какой-то хитрый алгоритм.
V>Кроме того, если совсем все комментарии записывать в имена методов, то можно легко получить малочитаемый код с огромным количеством методов из одной-двух строк.
Если вынесение чего-то в метод не прибавляет читабельности, это не надо делать.
Здравствуйте, IncremenTop, Вы писали:
vsb>>Комментарии лучше не писать. Это первейший признак плохого кода. Бывают исключения, но редко. Хочешь написать комментарий — вынеси код в функцию с названим, отражающим то, что ты хотел написать в комментарии.
IT>Уже не первый раз встречаю подобное заблуждение. Название даже функции в 20 строчек порой не отображает то, что она делает, а мне именно это и нужно.
20 строчек это уже практически предел размера функции. Уже стоит задуматься о декомпозиции. А уж если название функции не отражает то, что она делает — то и задумываться не нужно.
IT>И даже если код написан идеально — для разработчика это является потерей времени читать чужой код, когда все нужная для него информация должна быть в комментарии
Потерей времени будет полагаться на комментарий, в котором написано одно, а в коде другое.
IT> еще лучше — писать комментарии на языке, на котором думает команда.
И все будущие команды, которые будут иметь дело с этим кодом. Этот язык — английский.
Здравствуйте, vsb, Вы писали:
vsb>Это нормальные причины. Это и есть редкие исключения.
Это не редкие исключения. Это вы, возможно, не работали на проектах со сложной бизнес-логикой или математикой, где плотность этой бизнес-логики в коде может быть очень высока. Если комментариев и ссылок в них на алгоритмы и джиры не будет, то каждые 5 строчек в голове может возникать "WTF???".
vsb>Можно и отдельный документ написать, если реализован какой-то хитрый алгоритм.
Можно. И ссылку на него — в комментарий
Здравствуйте, vsb, Вы писали:
vsb>20 строчек это уже практически предел размера функции. Уже стоит задуматься о декомпозиции. А уж если название функции не отражает то, что она делает — то и задумываться не нужно.
Название может отражать, но не полностью.
vsb>Потерей времени будет полагаться на комментарий, в котором написано одно, а в коде другое.
Это неверно проведенный рефакторинг. И да — с названиями функций та же беда.
vsb>И все будущие команды, которые будут иметь дело с этим кодом. Этот язык — английский.
Нет, это заблуждение. Если бы разработчики думали на английском именно, как носители, то явно бы не работали на российские бомж-конторы за низкие ценники. В 95% случаев никакие носители языка не будут читать ваш код. Особенно забавно видеть английские комментарии в сугубо российских продуктах по автоматизации ооо "вектор".
Вообще, это очень хорошо проверяется — дается код стороннему разработчику(а не изначальной команде зеленого проекта). И я почему-то уверен, что вопросы возникнут и именно их скорее всего нужно отобразить в комментарии.
Здравствуйте, vsb, Вы писали:
vsb>Надо переписывать.
Можете обосновать этот совет? Мне вот всё-таки кажется, что с заплатками часто суммарная работа намного меньше, чем с переписыванием. У меня проект не коллективный.
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, Khimik, Вы писали:
vsb>>Надо переписывать.
K>Можете обосновать этот совет? Мне вот всё-таки кажется, что с заплатками часто суммарная работа намного меньше, чем с переписыванием. У меня проект не коллективный.
В определённый момент проект станет неподдерживаемым. Фикс одного бага будет порождать два новых. Разобраться в том, что происходит, перестанет быть возможным. Будут разные мистические баги после полнолуния в четверг. Обычно в этот момент весь проект переписывают. И это обходится гораздо дороже, чем поддержание старого проекта в нормальном состоянии.
Есть понятие технического долга. Мы или пишем всё как положено, или пишем на тяп-ляп. Во втором случае мы берём в долг. Мы пишем быстрее, но на нас вешается технический долг. И этот долг надо отдать (привести код в порядок). Чем дольше не отдаёте долг, тем больше процентов по нему капает, тем хуже всё будет.
Возможно к проекту одного человека это не относится. Особенно если он не очень большой и "помещается в голову". Хотя, на мой взгляд, это универсальные принципы.
vsb>Есть понятие технического долга. Мы или пишем всё как положено, или пишем на тяп-ляп. Во втором случае мы берём в долг. Мы пишем быстрее, но на нас вешается технический долг. И этот долг надо отдать (привести код в порядок). Чем дольше не отдаёте долг, тем больше процентов по нему капает, тем хуже всё будет.
Кто пишет тяп-ляп, тот быстро сдаёт проект, получает премию, увольняется, идёт с повышением зарплаты в другом месте писать тяп-ляп. Кто отдаёт технический долг, тот остаётся "поддерживать" (т. е. пытается заставить работать в боевых условиях) то, что написал уволившийся, под звуки воспоминаний начальством, какой был мега-разработчик, а вы тут не можете его гениальное творение всего лишь нормально поддерживать.
K>У меня время от времени появляется необходимость добавить новый функционал к коду, написанному лет восемь назад. И тогда довольно часто возникает дилемма: переписывать ли старый код целиком, либо добавлять к нему одну заплатку за другой.
...
Что значит: переписать целиком, переписать с нуля?
Прежде, чем писать, надо провести анализ существующей архитектуры.
И посмотреть, мож и не все сразу переписывать надо?
Я б начал с анализа, в какие места наиболее часто приходится делать добавки.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Khimik, Вы писали:
K>У меня время от времени появляется необходимость добавить новый функционал к коду, написанному лет восемь назад. И тогда довольно часто возникает дилемма: переписывать ли старый код целиком, либо добавлять к нему одну заплатку за другой.
В один прекрасный день всё провалится под собственным весом. K>Старый код написан неграмотно, и если его переписывать с нуля, избегаешь прошлых ошибок – это как строить город по заранее составленному проекту, с большими проспектами.
Ну не с 0, у тебя уже есть наработки и алгоритмы. Если правильно сделать декомпозицию системы, изолировать алгоритмы и покрыть их юнит-тестми, то всё это потом можно будет либо копипастой, либо целыми библиоткеками перенести в новую инраструктуру. Ну а если смотреть на это по другому, то во время рефакторинга у тебя система просто примет тот вид который ты хочешь. K>Как вы для себя решаете эти проблемы?
Постоянный рефакторинг + юнит тесты.
Здравствуйте, Khimik, Вы писали: K>Как вы для себя решаете эти проблемы?
Ничего нельзя переписывать. Вам кажется, что вы "избежите старых ошибок". На самом деле вы всего лишь внесёте новые.
Решайте только реальные проблемы. Если вам не нравится то место, в которое вы сейчас вносите изменения, то делайте локальный рефакторинг.
Переписывание с нуля — это работа с очевидным убытком и неочевидной выгодой.
Сначала вам надо добиться значительного тестового покрытия. Радикалы требуют 100%, но это требование — гарантия провала. Мало-мальски сложный проект покрыть на 100% невозможно.
Это займёт примерно в 2 раза больше времени, чем вы запланируете.
Затем вы начнёте переписывать код с нуля.
Это займёт примерно в 2 раза больше времени, чем вы запланируете.
Потом вы станете запускать тесты, и окажется, что надо потратить ещё X времени на это, т.к. половина тестов жёстко привязана к реализации, и фейлятся с новым кодом, несмотря на его корректность.
Потом окажется, что новый красивый код всё же фейлит некоторые тесты, потому что часть выброшенных в новой архитектуре заплаток решала неочевидные проблемы.
Обычно на этом этапе превышение бюджета становится настолько значительным, что принимается решение "а ну его в баню", со старого кода сдувается пыль, а новый код отправляют в музей поля чудес.
Если же желание нового оказывается сильнее жадности и здравого смысла, то тесты доводятся до 100% успеха и новая версия выпускается в свет.
Два-три года спустя половина народа всё ещё сидит на древней версии, потому что реальная эксплуатация выявила несколько десятков критичных проблем, которые не отлавливались тестами.
У целевой аудитории нет доверия к новой версии из-за этого. В итоге вам приходится маинтейнить две кучи дерьмокода вместо одной.
Греть вас будет только одно: мало кто из разработчиков не падал в эту яму. Из самого недавнего — посмотрите на Microsoft с их Edge.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vsb, Вы писали:
vsb>Надо переписывать. Чтобы ничего не сломать — надо сначала написать тесты, полностью покрывающие старый код. Заплатки — только если нужно срочно сделать исправление и на качественную работу нет времени.
А что ты собираешься в тесты выносить ? Для старого кода как правило нет никакой документации и требований.
Переписывание это автоматически потеря всех вырожденных случаев, неочевидных проблем и тд и тд. Скажем, если в код коммиты делались лет 5 время от времени, то переписать за обозримое время просто не получится.
Старый, древний код имеет смысл рефакторить с самых низов — с функций, которые имеют по минимуму зависимостей, используя автоматические инстурменты — переименование, выделение функций, инлайн и тд.
Есть много способов радикально изменить структуру кода, сделать его более гибким, понятным и дешевым в майнтенансе и при этом достаточно надежным для применения в продакшне. Переписывание сюда никак не вписывается. Это, фактически, обнуление накопленого экспириенса.
Здравствуйте, IncremenTop, Вы писали:
IT>Уже не первый раз встречаю подобное заблуждение. Название даже функции в 20 строчек порой не отображает то, что она делает, а мне именно это и нужно. И даже если код написан идеально — для разработчика это является потерей времени читать чужой код, когда все нужная для него информация должна быть в комментарии, еще лучше — писать комментарии на языке, на котором думает команда.
У разработчика вообще говоря основная обязанность — читать чужой код. Комментарии, которые описывают код, не нужны.
Комментарии можно майнтейнить только руками. Все рефакторинги, особенно автоматические, резко прекращаются, когда девелоперов обязывают майнтейнить каменты.
В одном месте сменил сигнатуру функции или сделал какой инлайн — и в 50 местах надо сменить каменты. И то руками, руками, руками.
Отсюда ясно, что код должен читаться предельно просто. А вот вещи, где нужны каменты, это как раз то, что не следует явно из кода. Например баги ОС, платформы, хитрые оптимизации, косяки либы-фремворка, вырожденные случаи и тд и тд.
Здравствуйте, vsb, Вы писали:
vsb>20 строчек это уже практически предел размера функции. Уже стоит задуматься о декомпозиции. А уж если название функции не отражает то, что она делает — то и задумываться не нужно.
Название функции точно не должно отражать то, что она делает. Это скорее признак плохого кода, когда название повторяет то, что делает функция.
Например indexOf это хорошее имя, а вот что именно делает функция, что бы найти индекс, совершенно не актуально.
Здравствуйте, MozgC, Вы писали:
MC>Это не редкие исключения. Это вы, возможно, не работали на проектах со сложной бизнес-логикой или математикой, где плотность этой бизнес-логики в коде может быть очень высока. Если комментариев и ссылок в них на алгоритмы и джиры не будет, то каждые 5 строчек в голове может возникать "WTF???".
Ссылки на алгоритмы можно всунуть в каменты. Как именно код реализует алгоритм — дело десятое.
Здравствуйте, IncremenTop, Вы писали:
vsb>>Потерей времени будет полагаться на комментарий, в котором написано одно, а в коде другое. IT>Это неверно проведенный рефакторинг. И да — с названиями функций та же беда.
Вот-вот. С требованием каментить код весь рефакторинг идет к чертям.
Из моего опыта, самый жосцкий говнокод был именно там, где требовали каменты писать и майнтейнить. В итоге никто и никогда в своём уме не занимался рефакторингом.
