Переписывание старого дерьмокода
От: Khimik  
Дата: 20.01.16 15:23
Оценка:
У меня время от времени появляется необходимость добавить новый функционал к коду, написанному лет восемь назад. И тогда довольно часто возникает дилемма: переписывать ли старый код целиком, либо добавлять к нему одну заплатку за другой.
Старый код написан неграмотно, и если его переписывать с нуля, избегаешь прошлых ошибок – это как строить город по заранее составленному проекту, с большими проспектами. Но переписывание кода с нуля – большая работа, и поэтому часто я выбираю просто добавление к коду разных заплаток. И чем больше этих заплаток, тем легче в них окончательно запутаться. Проблему частично решает изобильное написание комментариев, которые служат “картой” в лабиринтах запутанного кода.
Как вы для себя решаете эти проблемы?
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Re: Переписывание старого дерьмокода
От: vsb Казахстан  
Дата: 20.01.16 15:25
Оценка: 15 (3) +5 -2
Здравствуйте, Khimik, Вы писали:

K>У меня время от времени появляется необходимость добавить новый функционал к коду, написанному лет восемь назад. И тогда довольно часто возникает дилемма: переписывать ли старый код целиком, либо добавлять к нему одну заплатку за другой.

K>Старый код написан неграмотно, и если его переписывать с нуля, избегаешь прошлых ошибок – это как строить город по заранее составленному проекту, с большими проспектами. Но переписывание кода с нуля – большая работа, и поэтому часто я выбираю просто добавление к коду разных заплаток. И чем больше этих заплаток, тем легче в них окончательно запутаться. Проблему частично решает изобильное написание комментариев, которые служат “картой” в лабиринтах запутанного кода.
K>Как вы для себя решаете эти проблемы?

Надо переписывать. Чтобы ничего не сломать — надо сначала написать тесты, полностью покрывающие старый код. Заплатки — только если нужно срочно сделать исправление и на качественную работу нет времени.

Комментарии лучше не писать. Это первейший признак плохого кода. Бывают исключения, но редко. Хочешь написать комментарий — вынеси код в функцию с названим, отражающим то, что ты хотел написать в комментарии.
Отредактировано 20.01.2016 15:26 vsb . Предыдущая версия .
Re[2]: Переписывание старого дерьмокода
От: vmpire Россия  
Дата: 20.01.16 15:38
Оценка: 1 (1) +17
Здравствуйте, vsb, Вы писали:

vsb>Комментарии лучше не писать. Это первейший признак плохого кода. Бывают исключения, но редко. Хочешь написать комментарий — вынеси код в функцию с названим, отражающим то, что ты хотел написать в комментарии.

Вот эта фраза зацепила. Мне кажется, это неверное мнение.
Писать комментарии, которые могут быть записаны в названии функции, действительно, не следует. Но это не значит, что их не нужно писать вообще.
Например, могут быть комментарии:
— почему в этом месте кода используется именно этот алгоритм, а не другой, очевидный
— почему делаются нетривиальные вещи (например, обход бага библиотеки)
— отсылка к стандарту, который предписывает дклать именно так
да и многое другое. Что это всё в имена переменных записывать? Или писать отдельный документ с комментариями к коду?

Кроме того, если совсем все комментарии записывать в имена методов, то можно легко получить малочитаемый код с огромным количеством методов из одной-двух строк.
Re[2]: Переписывание старого дерьмокода
От: IncremenTop  
Дата: 20.01.16 16:18
Оценка: 8 (1) +7 -2
Здравствуйте, vsb, Вы писали:

vsb>Комментарии лучше не писать. Это первейший признак плохого кода. Бывают исключения, но редко. Хочешь написать комментарий — вынеси код в функцию с названим, отражающим то, что ты хотел написать в комментарии.


Уже не первый раз встречаю подобное заблуждение. Название даже функции в 20 строчек порой не отображает то, что она делает, а мне именно это и нужно. И даже если код написан идеально — для разработчика это является потерей времени читать чужой код, когда все нужная для него информация должна быть в комментарии, еще лучше — писать комментарии на языке, на котором думает команда.
Re[3]: Переписывание старого дерьмокода
От: vsb Казахстан  
Дата: 20.01.16 16:20
Оценка:
Здравствуйте, vmpire, Вы писали:

vsb>>Комментарии лучше не писать. Это первейший признак плохого кода. Бывают исключения, но редко. Хочешь написать комментарий — вынеси код в функцию с названим, отражающим то, что ты хотел написать в комментарии.

V>Вот эта фраза зацепила. Мне кажется, это неверное мнение.
V>Писать комментарии, которые могут быть записаны в названии функции, действительно, не следует. Но это не значит, что их не нужно писать вообще.
V>Например, могут быть комментарии:
V>- почему в этом месте кода используется именно этот алгоритм, а не другой, очевидный
V>- почему делаются нетривиальные вещи (например, обход бага библиотеки)
V>- отсылка к стандарту, который предписывает дклать именно так
V>да и многое другое. Что это всё в имена переменных записывать? Или писать отдельный документ с комментариями к коду?

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

V>Кроме того, если совсем все комментарии записывать в имена методов, то можно легко получить малочитаемый код с огромным количеством методов из одной-двух строк.


Если вынесение чего-то в метод не прибавляет читабельности, это не надо делать.
Re[3]: Переписывание старого дерьмокода
От: vsb Казахстан  
Дата: 20.01.16 16:24
Оценка: +2 -3
Здравствуйте, IncremenTop, Вы писали:

vsb>>Комментарии лучше не писать. Это первейший признак плохого кода. Бывают исключения, но редко. Хочешь написать комментарий — вынеси код в функцию с названим, отражающим то, что ты хотел написать в комментарии.


IT>Уже не первый раз встречаю подобное заблуждение. Название даже функции в 20 строчек порой не отображает то, что она делает, а мне именно это и нужно.


20 строчек это уже практически предел размера функции. Уже стоит задуматься о декомпозиции. А уж если название функции не отражает то, что она делает — то и задумываться не нужно.

IT>И даже если код написан идеально — для разработчика это является потерей времени читать чужой код, когда все нужная для него информация должна быть в комментарии


Потерей времени будет полагаться на комментарий, в котором написано одно, а в коде другое.

IT> еще лучше — писать комментарии на языке, на котором думает команда.


И все будущие команды, которые будут иметь дело с этим кодом. Этот язык — английский.
Отредактировано 20.01.2016 16:24 vsb . Предыдущая версия .
Re[4]: Переписывание старого дерьмокода
От: MozgC США http://nightcoder.livejournal.com
Дата: 20.01.16 16:38
Оценка: +8
Здравствуйте, vsb, Вы писали:

vsb>Это нормальные причины. Это и есть редкие исключения.


Это не редкие исключения. Это вы, возможно, не работали на проектах со сложной бизнес-логикой или математикой, где плотность этой бизнес-логики в коде может быть очень высока. Если комментариев и ссылок в них на алгоритмы и джиры не будет, то каждые 5 строчек в голове может возникать "WTF???".

vsb>Можно и отдельный документ написать, если реализован какой-то хитрый алгоритм.

