Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Как добиться эффективности, работая с legacy-Г-кодом?

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

От них можно отказываться сразу, но их слишком много, они повсюду, и это в несколько раз уменьшает выбор вариантов работы. А ещё бывает так, что работа нужна и/или в какой-то компании прекрасные условия, хорошо платят, всё у них нравится, и плох(и) только проект(ы). Поэтому надо быть готовым к этому, на всякий случай.

Очевидно, что на «brute-force approach» сил и времени заведомо не хватит.
Есть какие-нибудь приёмы, методы, лайфхаки, что угодно, что реально помогает справляться с legacy-хаффнокодом и даже показывать какую-никакую «эффективность»?

Есть по этому делу книга, что-то вроде «working effectively with legacy code», — кто-нибудь читал, пробовал, как помогло?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Никак, лучше всего выбрасывать. Если экономически в рамках предприятия нецелесообразно выбрасывать, подготавливать платформу для скоростной замены.
Лучший код — не написанный.
Куда более лучший код — тот, который пишет не программист.
Самый лучший код — который пишет учёный инженерной специализации.

Всякий код, который написан не тобой — г-нокод


— Я уж и так читаю, читаю... — ответил Шариков и вдруг хищно и быстро налил себе полстакана водки.

— Эту... как ее... переписку Пoхуистов с этими... как его, дьявола... с Перфекционистами.

Борменталь остановил на полдороге вилку с куском белого мяса, а Филипп Филиппович расплескал вино. Шариков в это время изловчился и проглотил водку.

Филипп Филиппович локти положил на стол, вгляделся в Шарикова и спросил:

— Позвольте узнать, что вы можете сказать по поводу прочитанного?

Шариков пожал плечами.

— Да не согласен я.

— С кем? С Пoхуистами или с Перфекционистами?

— С обоими, — ответил Шариков.

— Это замечательно, клянусь Богом! «Всех, кто скажет, что другая!..» А что бы вы, со своей стороны, могли предложить?

— Да что тут предлагать... А то пишут, пишут... рефакторинг, тесты какие-то... голова пухнет!
Взять все да и переписать..

Как не странно, но основной навык при работе с легаси кодом, это умение _читать_ код. Для меня загадка, но этого умения чертовски не хватает многим программистам.

Прошу заметить, что автору этого поста на ЖЖ все-таки читали лекции по архитектуре системы и производили review наработанного. Если лекций читать некому, то должно быть описание. Иначе придется искать просветленных разработчиков. Я даже знаю страну где их особенно много :))) Или мириться с никакой производительностью на начальном этапе.
@NewType: делайте что можете и будь что будет. Если у Вас в руководстве нормальные люди, то они должны понимать ситуацию, по крайней мере после Ваших разъяснений. Так же можно и нужно прибегать к помощи коллег, особенно если чувствуете, что застряли. Если до руководства не доходит и выставляются какие-то трудновыполнимые требования к производительности, то пусть ищут просветленного.

На некоторых (веб)-проектах и на некоторых задачах хорошо себя показал подход примерно такой (для контроля бизнес-логики):
— делаем снэпшот базы
— логируем все реальные запросы с момента снэпшота какое-то время
— делаем второй снэпшот
— вносим изменения на тестовый
— накатываем первый снэпшот
— реплаим лог запросов
— сравниваем тестовую базу со вторым снэпшотом

Покупал я эту книжку, полистал и оставил на прошлой работе монитор подпирать. Вся суть — а давайте вы будете писать тесты, а потом менять код.

Ну, в принципе это нормальный вариант: написать integration test’ы (не пытаясь обзывать их unit-тестами), менять код, гонять тесты, продолжать...

Проблема написания тестов в том, что ожидаемое поведение неизвестно как правило.

Ожидаемое поведение должно быть известно. Если оно неизвестно, то тогда всё равно, как оно работает, как ведёт себя.

С легаси кодом нет никаких «должно». Из недавнего — отчёт, задание на который давал бывший топ и реализовывал бывший разработчик. Что за цифры показывает, какие крайние случаи ку учитывает, что за магические константы никто в фирме не знает. Растут цифры — хорошо, падают — плохо. Но вот нужно его оптимизировать и без поллитры не поймешь, что он показывает в бизнес-терминах.

Если не ясно, что должно происходить, то и требования неоткуда брать. А значит и фиксить по сути ничего не надо.

Требования могут быть нейфункциональные. Требования могут быть на изменение или расширение функциональности, то есть «вот это не трогать, а вот это изменить».

Если не ясно, что должно происходить, то и требования неоткуда брать.
Поэтому есть только одно главное требование: что бы все работало как раньше!
А значит и фиксить по сути ничего не надо.
И маленькое дополнение, например: если имя юзера начинается на В и сегодня Вторник то именно ему одному посчитать по другому и показать слева, а не справа.
И маленькое дополнение,
Впрочем — через неделю постановщик задачи, скорее всего, куда-то исчезнет и забудет о ней на месяц или навсегда.
Но сегодня ему это нужно на вчера и вообще «всех уволю!».
если имя юзера начинается на В и сегодня Вторник то именно ему одному посчитать по другому и показать слева, а не справа.

И ещё чтобы при этом не сломалась вся остальная вёрстка. :-)

working effectively with legacy code
книга конечно хорошая, но не всем с ходу поможет. Clean code и уже упоминавшийся рефакторинг фаулера может получше будут для начала.

