Мне достаточно долго уже нравилось «причесывание» кода, когда берешь полное говно и постепенно приводишь его в разумное состояние.
Недавно, сам того не заметив, поставил личный рекорд. Проект с 15Mb фиговых (плохо написанных и плохо документированных) исходников ужался до 1Mb более менее нормальных исходников, без потери функциональности. Собственно рекорд в срезании 94% кода 🙂
Оговорюсь правда, что заняло эта радость у меня достаточно долго.
С удовольствием послушаю о ваших рекордах (на любую тему) 🙂
Цифра конечно впечатляет, но интересны подробности, как ты определил, что без потери функциональности. Сам полную регрессию проводил? Автоматизированное тестирование? Как ты процент покрытия тест кейсов и юнит тестов считал? Ну и тд. Тема очень животрепещущая, так что интерес отнюдь не праздный
Начну с конца.
Более точно будет сказать не «без потери функциональности», а «без потери известной и используемой функциональности».
Теперь более детально.
— Продукт был куплен некоторое время назад, а потом прикручен большими ржавыми болтами к основному
— Полного списка фич оригинального продукта нет
— Функциональность которая нужна (та самая, которая прикручена ботами хорошо всем известна), хотя даже на нее нет списка фич.
— unitTest’ов нет
— автоматизированных тестов нет
— Растительности нет, планета населена роботами
Теперь о том, как я определил, что потери функционала нет
а) Сел с разработчиками составил список того, что оно должно делать
б) Сел с QA составил список того, что оно должно делать
в) Пошел в код и постепенно убил все то, что не было озвучено в пункте а) и б).
г) Процесс в) проходил некоторое время, так что по ходу я и QA это тестировали.
д) …
е) Profit
Естественно проделанная процедура не вписывается в рамки ни одного разумного процесса. С другой стороны, в описанной ситуации, как по мне это был единственный метод сделать из говна конфетку.
Я называю это рефакторинг и занимаюсь этим уже лет 7.
Но 15 мегабайт — это уж очень много.
В целом я тоже называю это рефакторинг. Но скорее рефакторинг я отношу к постепенной расчистке кода, чем к кардинальным изменениям.
Как-то педелывал обработку (отчет) в 1С-ке. В исходном варианте отчет формировался примерно 40 минут. После оптимизации — 40 секунд. плюс доп.функционал появился.
Прикольно 🙂
Круто
Ух, больная тема! Достался мне проект, предыдущие писатели которого потратили 400% от запланированного времени, в результате местами получилось такое… Из-за того, что оно как-то работало, убедить руководство в необходимости рефакторинга было сложно. Но после полугода работы над версией 2 (это собственно и было целью) вдвоем с коллегой старались подчищать где только можно, и все равно все еще порой натыкаюсь на ужасности вроде двух копий функциональности в разных местах, четырех функций с очень близкими именами или двух классов с полностью одинаковыми именами и при этом вообще никак не связанных…
Из старого вспоминается, как в самой первой версии проекта из-за чрезмерно ранней (и как оказалось вообще не нужной) оптимизации кусок кода был нечитаемым и несопровождаемым вообще никак. И он там просуществовал еще четыре версии! Потому что никому не хотелось туда влазить. Пока мне это не надоело и, сев однажды, дня за три полностью этот кусок переписал. К счастью, автоматические тесты тогда у нас уже были, иначе было бы стремно, поскольку кусок этот был сильно в середине всего…
И да, проделав это, действительно потом испытываешь удовольствие, как от генеральной уборки в доме, когда все блестит и сияет 🙂
В целом — это стандартная проблема по индустрии.
Хотя многие говорят, что это нормально. Мол, в начале пытались побыстрее, чтобы выйти на рынок раньше и захватить его, а потом можно и расчистить. Но, чаще всего качественное написание (без фанатизма) с самого начала позволяет выйти таки на рынок быстрее.
Да, удовольствие от этого действительно получаешь море. Когда, можно заглянуть в код, без тяжелого вздоха и фраз «какая же сволочь это наваяла».
Кстати, первые два проекта которые расчищал были мной же и написаны. Поэтому на вопрос о сволочи у меня был четкий ответ. Ну и плюс, после этого решил, что код таки надо держать чистым.
Мини-спринт рекорд:
За 8 часов 20 минут, переписал и отладил код который прежде два программиста не смогли довести до стабильного состояния за 4ре рабочих дня.
О… кстати, у меня было похожая ситуация. Там был баг, которые двое seniour’ов мурыжили пару дней. Я его пофиксил и протестил за пару часов.
Знакомое дело. Мне кажется тут наиболее интересным сам процесс адаптации мозга.
Поначалу приходится адаптироваться и думать почему именно так и как из этого сделать конфету постепенно что бы не убить всю логику. Обычно я действую очень дробными шагами — это как переступать по камням в сильном водном потоке по пояс.
Постепенно шаг за шагом и от уровня к уровню логика приходит в порядок — болты выкручиваются и дыры заростают. Настает чистота и справедливость. 🙂
ПС. Мне тоже это нравится, это развивает.
Та да, рубить с плеча тут нельзя. Собственно дольше всего у меня именно ушло просто на работу с проектом и пофиксов в старом коде багов. За это время я разбрался, что там нужно, а что нет (теми самыми мелкими шажками).
А потом уже начал выкручивать болты.
Боюсь, получи я 15 мб исходников, я бы их распечатал и сжёг, а потом написал всё с нуля. =)
Недавно в отпуске за 2 недели реализовал основную функциональность программы, которую предыдущий кодер писал полгода. Конечно, всяких мелочей у меня нет, зато написано не на (обожемой) delphi 7, а на c++ и работает шустрее
>Боюсь, получи я 15 мб исходников, я бы их распечатал и сжёг, а потом написал всё с нуля. =)
Ну, все таки… Не зная точно, что оно делает и имея постоянно релиз через месяц, тяжко такое сделать.
Хотя безусловно, желание такое присутствовало.
Портирование игры с j2me на brew — которое оценил вместе с заказчиком в 2 человека месяца фактической работы (3 календарных) и сооветствующие деньги — получилось сделать за 20 часов, в течении трех дней.
Причины — код исходной игры пришел удивительно чистый и хороший и на удивление хорошо сработало полуавтоматическое преобразование кода и классы врапперы (обертка вокруг BREW функций и процедур в одноименные j2me классы) из предыдушего проекта.
Правда реальная оценка была месяц, 2 это было с заранее доп. запасом. Но все равно, было приятно.
Хотя, были и проблемы — сдавать проект сразу было не комильфо, поэтому пришлось через полтора месяца, при сдаче проекта, судорожно вспоминать игру чтобы на некоторые вопросы ответить.
Такие рекорды вдвойне приятны 🙂 И профессиональная гордость и еще и под деньгам хорошо.