Можно. И ссылку на него — в комментарий
Re[4]: Переписывание старого дерьмокода
От: IncremenTop  
Дата: 20.01.16 16:45
Оценка: +3 -1
Здравствуйте, vsb, Вы писали:

vsb>20 строчек это уже практически предел размера функции. Уже стоит задуматься о декомпозиции. А уж если название функции не отражает то, что она делает — то и задумываться не нужно.


Название может отражать, но не полностью.

vsb>Потерей времени будет полагаться на комментарий, в котором написано одно, а в коде другое.


Это неверно проведенный рефакторинг. И да — с названиями функций та же беда.


vsb>И все будущие команды, которые будут иметь дело с этим кодом. Этот язык — английский.


Нет, это заблуждение. Если бы разработчики думали на английском именно, как носители, то явно бы не работали на российские бомж-конторы за низкие ценники. В 95% случаев никакие носители языка не будут читать ваш код. Особенно забавно видеть английские комментарии в сугубо российских продуктах по автоматизации ооо "вектор".

Вообще, это очень хорошо проверяется — дается код стороннему разработчику(а не изначальной команде зеленого проекта). И я почему-то уверен, что вопросы возникнут и именно их скорее всего нужно отобразить в комментарии.
Re[2]: Переписывание старого дерьмокода
От: Khimik  
Дата: 20.01.16 20:31
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Надо переписывать.


Можете обосновать этот совет? Мне вот всё-таки кажется, что с заплатками часто суммарная работа намного меньше, чем с переписыванием. У меня проект не коллективный.
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Re[3]: Переписывание старого дерьмокода
От: vsb Казахстан  
Дата: 20.01.16 20:52
Оценка: 13 (2) +1
Здравствуйте, Khimik, Вы писали:

vsb>>Надо переписывать.


K>Можете обосновать этот совет? Мне вот всё-таки кажется, что с заплатками часто суммарная работа намного меньше, чем с переписыванием. У меня проект не коллективный.


В определённый момент проект станет неподдерживаемым. Фикс одного бага будет порождать два новых. Разобраться в том, что происходит, перестанет быть возможным. Будут разные мистические баги после полнолуния в четверг. Обычно в этот момент весь проект переписывают. И это обходится гораздо дороже, чем поддержание старого проекта в нормальном состоянии.

Есть понятие технического долга. Мы или пишем всё как положено, или пишем на тяп-ляп. Во втором случае мы берём в долг. Мы пишем быстрее, но на нас вешается технический долг. И этот долг надо отдать (привести код в порядок). Чем дольше не отдаёте долг, тем больше процентов по нему капает, тем хуже всё будет.

Возможно к проекту одного человека это не относится. Особенно если он не очень большой и "помещается в голову". Хотя, на мой взгляд, это универсальные принципы.
Отредактировано 20.01.2016 20:53 vsb . Предыдущая версия .
Re[4]: Переписывание старого дерьмокода
От: Osaka  
Дата: 20.01.16 23:59
Оценка: 16 (4) +7 :))) :))
vsb>Есть понятие технического долга. Мы или пишем всё как положено, или пишем на тяп-ляп. Во втором случае мы берём в долг. Мы пишем быстрее, но на нас вешается технический долг. И этот долг надо отдать (привести код в порядок). Чем дольше не отдаёте долг, тем больше процентов по нему капает, тем хуже всё будет.
Кто пишет тяп-ляп, тот быстро сдаёт проект, получает премию, увольняется, идёт с повышением зарплаты в другом месте писать тяп-ляп. Кто отдаёт технический долг, тот остаётся "поддерживать" (т. е. пытается заставить работать в боевых условиях) то, что написал уволившийся, под звуки воспоминаний начальством, какой был мега-разработчик, а вы тут не можете его гениальное творение всего лишь нормально поддерживать.
Re: Переписывание старого дерьмокода
От: LaptevVV Россия  
Дата: 21.01.16 07:49
Оценка: +1
K>У меня время от времени появляется необходимость добавить новый функционал к коду, написанному лет восемь назад. И тогда довольно часто возникает дилемма: переписывать ли старый код целиком, либо добавлять к нему одну заплатку за другой.
...
Что значит: переписать целиком, переписать с нуля?
Прежде, чем писать, надо провести анализ существующей архитектуры.
И посмотреть, мож и не все сразу переписывать надо?
Я б начал с анализа, в какие места наиболее часто приходится делать добавки.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: Переписывание старого дерьмокода
От: Kernan Ниоткуда https://rsdn.ru/forum/flame.politics/
Дата: 21.01.16 10:19
Оценка: 8 (1)
Здравствуйте, Khimik, Вы писали:

K>У меня время от времени появляется необходимость добавить новый функционал к коду, написанному лет восемь назад. И тогда довольно часто возникает дилемма: переписывать ли старый код целиком, либо добавлять к нему одну заплатку за другой.

В один прекрасный день всё провалится под собственным весом.
K>Старый код написан неграмотно, и если его переписывать с нуля, избегаешь прошлых ошибок – это как строить город по заранее составленному проекту, с большими проспектами.
Ну не с 0, у тебя уже есть наработки и алгоритмы. Если правильно сделать декомпозицию системы, изолировать алгоритмы и покрыть их юнит-тестми, то всё это потом можно будет либо копипастой, либо целыми библиоткеками перенести в новую инраструктуру. Ну а если смотреть на это по другому, то во время рефакторинга у тебя система просто примет тот вид который ты хочешь.
K>Как вы для себя решаете эти проблемы?
Постоянный рефакторинг + юнит тесты.
Sic luceat lux!
Re: Переписывание старого дерьмокода
От: Sinclair Россия https://github.com/evilguest/
Дата: 22.01.16 06:28
Оценка: 51 (9) +4 -1
Здравствуйте, Khimik, Вы писали:
K>Как вы для себя решаете эти проблемы?
Ничего нельзя переписывать. Вам кажется, что вы "избежите старых ошибок". На самом деле вы всего лишь внесёте новые.
Решайте только реальные проблемы. Если вам не нравится то место, в которое вы сейчас вносите изменения, то делайте локальный рефакторинг.
Переписывание с нуля — это работа с очевидным убытком и неочевидной выгодой.
Сначала вам надо добиться значительного тестового покрытия. Радикалы требуют 100%, но это требование — гарантия провала. Мало-мальски сложный проект покрыть на 100% невозможно.
Это займёт примерно в 2 раза больше времени, чем вы запланируете.
Затем вы начнёте переписывать код с нуля.
Это займёт примерно в 2 раза больше времени, чем вы запланируете.
Потом вы станете запускать тесты, и окажется, что надо потратить ещё X времени на это, т.к. половина тестов жёстко привязана к реализации, и фейлятся с новым кодом, несмотря на его корректность.
Потом окажется, что новый красивый код всё же фейлит некоторые тесты, потому что часть выброшенных в новой архитектуре заплаток решала неочевидные проблемы.
Обычно на этом этапе превышение бюджета становится настолько значительным, что принимается решение "а ну его в баню", со старого кода сдувается пыль, а новый код отправляют в музей поля чудес.
Если же желание нового оказывается сильнее жадности и здравого смысла, то тесты доводятся до 100% успеха и новая версия выпускается в свет.

