Items

Получился у меня с Not A Kernel Guy своебразный диалог, в рамках которого он, в течение одного комментария, дважды посоветовал изменить дизайн. Неважно по какому поводу и неважно дизайн чего. К данному разговору это не имеет никакого отношения. Но вот, что показалось мне достойным отдельного разговора, так это вопрос, как определить ту грань, когда старый код поддерживать становится гораздо труднее чем написать всё from scratch.

Рискну ошибиться, но ведь наверняка, это общая проблема для многих долгосрочных и не очень проектов.

Хорошо, когда можно обойтись малой кровью, то есть лёгким рефакторингом, или переписыванием пары классов, которые составляют суть проблемы. Но ведь это совсем не всегда возможно. Даже в моей скромной практике был случай, когда код работал нормально на однопроцессорной системе, а будучи запущенным даже на HyperThreading процессоре начинал приподносить сюрпризы, я уж не говорю про многопроцессорные системы, где его пытались запускать. Сразу отмажусь, код писал не я :-) Да, и собственно тот, кто его писал тоже не виноват, потому как дело было давно, когда и мысли не было, что однажды будет доступно нечто бОльшее, чем разделение времени одного единственного процессора. Было совершенно ясно, что проблема в синхронизации потоков, но как это обычно бывает: 

The fellow who designed it

is working far away;

The spec's not been updated

For many a livelong day.

The guy who implemented it is

Promoted up the line;

And some of the enhancements

Didn't match to the design

They haven't kept the flowcharts,

The manual's a mess,

And most of what you need to know,

You'll simply have to guess.

(с) чей-то

 

А меж тем система была серьёзная, установленная много где и рабочая. Какие-то вещи удалось исправить, но ничего кардинального изменять не стали. Вместо этого задумали новую систему :-)

 

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

 

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

Хотелось бы услышать глас народа по данному поводу.