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

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

http://rsdn.ru/forum/humour/1600906.flat

Автор: Sinclair
Дата: 19.01.06

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MTD>Есть множество обратных примеров.
Да, и я даже участвовал в одном таком примере. Тем не менее, общее правило — такое, как я писал.

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

K>>Как вы для себя решаете эти проблемы?
EL>С помощью рефакторинга.

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

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

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

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

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

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

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

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

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

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

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

	Слайды

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

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

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

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

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

Ну тогда расскажи, как именно тут помогут юнит-тесты. Сделают код читабельнее?
Что именно ты собираешься окучивать тестами? Каждую строчку алгоритма? Весь алгоритм целиком?

Здравствуйте, Stanislav V. Zudin, Вы писали:

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

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

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

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

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

MTD>Ни у кого не хватает способностей — логика размазана по огромному количеству классов, масса неявных взаимодействий, казалось бы правильные изменения что-то ломают в самом неожиданном месте.
Вот в таком случае я уверен в своём совете на 100%. Потому, что идея "да что тут чинить — давайте перепишем всё нахрен!" продиктована непониманием.
Это — гарантия провала, т.к. ставится задача "воспроизвести неизвестно что".

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

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

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

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

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

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

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

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

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

Да, совсем забыл я про этот случай. Слава Стиву Джобсу!

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

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

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

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

Ага, бардака я тоже много видел.

V>+1
V>Только инкрементально.
А разве я что-то другое советовал делать?

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

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

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

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

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

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

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

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


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

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

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

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

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

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

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

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

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

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

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