Два-три года спустя половина народа всё ещё сидит на древней версии, потому что реальная эксплуатация выявила несколько десятков критичных проблем, которые не отлавливались тестами.
У целевой аудитории нет доверия к новой версии из-за этого. В итоге вам приходится маинтейнить две кучи дерьмокода вместо одной.

Греть вас будет только одно: мало кто из разработчиков не падал в эту яму. Из самого недавнего — посмотрите на Microsoft с их Edge.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Переписывание старого дерьмокода
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.01.16 10:20
Оценка: +1
Здравствуйте, vsb, Вы писали:

vsb>Надо переписывать. Чтобы ничего не сломать — надо сначала написать тесты, полностью покрывающие старый код. Заплатки — только если нужно срочно сделать исправление и на качественную работу нет времени.


А что ты собираешься в тесты выносить ? Для старого кода как правило нет никакой документации и требований.

Переписывание это автоматически потеря всех вырожденных случаев, неочевидных проблем и тд и тд. Скажем, если в код коммиты делались лет 5 время от времени, то переписать за обозримое время просто не получится.

Старый, древний код имеет смысл рефакторить с самых низов — с функций, которые имеют по минимуму зависимостей, используя автоматические инстурменты — переименование, выделение функций, инлайн и тд.

Есть много способов радикально изменить структуру кода, сделать его более гибким, понятным и дешевым в майнтенансе и при этом достаточно надежным для применения в продакшне. Переписывание сюда никак не вписывается. Это, фактически, обнуление накопленого экспириенса.
Re: Переписывание старого дерьмокода
От: 0x7be СССР  
Дата: 22.01.16 10:23
Оценка:
Здравствуйте, Khimik, Вы писали:

K>Как вы для себя решаете эти проблемы?

Согласен с точкой зрения Спольски: http://www.joelonsoftware.com/articles/fog0000000069.html

На практике видел последствия попыток сделать big band rewrite, последствия всегда были печальные.
Re[3]: Переписывание старого дерьмокода
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.01.16 10:26
Оценка:
Здравствуйте, IncremenTop, Вы писали:

IT>Уже не первый раз встречаю подобное заблуждение. Название даже функции в 20 строчек порой не отображает то, что она делает, а мне именно это и нужно. И даже если код написан идеально — для разработчика это является потерей времени читать чужой код, когда все нужная для него информация должна быть в комментарии, еще лучше — писать комментарии на языке, на котором думает команда.


У разработчика вообще говоря основная обязанность — читать чужой код. Комментарии, которые описывают код, не нужны.
Комментарии можно майнтейнить только руками. Все рефакторинги, особенно автоматические, резко прекращаются, когда девелоперов обязывают майнтейнить каменты.
В одном месте сменил сигнатуру функции или сделал какой инлайн — и в 50 местах надо сменить каменты. И то руками, руками, руками.

Отсюда ясно, что код должен читаться предельно просто. А вот вещи, где нужны каменты, это как раз то, что не следует явно из кода. Например баги ОС, платформы, хитрые оптимизации, косяки либы-фремворка, вырожденные случаи и тд и тд.
Re[4]: Переписывание старого дерьмокода
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.01.16 10:29
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>20 строчек это уже практически предел размера функции. Уже стоит задуматься о декомпозиции. А уж если название функции не отражает то, что она делает — то и задумываться не нужно.


Название функции точно не должно отражать то, что она делает. Это скорее признак плохого кода, когда название повторяет то, что делает функция.
Например indexOf это хорошее имя, а вот что именно делает функция, что бы найти индекс, совершенно не актуально.
Re[5]: Переписывание старого дерьмокода
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.01.16 10:30
Оценка:
Здравствуйте, MozgC, Вы писали:

MC>Это не редкие исключения. Это вы, возможно, не работали на проектах со сложной бизнес-логикой или математикой, где плотность этой бизнес-логики в коде может быть очень высока. Если комментариев и ссылок в них на алгоритмы и джиры не будет, то каждые 5 строчек в голове может возникать "WTF???".


Ссылки на алгоритмы можно всунуть в каменты. Как именно код реализует алгоритм — дело десятое.
Re[5]: Переписывание старого дерьмокода
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.01.16 10:33
Оценка:
Здравствуйте, IncremenTop, Вы писали:

vsb>>Потерей времени будет полагаться на комментарий, в котором написано одно, а в коде другое.

IT>Это неверно проведенный рефакторинг. И да — с названиями функций та же беда.

Вот-вот. С требованием каментить код весь рефакторинг идет к чертям.

Из моего опыта, самый жосцкий говнокод был именно там, где требовали каменты писать и майнтейнить. В итоге никто и никогда в своём уме не занимался рефакторингом.
Re[4]: Переписывание старого дерьмокода
От: IncremenTop  
Дата: 22.01.16 10:59
Оценка: +2 -3
Здравствуйте, Ikemefula, Вы писали:

I>У разработчика вообще говоря основная обязанность — читать чужой код. Комментарии, которые описывают код, не нужны.


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


I>В одном месте сменил сигнатуру функции или сделал какой инлайн — и в 50 местах надо сменить каменты. И то руками, руками, руками.


Это явно какой-то дефективный код(либо избыток комментов, либо излишняя связанность), если подобное происходит.
Re: Переписывание старого дерьмокода
От: tdiff  
Дата: 22.01.16 15:06
Оценка:
Здравствуйте, Khimik, Вы писали:

K>У меня время от времени появляется необходимость добавить новый функционал к коду, написанному лет восемь назад. И тогда довольно часто возникает дилемма: переписывать ли старый код целиком, либо добавлять к нему одну заплатку за другой.

K>Старый код написан неграмотно, и если его переписывать с нуля, избегаешь прошлых ошибок – это как строить город по заранее составленному проекту, с большими проспектами. Но переписывание кода с нуля – большая работа, и поэтому часто я выбираю просто добавление к коду разных заплаток. И чем больше этих заплаток, тем легче в них окончательно запутаться. Проблему частично решает изобильное написание комментариев, которые служат “картой” в лабиринтах запутанного кода.
K>Как вы для себя решаете эти проблемы?

Если у вас неограниченное количество времени и работодатель готов вам его оплачивать, то почему бы и не переписать всё с нуля. По-моему, такое случается редко, а если и случается, то решения принимает не разработчик и проблемы "принятия решения" у него никакой нет.

С другой стороны, в какой-то книжке читал совет типа "если у вас есть gut feeling, что для выполнения вашей работы надо переписать всё, но начальник не даёт денег — переписывайте! (на свой страх и риск)".
Re[5]: Переписывание старого дерьмокода
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.01.16 16:51
Оценка: -1
Здравствуйте, IncremenTop, Вы писали:

IT>Основной обязанностью прежде всего является разработка, чтение кода — это необходимость.


Ага, а еще более основной обязанностью является хождение на работу.

IT>Комментарии обязательны в контракте класса — это точно такая же необходимость. Именно благодаря этому я не лезу каждый раз в мсдн в поисках "а что же там входе и выходе у этой функции".