ИМХО лучше всего систематически следовать правилу бойскаута — внеся изменение в код, проследи чтобы он стал чуть лучше. Со временем (в зависимости от объемности системы) это начнет приносить плоды, но только если вся команда согласованно следует этому направлению. Ибо скорость загаживания говн*кодером на свободе всегда много выше скорости вероятного разгребания. Ужесточение review policy может быть одним из решений.
Ну а поверх этого, как инструменты — стантартный набор:
* авто-тестирование. Желательно шире чем юнит — unit-tests в запущенных системах обычно тестируют ложные допущения и мокают не очень реальные события.
* рефакторинг. Так как продавать сначала будет сложно — можно вписывать в стандартные задачи (починил наскоро баг — попробуй найти и починить его глубинную причину. Заимплементил наскоро фичу — потрать пропорционально время полируя решение)
* продажа ЛПР (лицу принимающему решение) — «вот в прошлом месяце мы чуть дольше инвестировали в эту подсистему и теперь немногие дефекты чинятся намного быстрее чем раньше. А вот тут еще бардак, по-этому наш естимейт будет поболе»

Что не улучшит эффективность:
* громогласные заявления о ужасности кода/продукта/процесса/заказчика.
* требование полного переписания (части) системы или другой значительной инвестиции превышающей реально достигнутые успехи на данный момент.

Так книга Feather’а как раз и рассказывает, как довести код до такого состояния, чтобы его можно было уже поддерживать со всякими рефакторингами. А clean code это уже когда он действительно стал clean.
Так что они не противоречат, а аккуратно дополняют друг друга.

Ну как бы если не уметь писать хороший (clean это имеет ввиду) код, то рефакторинг не улучшит ситуацию. Дополнение — не спорю.

Смотря что вы вкладываете в понятие «эффективность».
Пофиксить 12 багов за 1 день или 1 мелкий баг за неделю?
Так вот, для вашей компании-бодишопа будет гораздо выгоднее 2-й вариант, чем ниже эффективность, тем лучше, для этого и берут на сапорт легаси системы.

Чтобы на фикс одного бага уходило от 1 до 5 рабочих дней, например. В крайнем случае до 10.
То есть чтобы эффективность была явно выше нуля.

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

Спокойно работать с legacy проектом можно только поработав на нём полгода-год. А чтобы выжить первые полгода на нём — надо как-то показывать результаты, а чтобы их показывать — в проекте надо разобраться, а для этого надо полгода покопаться.
Проблема курицы и яйца.

«Показывать эффективность» — я имел в виду закрывать баги в среднем за 2-3-5 дней, а не за 2-3-5 недель, например.

«Спроси у меня как» — я на таких проектах проработал больше 8 лет в общей сумме.
Практика показывает что почти любой проект возрастом более двух лет обычно превращается в «унылый» Г-код (в большей или меньшей степени). Потому что документацию писать никто не любит, оригинальные разработчики уходят, синьоров постепенно меняют на джунов, клиент начинает экономить на сапорте, технический долг только растет и т.д.
Главный вопрос при работе в таком проекте должен быть всегда только один: Зачем? В ситуации, когда что-то улучшить очень сложно, а испортить очень легко, стратегия в том, что бы получить желаемый результат (или максимально близкий к желаемому) с минимальными потерями.
Забудьте про рефакторинг и улучшения. Это имеет смысл только пока технический долг не превысил стоимость написания кода «с нуля». И пока не утрачено понимание, что код должен делать. Обычно для кода годичной давности эта точка уже пройдена. После этого код должен работать «как работает» и трогать его опасно. Все, что остается это либо ставить «костыли», либо рядом лепить новую версию того же куска (класса, метода), которая будет содержать +1 фичу и включаться вместо старой где надо.

документацию писать никто не любит

Потому что project manager недостаточно пинает разработчиков, чтобы писали документацию.

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

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

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

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

Обычно для кода годичной давности эта точка уже пройдена
Как-то очень быстро, на мой взгляд. Или там 300 «спартанцев» его год пишут?

можно и быстрее. Главное «мастерство» и немного прессинга со сроками.

Чушь. Работаю больше 10 лет на таких проектах. Больших и маленьких. Только начавшихся и с длинной историей. Вырефакториваются — уметь надо. А кто не умеет — у тех г-легаси начинается через месяц активной разработки.

Вырефакториваются — уметь надо. А кто не умеет — у тех г-легаси начинается через месяц активной разработки.
Вопрос только в стоимости рефакторинга. А в нее входит не только само изменение кода, но и разбирательство как код должен работать (если это где-то написано), как он работает по-факту сейчас и, самое главное, время на поиск и исправление всех возможных последствий рефакторинга.
Пока эта стоимость ниже, чем написать новые требования, утвердить у заказчика и заимплементить и протестировать по-новому не глядя в старый код, то код еще не гнилой и можно вырефакториваться.
В противном случае только подход «работает — не трогай», нужно поменять — напиши код рядом (скопипасти и поменяй если иначе никак).
«работает — не трогай»,
 — вот так они и размножаются делением. Потому как те, кто не умеют
разбирательство как код должен работать
новый лучше не сделают. А после
новые требования, утвердить у заказчика
вдруг выяснится что многие непонятности в старом коде на самом были нужны, просто заказчик все детали на стол сразу по памяти не выложит.

Всякое бывает, но в целом вырефакторивать как правило дешевле, быстрее и намного менее рисковано. Если скилзы есть, конечно.

Причем такое на 95% существующих систем. Где ИТ работает на бизнес. Если нет порядка в самом бизнесе — системы будут в любом случае отражать этот беспорядок. А наведение порядка в бизнесе — совсем другая история

Фаулер. Рефакторинг. Улучшение существующего кода
?

Физерс. Эффективная работа с унаследованным кодом. = Feathers. Working effectively with legacy code

Підписатись на коментарі