Здравствуйте, Kernan, Вы писали:
K>>>Как вы для себя решаете эти проблемы? S>>Ничего нельзя переписывать. Вам кажется, что вы "избежите старых ошибок". K>Если я правильно помню, Эвернот был переписан нс С++ с чего-то другого и выиграл от этого. Местный проектородел дрВано тоже переписывал свой протектор нс С++.
Здравствуйте, 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>Кстати, что это за примеры удачного переписывания кода с нуля?
Здравствуйте, MTD, Вы писали:
MTD>Отчего-то евангелисты "нельзя переписывать" отталкиваются от придуманной ими же аксиомы "старый код работает". Ну да, в какой-то мере он работает, но как-то лично мне сложно принять, например, что код который никто не может починить и который регулярно портит данные в базе из-за чего есть целый отдел который данные в базе правит руками, переписывать нельзя.
MTD>Я считаю, что нельзя давать переписывать человеку незнакомому с проектом, а к мнению человека который на проекте несколько лет, хорошо знает архитектуру и все подводные камни, прислушиваться надо. И если он утверждает, что переписать надо, то рассмотреть вопрос надо серьезно.
Вот этот момент непонятен: что именно мешает починить старый код? Ну, кроме нежелания вчитываться в кашу и желания попробовать новые паттерны, которые разработчик выучил с момента написания этого кода?
MTD>Есть множество обратных примеров.
Да, и я даже участвовал в одном таком примере. Тем не менее, общее правило — такое, как я писал.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, ELazin, Вы писали:
K>>Как вы для себя решаете эти проблемы? EL>С помощью рефакторинга.
+1
Только инкрементально.
EL>Как тут уже писали, нужно постепенно покрывать код тестами и рефакторить. Правда забыли добавить что легаси код часто бывает невозможно покрыть тестами,так как он плохо написан.
Вот как раз в сторону тестопригодности его и надо эволюционировать. Где-то декомпозировать, где-то добавить диагностики или вынести кишки наружу.
Здравствуйте, Sinclair, Вы писали:
S>Вот этот момент непонятен: что именно мешает починить старый код? Ну, кроме нежелания вчитываться в кашу и желания попробовать новые паттерны, которые разработчик выучил с момента написания этого кода?
Ни у кого не хватает способностей — логика размазана по огромному количеству классов, масса неявных взаимодействий, казалось бы правильные изменения что-то ломают в самом неожиданном месте.
Здравствуйте, vsb, Вы писали: vsb>Комментарии лучше не писать. Это первейший признак плохого кода. Бывают исключения, но редко. Хочешь написать комментарий — вынеси код в функцию с названим, отражающим то, что ты хотел написать в комментарии.
С этим категорически не согласен.
Да, есть очевидный код, не нуждающийся в пояснениях. Но тогда комментарии пишутся на функцию — что делает, какие параметры ожидает. Doxygen-style вполне подходит.
Комментарии необходимы. Прежде всего потому, что комментарии описывают то, что разработчик намеревался сделать, а код — то, что разработчик наделал.
При последующем разборе говнокода несоответствие кода комментариям помогает обнаружить ошибку.
У нас новый код начинается примерно так:
Слайды
Потом между комментариями набивается код. Если по ходу пьесы логика меняется, то и комментарии меняются.
Не уверен, что существует достаточно умный авторефакторинг, способный поменять алгоритм.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ> У нас новый код начинается примерно так: SVZ> Потом между комментариями набивается код
Осталось сделать главный шаг — выкинуть комметарии и начать использовать юнит-тесты.
Здравствуйте, ·, Вы писали:
SVZ>> У нас новый код начинается примерно так: SVZ>> Потом между комментариями набивается код
·>Осталось сделать главный шаг — выкинуть комметарии и начать использовать юнит-тесты.
Ну тогда расскажи, как именно тут помогут юнит-тесты. Сделают код читабельнее?
Что именно ты собираешься окучивать тестами? Каждую строчку алгоритма? Весь алгоритм целиком?
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>>> У нас новый код начинается примерно так: SVZ>>> Потом между комментариями набивается код
SVZ>·>Осталось сделать главный шаг — выкинуть комметарии и начать использовать юнит-тесты.
SVZ>Ну тогда расскажи, как именно тут помогут юнит-тесты. Сделают код читабельнее?
Читабельность ортогональна.
Тесты дадут более простой в использовании и поддержке код.
SVZ>Что именно ты собираешься окучивать тестами? Каждую строчку алгоритма? Весь алгоритм целиком?
Собственно каждый параграф комментов из картинки выше становится юнит-тестом, по сути исполняемым комментом.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, MTD, Вы писали:
MTD>Ни у кого не хватает способностей — логика размазана по огромному количеству классов, масса неявных взаимодействий, казалось бы правильные изменения что-то ломают в самом неожиданном месте.
Вот в таком случае я уверен в своём совете на 100%. Потому, что идея "да что тут чинить — давайте перепишем всё нахрен!" продиктована непониманием.
Это — гарантия провала, т.к. ставится задача "воспроизвести неизвестно что".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ> SVZ>>Ну тогда расскажи, как именно тут помогут юнит-тесты. Сделают код читабельнее? SVZ> ·>Читабельность ортогональна. SVZ> А так всё хорошо начиналось... Комменты не нужны и всё такое Как раз обсуждение для КСВ
Просто тут как получается. Если тестов нет, то код менять страшно. Поэтому как написали — сработало — ура, коммит! И не до читабельности. Когда есть тесты — то после написания кода "чтоб работало", можно спокойно начать править код на "чтоб читабельно".
SVZ> ·>Собственно каждый параграф комментов из картинки выше становится юнит-тестом, по сути исполняемым комментом. SVZ> Тесты все равно оформляются отдельно от кода. Поэтому как они могут стать "исполняемым комментом"
То что тесты это тоже код, который можно исполнить и посмотреть результат исполнения.
SVZ> У меня к юнит-тестам неоднозначное отношение. Вроде бы вещь полезная, однако затраты времени на их написание многократно превосходят написание собственно кода.
Это с непривычки. Потом, когда привыкнешь, время написания кода+тесты скорее всего станет меньше, чем просто кода. Ибо как работает код ты можешь видеть практически мгновенно, просто запустив тест, вместо того, чтобы полностью компилировать+деплоить+запускать проект и потом накликивать до тестируемого места.
SVZ> В приведенном примере код тривиальный. Собственных юнит-тестов заслуживает, разве что, построение графа.
Для тривиального кода как правило получаются тривиальные тесты.
SVZ> У нас основная ошибка, с которой сталкиваемся — правильность алгоритма в целом, а не отдельных его частей. SVZ> Т.е. все части по отдельности работают, алгоритм тоже работает, но выполняет не то, либо то, но не всегда.
Собирать правильный алгоритм из правильных частей проще. А вообще для этого есть интеграционные, функциональные, системные тесты.
SVZ> Т.к. данные приходят с ошибками, то и предусмотреть, что нагородил очередной нетрезвый конструктор не представляется возможным.
Ошибочные данные и то что они правильно валидируются — тоже тестируются. Или я не понял о какого рода ошибках ты говоришь.
SVZ> А отдельные части получается эффективнее обвешивать ассертами и проверять валидность входных данных и корректность внутреннего состояния. SVZ> И именно ассерты получаются теми самыми "исполняемыми комментами".
Ассерты несколько другой инструмент, с другими целями. Они не заменяют юнит-тесты, а могут дополнять.