I>>В одном месте сменил сигнатуру функции или сделал какой инлайн — и в 50 местах надо сменить каменты. И то руками, руками, руками.


IT>Это явно какой-то дефективный код(либо избыток комментов, либо излишняя связанность), если подобное происходит.


Это нормально, когда используют полезную функцию или класс.
Re[2]: Переписывание старого дерьмокода
От: DiPaolo Россия  
Дата: 22.01.16 17:01
Оценка: +1 :))
Здравствуйте, tdiff, Вы писали:

T>С другой стороны, в какой-то книжке читал совет типа "если у вас есть gut feeling, что для выполнения вашей работы надо переписать всё, но начальник не даёт денег — переписывайте! (на свой страх и риск)".


Так и хочется добавить "... за свой счет (в свое свободное время)"
Патриот здравого смысла
Re[6]: Переписывание старого дерьмокода
От: IncremenTop  
Дата: 22.01.16 19:37
Оценка: -2
Здравствуйте, Ikemefula, Вы писали:

I>Ага, а еще более основной обязанностью является хождение на работу.


Не надо играть в демагогию. Нанимают программистов для разработки, а не для чтения кода.


I>Это нормально, когда используют полезную функцию или класс.


Ненормально, когда правят внешние обязательства множества полезных функции при рефакторинге.
Re[7]: Переписывание старого дерьмокода
От: vmpire Россия  
Дата: 22.01.16 20:37
Оценка: +2
Здравствуйте, IncremenTop, Вы писали:

IT>Не надо играть в демагогию. Нанимают программистов для разработки, а не для чтения кода.

Вы нанимаете отдельных людей для чтения кода и пересказа программистам?
Re[2]: Переписывание старого дерьмокода
От: __kot2  
Дата: 23.01.16 00:03
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, Khimik, Вы писали:


K>>Как вы для себя решаете эти проблемы?

0>Согласен с точкой зрения Спольски: http://www.joelonsoftware.com/articles/fog0000000069.html

0>На практике видел последствия попыток сделать big band rewrite, последствия всегда были печальные.

а я ксати был в мс свидетелем глобального переписывания. случилось все то, что здесь и говорят
— в результате переписывания возникла просто еше одна параллельная куча говнокода
— нафигачившие говнокод быстро свалили с повышением в другие отделы (я с тех пор отношусь подозрительно ко всем кто в мс быстро продвигается )
— было просрано очень много денег
— проект потом вообще закрыли, всех разогнали, в том числе и руководство
Re[7]: Переписывание старого дерьмокода
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.01.16 15:49
Оценка: -1
Здравствуйте, IncremenTop, Вы писали:

I>>Ага, а еще более основной обязанностью является хождение на работу.


IT>Не надо играть в демагогию.


Начни с себя, покажи пример.

>Нанимают программистов для разработки, а не для чтения кода.


Новое слово в разработке — писать не читая

I>>Это нормально, когда используют полезную функцию или класс.

IT>Ненормально, когда правят внешние обязательства множества полезных функции при рефакторинге.

Вот это и есть демагогия. Ранее ты предложил коментировать не только внешние обязательства, но и "что она делает". Вот это "что она делает" как раз и меняется рефакторингом на раз.
Кроме того, ты предложил фактически заменить чтение кода чтением каментов. Это значит, что вообще все важные моменты должны быть в каментах. И снова даже небольшой рефакторин заводит в тупик.
Ну и до кучи — внешние обязательства так же могут измениться. Например пропадут или появятся побочные эффекты. Если наблюдаемое поведение не изменилось — плевать.
Re[8]: Переписывание старого дерьмокода
От: IncremenTop  
Дата: 23.01.16 16:23
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Новое слово в разработке — писать не читая


Ок, раз не перестаешь играть в демагогию, то тоже передерну.
Новое слово в разработке — исключительно чтение кода. Открой отдельную библиотеку читающих программистов, зачем писать код, когда можно его просто читать?


I>Вот это и есть демагогия. Ранее ты предложил коментировать не только внешние обязательства, но и "что она делает". Вот это "что она делает" как раз и меняется рефакторингом на раз.


Мое:
"Название даже функции в 20 строчек порой не отображает то, что она делает, а мне именно это и нужно."

Поздравляю с тем, что нагло переврал мои слова.



I>Кроме того, ты предложил фактически заменить чтение кода чтением каментов. Это значит, что вообще все важные моменты должны быть в каментах.


Я предложил сократить чтение кода по-возможности, ибо это глупость во всех случаях читать код. Глупость в квадрате, когда программист по фронтенду будет лезть в бэкенд для чтения кода и будет тратить время на это. Также глупо и обратно — когда программист бэкенда будет делать обратное.
Потому что люди приходят и становятся программистами не для того, чтобы читать чужой код. И платят им не за это. Это — издержка, а издержки принято сокращать.

И да — действительно важные моменты должны быть в комментах, а не в голове у разработчика.

I>Ну и до кучи — внешние обязательства так же могут измениться. Например пропадут или появятся побочные эффекты. Если наблюдаемое поведение не изменилось — плевать.


До кучи изменять название функции и переменных точно также придется. Особенно пикантно выглядят названия, которые не умещаются даже в строчку.
Еще более пикантно, что ни во всех библиотечных функциях почему-то есть комментарии, не смотря на говорящие названия. Вокруг дураки(с).
Re: Переписывание старого дерьмокода
От: dr. Acula Украина  
Дата: 23.01.16 16:25
Оценка:
Здравствуйте, Khimik, Вы писали:

K>У меня время от времени появляется необходимость добавить новый функционал к коду, написанному лет восемь назад. И тогда довольно часто возникает дилемма: переписывать ли старый код целиком, либо добавлять к нему одну заплатку за другой.

Тесты хоть есть?
K>Старый код написан неграмотно, и если его переписывать с нуля, избегаешь прошлых ошибок – это как строить город по заранее составленному проекту, с большими проспектами. Но переписывание кода с нуля – большая работа, и поэтому часто я выбираю просто добавление к коду разных заплаток. И чем больше этих заплаток, тем легче в них окончательно запутаться. Проблему частично решает изобильное написание комментариев, которые служат “картой” в лабиринтах запутанного кода.
Такова жизнь.
K>Как вы для себя решаете эти проблемы?
Тесты.
Как только покрыли — переписываем.
Re[3]: Переписывание старого дерьмокода
От: dr. Acula Украина  
Дата: 23.01.16 16:27
Оценка:
IT>Уже не первый раз встречаю подобное заблуждение. Название даже функции в 20 строчек порой не отображает то, что она делает, а мне именно это и нужно. И даже если код написан идеально — для разработчика это является потерей времени читать чужой код, когда все нужная для него информация должна быть в комментарии, еще лучше — писать комментарии на языке, на котором думает команда.
Всё классно, кроме того, то команда может думать на разных языках.
Re[3]: Переписывание старого дерьмокода
От: dr. Acula Украина  
Дата: 23.01.16 16:34
Оценка: 8 (1)
I>Есть много способов радикально изменить структуру кода, сделать его более гибким, понятным и дешевым в майнтенансе и при этом достаточно надежным для применения в продакшне. Переписывание сюда никак не вписывается. Это, фактически, обнуление накопленого экспириенса.
Не всегда.
Есть случаи, и я с такими сталкивался, когда переписали 80% кода, те же люди, что и начинали. И никакой экспириенс никто не обнулил, наоборот, сделали относительно нормально, т.к. знали в чём трудности.
После того как поняли, что бороться с багами бесполезно.
Да, заняло порядочно времени, пришлось таки заняться тестированием, составить хоть какие-то требования.
Но это окупилось в итоге.
И да, проект не на одного человека.
Пока переписывали — правили баги в старом коде и документировали тщательнейшим образом.
Re[4]: Переписывание старого дерьмокода
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.01.16 12:22
Оценка:
Здравствуйте, dr. Acula, Вы писали:

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

