Lava flow

Добрый день

Давеча упоминались антипаттерны, мне очень нравится эта ссылка

Lava flow На википедии антипаттерн «Lava flow» находится в разделе «Programming anti-patterns», но я считаю, что ему все же место в разделе «Management anti-patterns». По крайней мере как это бывает в России. Предположим что у вас есть какая-то подсистема. Эта подсистема досталась вам в наследство от прошлого владельца. Она вроде как работает, но при этом имеет совершенно уродливую реализацию, затрудняющую ее дальнейшее сопровождение и развитие, и является самым настоящим музеем антипаттернов. Для того чтобы привести эту систему в порядок (что чаще всего означает «переписать заново»), придется потратить немало сил и времени. Многие руководители боятся пойти на такой рискованный шаг, продолжая двигаться по пути наименьшего сопротивления. Мол, «работает, и ладно». Подобный отказ от приведения системы в порядок и является антипаттерном «Lava flow». Я особенно трепетно отношусь к этому антипаттерну. Когда я сталкиваюсь с ним в реальной жизни, я всегда жалею о том, что не родился штандартенфюрером «СС» или древнекитайским пыточником. «Lava flow» особенно часто встречается в коде, у которого сменилось не одно поколение хозяев. Предлагаю вашему вниманию мини-пьесу, написанную лично мной, которая так и называется: «Lava flow»: Генеральный (в отдел кадров). Уволить этих бездарей! Найдите мне нормальных специалистов! …спустя три недели новые специалисты сидят на рабочих местах и изучают проект. Junior developer (про себя). Как тут все сложно… Жизни не хватит чтобы понять как все это работает… Меня наверно уволят… Senior developer (громко и недовольно). Кто учил этих мудаков программировать?!! Нет, ну вы посмотрите что они тут пишут! Главный архитектор (задумчиво). Если бы это была лошадь, я бы посоветовал ее пристрелить… Team leader (нервно). Спокойно, мужики. Заказчик хочет чтобы мы просто кое-что тут дописали. Оставим все как есть, просто доделаем то, что требуется. Project manager (обращаясь к разработчикам). Проект конечно тяжелый, но мы ведь справимся! Тем более мы будем вести разработку по самой лучшей методологии! Нам поможет XP! Scrum! TDD! (нужное подчеркнуть). Главный архитектор (поймав project manager-а в курилке). Ты ведь понимаешь, что проект уже бьется в предсмертных конвульсиях. Его нужно полностью переписать. Project manager (Главному архитектору). Да все я понимаю, только кто мне это позволит? Знаешь сколько уже потрачено бабла на этот проект? Попробуй объяснить генеральному, что нужно все переделать, я посмотрю насколько быстро ты отыщешь живописное местечко под названием «нах#й». Project manager (Оставшись один в курилке, глядя в окно). Вот начнем мы писать проект заново. И облажаемся. Я же во всем виноват буду, с меня же шкуру спустят. Ну его нафиг. А так, если сроки и завалим, то я всегда смогу свалить все на то, что проект уже был полным говном, когда достался нам. …спустя полгода. Генеральный (в отдел кадров). Уволить этих бездарей! Найдите мне нормальных специалистов!

Написано замечательно, но согласны ли Вы с "главным архитектором" ?

0

Вы просто валите все в одну кучу. Тесты ни чего не решают, они помогают. И не более.
Условно один из вариантов, который я обкатываю на своем проекте:

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

Сообщение от Igor3D Это очень "растяжимое" понимание. "В общих чертах" функционал можно понять за вполне обозримое время.

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

Ведь чем сложнее программа тем больше "темных" уголков (фич) которыми лично вы не пользовались, а вот коллега в соседнем кабинете только ими и пользуется.

И тут ведь не обязательно речь о всей программе в целом: класс, отдельный метод, функция.... Т.е. вы берете сущность, определяете что она делает. При каких параметрах какие результаты она дает - записываете. Рефакторите. Проверяете работу при тех же самых входных параметрах. Если результаты другие - то у вас косяк. (если конечно, не было целью рефакторинга изменение поведения).

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

0

Сообщение от voral Вы просто валите все в одну кучу.

Так Вы же только тестах и говорите (понимаю, работа такая). Вот и "валю"

Сообщение от voral и вот в конкретном месте кода я понимаю, что что то не устраивает.

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

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

0

Сообщение от Igor3D Так Вы же только тестах и говорите (понимаю, работа такая). Вот и "валю"

Отчего же. Мы же про рефакторинг говорим. Не будет вопросов про тесты - значит и заглохнет это направление.

Сообщение от Igor3D Пишут свой (хороший/современный) код и как-то пристраивают его к старому ядру, у которого какая-то "модульность" все-таки есть. И долгое время это так-сяк проходит. Но все равно рано или поздно приходится принимать "непростые решения"

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

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


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

0