DA>Не всегда.
DA>Есть случаи, и я с такими сталкивался, когда переписали 80% кода, те же люди, что и начинали. И никакой экспириенс никто не обнулил, наоборот, сделали относительно нормально, т.к. знали в чём трудности.
DA>После того как поняли, что бороться с багами бесполезно.

Может просто нечего было обнулять ?
Сразу возникает вопрос — рефакторинг пробовали ?

DA>Да, заняло порядочно времени, пришлось таки заняться тестированием, составить хоть какие-то требования.

DA>Но это окупилось в итоге.

Не ясно, что это значит. Порядочно — это больше чем на предыдущую версию или меньше ?
И что значит 'составить хоть какие то требования' ?
Окупилось — это не аргумент. Могло ли быть, что рефакторинг получился более эффективным ?
Re[9]: Переписывание старого дерьмокода
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.01.16 12:34
Оценка:
Здравствуйте, IncremenTop, Вы писали:

I>>Новое слово в разработке — писать не читая


IT>Ок, раз не перестаешь играть в демагогию, то тоже передерну.

IT>Новое слово в разработке — исключительно чтение кода.

Никто и не предлагает заниматься исключительно чтением кода. Бизнес-логику например нужно читать. А вот внешнюю либу совсем необязательно.
Вообще все что непосредственно код твоего приложения, нужно читать в обязательном порядке.

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

I>>Вот это и есть демагогия. Ранее ты предложил коментировать не только внешние обязательства, но и "что она делает". Вот это "что она делает" как раз и меняется рефакторингом на раз.


IT>Мое:

IT>"Название даже функции в 20 строчек порой не отображает то, что она делает, а мне именно это и нужно."
IT>Поздравляю с тем, что нагло переврал мои слова.

Название и не должно отображать что делает функция. Название — filterBy, и отсюда никак не следует, что именно делает функция.

IT>Я предложил сократить чтение кода по-возможности, ибо это глупость во всех случаях читать код.


Ты предложил заменить чтение кода чтением каментов. Это жосткое требование — слишком много работы без гарантии какого либо результата

IT>До кучи изменять название функции и переменных точно также придется. Особенно пикантно выглядят названия, которые не умещаются даже в строчку.


Ну так дай правильное имя. Глядишь, каменты и не понадобятся.

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


Публичный АПИ библиотек — единственное исключение. Каменты здесь выполняют совсем другую функцию. Точнее — докумнтация делается за счет каментов.
Не любой камент есть документация.
Re[10]: Переписывание старого дерьмокода
От: IncremenTop  
Дата: 24.01.16 13:08
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Вообще все что непосредственно код твоего приложения, нужно читать в обязательном порядке.


Верно лишь для маленьких проектов или для зеленых на первых стадиях. В остальных случаях — бред сивой кобылы.


I> А ты предлагаешь на этом не заморачиваться и заменить это каментами, на том основании что их легче читать.


Я не предлагал это.
Не надо вешать свою булевскую логику на все случаи жизни.

Если снова не смог прочесть мои слова, то переведу проще — "комментарии нужны, чистый код никогда их не заменит полностью". Твои фантазии меня не интересуют, выше можешь прочесть, что я действительно сказал, а не ты выдумал.


I>Название и не должно отображать что делает функция. Название — filterBy, и отсюда никак не следует, что именно делает функция.


Еще прелестнее.

I>Ну так дай правильное имя. Глядишь, каменты и не понадобятся.


Комментарии понадобятся, ибо читать, что делает внешняя в рамках данной работы функция необязательно и затратно.


I>Публичный АПИ библиотек — единственное исключение. Каменты здесь выполняют совсем другую функцию. Точнее — докумнтация делается за счет каментов.


Я приводил выше пример — не должен программист бэкенда лазить во фронтенде. У них разные специализации и это потеря времени. Точно также какой-нибудь математик-алгоритмист не должен лазить в бэкенде. Это глупо и нерациональное расходование средств.
Re[5]: Переписывание старого дерьмокода
От: Privalov  
Дата: 24.01.16 13:23
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Например indexOf это хорошее имя, а вот что именно делает функция, что бы найти индекс, совершенно не актуально.


Сдается мне, indexOf точно отражает, что именно делает функция. А вот то, как она это делает, пользователя не интересует. Если же внутри что-то хитро вывернутое, то в начале функции пишем комментарий, содержащий ссылку на документ, описывающий алгоритм, используемый в функции.
Re[11]: Переписывание старого дерьмокода
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.01.16 16:08
Оценка:
Здравствуйте, IncremenTop, Вы писали:

I>>Вообще все что непосредственно код твоего приложения, нужно читать в обязательном порядке.


IT>Верно лишь для маленьких проектов или для зеленых на первых стадиях. В остальных случаях — бред сивой кобылы.


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

IT>Я не предлагал это.

IT>Не надо вешать свою булевскую логику на все случаи жизни.

Предлагаешь вообще логикой не пользоваться а верить тебе на слово ?

IT>Если снова не смог прочесть мои слова, то переведу проще — "комментарии нужны, чистый код никогда их не заменит полностью". Твои фантазии меня не интересуют, выше можешь прочесть, что я действительно сказал, а не ты выдумал.


Наоборот. Сначала — чистый код. А вот в некоторых частных случаях — комментарии. И нужно отделять документацию от комментариев

I>>Ну так дай правильное имя. Глядишь, каменты и не понадобятся.


IT>Комментарии понадобятся, ибо читать, что делает внешняя в рамках данной работы функция необязательно и затратно.


Перечитай своё "Еще прелестнее", про filter и прочее.

IT>Я приводил выше пример — не должен программист бэкенда лазить во фронтенде. У них разные специализации и это потеря времени. Точно также какой-нибудь математик-алгоритмист не должен лазить в бэкенде. Это глупо и нерациональное расходование средств.


Правильно ! И мне для работы с бакендом нужны только правильный АПИ. А тебе нжны, внимание, каменты. Где находятся каменты ? Правильно — вмест с кодом. Итого — именно у тебя и нужно лезть в код бекенда за комментариями, ибо из апи и тестов нихрена не ясно.
Re[6]: Переписывание старого дерьмокода
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.01.16 16:13
Оценка:
Здравствуйте, Privalov, Вы писали:

P>Здравствуйте, Ikemefula, Вы писали:


I>>Например indexOf это хорошее имя, а вот что именно делает функция, что бы найти индекс, совершенно не актуально.


P>Сдается мне, indexOf точно отражает, что именно делает функция.


indexOf отражает ожидания пользователя, сам результат.

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


Здесь самое интересное — посмотри, на основании чего ты переименовываешь функции.
Re[2]: Переписывание старого дерьмокода
От: Kernan Ниоткуда https://rsdn.ru/forum/flame.politics/
Дата: 25.01.16 11:36
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Khimik, Вы писали:

K>>Как вы для себя решаете эти проблемы?
S>Ничего нельзя переписывать. Вам кажется, что вы "избежите старых ошибок".
Если я правильно помню, Эвернот был переписан нс С++ с чего-то другого и выиграл от этого. Местный проектородел дрВано тоже переписывал свой протектор нс С++.
Sic luceat lux!
Отредактировано 25.01.2016 11:37 Kernan . Предыдущая версия .
Re: Переписывание старого дерьмокода
От: ELazin http://rsdn.ru/forum/prj/6225353.1
Автор: ELazin
Дата: 26.10.15
Дата: 25.01.16 12:10
Оценка:
K>Как вы для себя решаете эти проблемы?
С помощью рефакторинга. Как тут уже писали, нужно постепенно покрывать код тестами и рефакторить. Правда забыли добавить что легаси код часто бывает невозможно покрыть тестами,так как он плохо написан. Тут уже возникает проблема, которая сродни квантовой физике, измерение изменяет состояние. Чтобы написать тест, нужно сначала немного порефакторить и переписать. Тут могут помочь всевозможные функциональные тесты, но даже с ними — процесс весьма непростой. Есть неплохая книжка на эту тему — http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
Re[3]: Переписывание старого дерьмокода
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 25.01.16 12:17
Оценка:
Здравствуйте, Kernan, Вы писали:

K>>>Как вы для себя решаете эти проблемы?

S>>Ничего нельзя переписывать. Вам кажется, что вы "избежите старых ошибок".
K>Если я правильно помню, Эвернот был переписан нс С++ с чего-то другого и выиграл от этого. Местный проектородел дрВано тоже переписывал свой протектор нс С++.

http://rsdn.ru/forum/humour/1600906.flat
Автор: Sinclair
Дата: 19.01.06
Re[7]: Переписывание старого дерьмокода
От: Privalov  
Дата: 25.01.16 13:24
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здесь самое интересное — посмотри, на основании чего ты переименовываешь функции.


Ты имеешь в виду, что функции получают названия типа BubbleSort или IntegralAdams? Я такие названия встречал, в основном, у математиков. Но тут это имеет смысл: математику так читать легче.
Re[8]: Переписывание старого дерьмокода
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 25.01.16 16:45
Оценка:
Здравствуйте, Privalov, Вы писали:

I>>Здесь самое интересное — посмотри, на основании чего ты переименовываешь функции.


P>Ты имеешь в виду, что функции получают названия типа BubbleSort или IntegralAdams? Я такие названия встречал, в основном, у математиков. Но тут это имеет смысл: математику так читать легче.


Маленькие детали очень сильно меняют картину. Рефакторингом как раз меняется структура приложения. readFile со временем перестаёт быть таковым и превращается скажем в TextReader.from(Stream.fromFile()).pipeTo(eventConsumer())
Итого — была одна функция, а стало много самых разных объектов с принципиально иной вычислительной моделью.

Инверсия управления творит чудеса — пару кликов мышом в решарпере том же и, внезапно, кучка концептуальных методов превращаются в один базовый + вызовы с параметрами-лямбдами по месту вызова.
Отредактировано 25.01.2016 16:49 Pauel . Предыдущая версия .
Re[2]: Переписывание старого дерьмокода
От: MTD https://github.com/mtrempoltsev
Дата: 28.01.16 08:17
Оценка: +2
Здравствуйте, Sinclair, Вы писали:

S>Ничего нельзя переписывать. Вам кажется, что вы "избежите старых ошибок". На самом деле вы всего лишь внесёте новые.


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

S>Греть вас будет только одно: мало кто из разработчиков не падал в эту яму. Из самого недавнего — посмотрите на Microsoft с их Edge.


Есть множество обратных примеров.
Re[3]: Переписывание старого дерьмокода
От: Terix  
Дата: 28.01.16 09:43
Оценка:
Здравствуйте, MTD, Вы писали:

MTD>Здравствуйте, Sinclair, Вы писали:


S>>Ничего нельзя переписывать. Вам кажется, что вы "избежите старых ошибок". На самом деле вы всего лишь внесёте новые.


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


S>>Греть вас будет только одно: мало кто из разработчиков не падал в эту яму. Из самого недавнего — посмотрите на Microsoft с их Edge.


MTD>Есть множество обратных примеров.


Я плохо представляю код, который никто не может починить, зато хорошо представляю менеджмент, котоый категорически не хочет выделять на это время. Зачастую "починить" означает переписать наново значительный блок кода, а не всю систему. Так делать можно и нужно. Переписывать всю систему, единственным полным описанием которой является её исходный код — опасно и трудозатратно. Оно того не стоит.

Кстати, что это за примеры удачного переписывания кода с нуля?
Re[4]: Переписывание старого дерьмокода
От: MTD https://github.com/mtrempoltsev
Дата: 28.01.16 19:46
Оценка:
Здравствуйте, Terix, Вы писали:

T>Я плохо представляю код, который никто не может починить


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

T>Переписывать всю систему, единственным полным описанием которой является её исходный код — опасно и трудозатратно.


Это типичная ошибка программиста — ставить код во главу угла, отталкиваться надо от бизнес требований.

T>Кстати, что это за примеры удачного переписывания кода с нуля?


Масса таких, например, MacOS 9 -> MacOS X
Re[3]: Переписывание старого дерьмокода
От: Sinclair Россия https://github.com/evilguest/
Дата: 29.01.16 07:01
Оценка:
Здравствуйте, MTD, Вы писали:

MTD>Отчего-то евангелисты "нельзя переписывать" отталкиваются от придуманной ими же аксиомы "старый код работает". Ну да, в какой-то мере он работает, но как-то лично мне сложно принять, например, что код который никто не может починить и который регулярно портит данные в базе из-за чего есть целый отдел который данные в базе правит руками, переписывать нельзя.


MTD>Я считаю, что нельзя давать переписывать человеку незнакомому с проектом, а к мнению человека который на проекте несколько лет, хорошо знает архитектуру и все подводные камни, прислушиваться надо. И если он утверждает, что переписать надо, то рассмотреть вопрос надо серьезно.

Вот этот момент непонятен: что именно мешает починить старый код? Ну, кроме нежелания вчитываться в кашу и желания попробовать новые паттерны, которые разработчик выучил с момента написания этого кода?

MTD>Есть множество обратных примеров.

Да, и я даже участвовал в одном таком примере. Тем не менее, общее правило — такое, как я писал.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Переписывание старого дерьмокода
От: vdimas Россия  
Дата: 29.01.16 07:45
Оценка: +1
Здравствуйте, ELazin, Вы писали:

K>>Как вы для себя решаете эти проблемы?

EL>С помощью рефакторинга.

+1
Только инкрементально.

EL>Как тут уже писали, нужно постепенно покрывать код тестами и рефакторить. Правда забыли добавить что легаси код часто бывает невозможно покрыть тестами,так как он плохо написан.


Вот как раз в сторону тестопригодности его и надо эволюционировать. Где-то декомпозировать, где-то добавить диагностики или вынести кишки наружу.
Re[4]: Переписывание старого дерьмокода
От: MTD https://github.com/mtrempoltsev
Дата: 29.01.16 08:33
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Вот этот момент непонятен: что именно мешает починить старый код? Ну, кроме нежелания вчитываться в кашу и желания попробовать новые паттерны, которые разработчик выучил с момента написания этого кода?


Ни у кого не хватает способностей — логика размазана по огромному количеству классов, масса неявных взаимодействий, казалось бы правильные изменения что-то ломают в самом неожиданном месте.
Re[2]: Переписывание старого дерьмокода
От: Stanislav V. Zudin Россия  
Дата: 29.01.16 09:19
Оценка: 2 (1) +1
Здравствуйте, vsb, Вы писали:

vsb>Комментарии лучше не писать. Это первейший признак плохого кода. Бывают исключения, но редко. Хочешь написать комментарий — вынеси код в функцию с названим, отражающим то, что ты хотел написать в комментарии.


С этим категорически не согласен.
Да, есть очевидный код, не нуждающийся в пояснениях. Но тогда комментарии пишутся на функцию — что делает, какие параметры ожидает. Doxygen-style вполне подходит.

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

У нас новый код начинается примерно так:
  Слайды


Потом между комментариями набивается код. Если по ходу пьесы логика меняется, то и комментарии меняются.
Не уверен, что существует достаточно умный авторефакторинг, способный поменять алгоритм.
_____________________
С уважением,
Stanislav V. Zudin
Re[3]: Переписывание старого дерьмокода
От: · Великобритания  
Дата: 30.01.16 00:07
Оценка:
Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ> У нас новый код начинается примерно так:

SVZ> Потом между комментариями набивается код
Осталось сделать главный шаг — выкинуть комметарии и начать использовать юнит-тесты.
avalon/1.0.432
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[4]: Переписывание старого дерьмокода
От: Stanislav V. Zudin Россия  
Дата: 30.01.16 06:59
Оценка:
Здравствуйте, ·, Вы писали:

SVZ>> У нас новый код начинается примерно так:

SVZ>> Потом между комментариями набивается код

·>Осталось сделать главный шаг — выкинуть комметарии и начать использовать юнит-тесты.


Ну тогда расскажи, как именно тут помогут юнит-тесты. Сделают код читабельнее?
Что именно ты собираешься окучивать тестами? Каждую строчку алгоритма? Весь алгоритм целиком?
_____________________
С уважением,
Stanislav V. Zudin
Re[5]: Переписывание старого дерьмокода
От: · Великобритания  
Дата: 30.01.16 10:52
Оценка:
Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>>> У нас новый код начинается примерно так:

SVZ>>> Потом между комментариями набивается код

SVZ>·>Осталось сделать главный шаг — выкинуть комметарии и начать использовать юнит-тесты.


SVZ>Ну тогда расскажи, как именно тут помогут юнит-тесты. Сделают код читабельнее?

Читабельность ортогональна.
Тесты дадут более простой в использовании и поддержке код.

SVZ>Что именно ты собираешься окучивать тестами? Каждую строчку алгоритма? Весь алгоритм целиком?

Собственно каждый параграф комментов из картинки выше становится юнит-тестом, по сути исполняемым комментом.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: Переписывание старого дерьмокода
От: Sinclair Россия https://github.com/evilguest/
Дата: 31.01.16 17:20
Оценка:
Здравствуйте, MTD, Вы писали:

MTD>Ни у кого не хватает способностей — логика размазана по огромному количеству классов, масса неявных взаимодействий, казалось бы правильные изменения что-то ломают в самом неожиданном месте.

Вот в таком случае я уверен в своём совете на 100%. Потому, что идея "да что тут чинить — давайте перепишем всё нахрен!" продиктована непониманием.
Это — гарантия провала, т.к. ставится задача "воспроизвести неизвестно что".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Переписывание старого дерьмокода
От: MTD https://github.com/mtrempoltsev
Дата: 31.01.16 20:10
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Это — гарантия провала, т.к. ставится задача "воспроизвести неизвестно что".


Типичная ошибка программиста — код во главе угла, в то время как отталкиваться надо от бизнес требований, с пониманием которых все нормально.
Re[5]: Переписывание старого дерьмокода
От: Terix  
Дата: 01.02.16 07:49
Оценка:
Здравствуйте, MTD, Вы писали:

T>>Переписывать всю систему, единственным полным описанием которой является её исходный код — опасно и трудозатратно.


MTD>Это типичная ошибка программиста — ставить код во главу угла, отталкиваться надо от бизнес требований.


Я не ставлю код во главу угла, я хочу сказать, что бизнес хочет фич завтра и фиксов багов послезавтра, а не безбажной системы послезавтра. Ещё я хочу сказать, что переписать код по существующей спецификации действительно не так уж и трудно. Но спецификация зачастую есть только в коллективном бессознательном коллектива разрабочиков, тестеров и пользователей.

T>>Кстати, что это за примеры удачного переписывания кода с нуля?


MTD>Масса таких, например, MacOS 9 -> MacOS X


Да, совсем забыл я про этот случай. Слава Стиву Джобсу!
Re[6]: Переписывание старого дерьмокода
От: MTD https://github.com/mtrempoltsev
Дата: 01.02.16 08:19
Оценка:
Здравствуйте, Terix, Вы писали:

T>я хочу сказать, что бизнес хочет фич завтра и фиксов багов послезавтра


Это же классика:
1. Бодрые ребята пишут продукт по принципу "фигак, фигак и в продакшн", бизнес счастлив — новые фичи каждый день.
2. Ребята притомившись и начиная подозревать, что что-то идет не так сваливают.
3. Приходят новые, пытются что-то пилить с переменным успехом, задалбываются и уходят, бизнес груснеет — фичи все реже.
4. Несколько раз повторяется итерация 3, с каждым разом багов все больше, фиксятся они все реже, фичи вообще почти не добавляются. Бизнес в отчаянье.
5. Попадается ловкач, уговаривающий все переписать — переход к пункту 1.

T>Но спецификация зачастую есть только в коллективном бессознательном коллектива разрабочиков, тестеров и пользователей.


Ага, бардака я тоже много видел.
Re[3]: Переписывание старого дерьмокода
От: ELazin http://rsdn.ru/forum/prj/6225353.1
Автор: ELazin
Дата: 26.10.15
Дата: 01.02.16 14:30
Оценка:
V>+1
V>Только инкрементально.
А разве я что-то другое советовал делать?

V>Вот как раз в сторону тестопригодности его и надо эволюционировать. Где-то декомпозировать, где-то добавить диагностики или вынести кишки наружу.

ditto
Re[6]: Переписывание старого дерьмокода
От: Stanislav V. Zudin Россия  
Дата: 01.02.16 15:42
Оценка:
Здравствуйте, ·, Вы писали:

SVZ>>·>Осталось сделать главный шаг — выкинуть комметарии и начать использовать юнит-тесты.


SVZ>>Ну тогда расскажи, как именно тут помогут юнит-тесты. Сделают код читабельнее?

·>Читабельность ортогональна.

А так всё хорошо начиналось... Комменты не нужны и всё такое Как раз обсуждение для КСВ

·>Тесты дадут более простой в использовании и поддержке код.


SVZ>>Что именно ты собираешься окучивать тестами? Каждую строчку алгоритма? Весь алгоритм целиком?

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

Тесты все равно оформляются отдельно от кода. Поэтому как они могут стать "исполняемым комментом"


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

У нас основная ошибка, с которой сталкиваемся — правильность алгоритма в целом, а не отдельных его частей.
Т.е. все части по отдельности работают, алгоритм тоже работает, но выполняет не то, либо то, но не всегда.

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

А отдельные части получается эффективнее обвешивать ассертами и проверять валидность входных данных и корректность внутреннего состояния.
И именно ассерты получаются теми самыми "исполняемыми комментами".
_____________________
С уважением,
Stanislav V. Zudin
Re[7]: Переписывание старого дерьмокода
От: · Великобритания  
Дата: 01.02.16 22:46
Оценка:
Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ> SVZ>>Ну тогда расскажи, как именно тут помогут юнит-тесты. Сделают код читабельнее?

SVZ> ·>Читабельность ортогональна.
SVZ> А так всё хорошо начиналось... Комменты не нужны и всё такое Как раз обсуждение для КСВ
Просто тут как получается. Если тестов нет, то код менять страшно. Поэтому как написали — сработало — ура, коммит! И не до читабельности. Когда есть тесты — то после написания кода "чтоб работало", можно спокойно начать править код на "чтоб читабельно".

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

SVZ> Тесты все равно оформляются отдельно от кода. Поэтому как они могут стать "исполняемым комментом"
То что тесты это тоже код, который можно исполнить и посмотреть результат исполнения.

SVZ> У меня к юнит-тестам неоднозначное отношение. Вроде бы вещь полезная, однако затраты времени на их написание многократно превосходят написание собственно кода.

Это с непривычки. Потом, когда привыкнешь, время написания кода+тесты скорее всего станет меньше, чем просто кода. Ибо как работает код ты можешь видеть практически мгновенно, просто запустив тест, вместо того, чтобы полностью компилировать+деплоить+запускать проект и потом накликивать до тестируемого места.

SVZ> В приведенном примере код тривиальный. Собственных юнит-тестов заслуживает, разве что, построение графа.

Для тривиального кода как правило получаются тривиальные тесты.

SVZ> У нас основная ошибка, с которой сталкиваемся — правильность алгоритма в целом, а не отдельных его частей.

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

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

Ошибочные данные и то что они правильно валидируются — тоже тестируются. Или я не понял о какого рода ошибках ты говоришь.

SVZ> А отдельные части получается эффективнее обвешивать ассертами и проверять валидность входных данных и корректность внутреннего состояния.

SVZ> И именно ассерты получаются теми самыми "исполняемыми комментами".
Ассерты несколько другой инструмент, с другими целями. Они не заменяют юнит-тесты, а могут дополнять.
avalon/1.0.432
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[4]: Переписывание старого дерьмокода
От: BulatZiganshin  
Дата: 01.03.16 23:42
Оценка: 42 (4)
Здравствуйте, vsb, Вы писали:

vsb>>>Комментарии лучше не писать. Это первейший признак плохого кода. Бывают исключения, но редко. Хочешь написать комментарий — вынеси код в функцию с названим, отражающим то, что ты хотел написать в комментарии.


vsb>Потерей времени будет полагаться на комментарий, в котором написано одно, а в коде другое.


а название функции значит отражает её смысл автоматически?

вот пример из моего кода. если убрать в нём комменты — то разбираться в нём будет на порядок дольше, а переносить каждые 2-3 тстрочки в отдельные фукции — вообще бредовый подход

  Скрытый текст
// Назначим пропавшим секторам данных их наиболее вероятные позиции в исходном файле
// (для того, чтобы скопировать в восстановленный файл эти, предположительно лишь частично повреждённые сектора,
//  в тех случаях, когда точное содержание сектора не может быть восстановлено с помощью ECC)
void Decoder::GuessPositionsOfLostSectors()
{
    // Проверка, что расстояние между секторами first и last осталось таким же, как в исходном файле
    // (что позволяет надеяться, что сектора между ними и вокруг них смещены аналогично)
    auto matching = [&] (size_t first, size_t last) {
        return  data_sector_pos[last] - data_sector_pos[first]  ==  G.data_sector_pos(last) - G.data_sector_pos(first);
    };

    size_t size = data_sector_pos.size(), first = 0, last = 0;
    size_t first_first = size, latest_last = size-1;  // эти значения будут задействованы, если нет ни одного сектора с известной позицией
    if (size==0)  return;
    ui.Progress (ui.DECODER_GUESSING, 0, size, sizeof(data_sector_pos[0]));

    // Найдём первый сектор, позиция которого в файле известна
    while (data_sector_pos[first] == SECTOR_NOT_FOUND)
        if (++first >= size)
            goto done;
    first_first = first;

    // Цикл по всем сегментам массива, ограниченным с обоих сторон секторами с известной позицией
    for(;;)
    {
        // Конец предыдущего сегмента становится началом следующего
        latest_last = last = first;

        // Найдём следующий сектор, позиция которого в файле известна
        do {
            if (++last >= size)
                goto done;
        } while (data_sector_pos[last] == SECTOR_NOT_FOUND);

        // Оптимизация - пропустим вычисление pos, если между first и last всё равно нет других секторов
        if (last==first+1)  {first++; continue;}

        // Если между first и last то же расстояние, что и в исходном файле, то позиции промежуточных секторов расставляются между ними,
        // иначе - исходя из предположения, что данные остались на исходном месте (умнее всё равно ничего не придумаешь)
        auto pos  =  matching(first,last)? data_sector_pos[first] : G.data_sector_pos(first);
        while (++first!=last)
            data_sector_pos[first] = (pos += SECTOR_SIZE);
    }

    // Теперь займёмся секторами до первого сектора с известной позицией и после последнего такого
    done: first = first_first, last = latest_last;

    // До первого first - если позиции трёх секторов first..first+2 консистентны, то мы берём их за базу
    auto pos  =  (first+2 < size  &&  matching(first,first+1)  &&  matching(first,first+2))? data_sector_pos[first] : G.data_sector_pos(first);
    while (first-- > 0)
        data_sector_pos[first]  =  (pos>=SECTOR_SIZE?  (pos -= SECTOR_SIZE)  :  G.data_sector_pos(first));

    // После последнего last - если позиции трёх секторов last-2..last консистентны, то мы берём их за базу
    pos  =  (last >= 2  &&  matching(last-1,last)  &&  matching(last-2,last))? data_sector_pos[last] : G.data_sector_pos(last);
    while (++last < size)
        data_sector_pos[last] = (pos += SECTOR_SIZE);
}
Люди, я люблю вас! Будьте бдительны!!!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.