Не надо по-хорошему, и так работает

[CDR]

Цитата:

Сообщение от gl00mie

Я не совсем понимаю, почему все свелось к алгоритмам, если честно.

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

Цитата:

Сообщение от gl00mie

Мне вот приходилось видеть описания таблиц OEBS, и что там первое бросилось в глаза - это наличие в значительной части таблиц множества зарезервированных полей (штук по пятнадцать). Для чего это было сделано? Думаю, чтобы при внедрении, если понадобятся какие-то новые атрибуты, поля с описанием и т.п., не менять схему БД, а использовать уже имеющиеся резервы в виде тех же неиспользуемых в стандартном функционале полей. Аналогичную картину можно наблюдать в Active Directory: у объектов классов user и group есть по 15 неиспользуемых атрибутов (называются extensionAttribute1 .. extensionAttribute15), которые, опять же, можно использовать для собственных нужд вместо того, чтобы заниматься самостоятельно изменением схемы AD. Относятся эти особенности к заложенным в упомянутые системы алгоритмам? По-моему, нет. Являются ли они особенностями архитектуры, позволяющими легче изменять и развивать их? На мой взгляд, да. Опять же, при создании многих систем используется объектно-ориентированный анализ и проектирование, а не просто алгоритмизация.

Как-то не совсем понятно, как наличие 15-ти зарезервированных полей или свойств (между которыми нет ни связей, ни отношений; которые не обрабатывает ни один алгоритм; и вообще они нигде не используются) упрощает изменение и развитие системы? С моей точки зрения – это некоторый бесполезный мусор. К тому же при дальнейшем развитии системы всегда нужно иметь в виду, что «зарезервированные» поля уже может кто-то использовать, причем самым невероятным образом.

Цитата:

Сообщение от gl00mie

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

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

Цитата:

Сообщение от gl00mie

Мешает отсутствие на этапе проектирования полного набора требований, которые будут предъявлены к модулю в ходе его эксплуатации. Это неминуемо ведет к принятию неоптимальных (с точки зрения последующих требований) архитектурных решений, в результате при появлении новых требований приходится либо "натягивать" решения на существующую архитектуру, либо менять ее в той или иной степени.

А вот здесь из Ваших же постов получаем очень интересный вывод.
Система с одной стороны «постоянно развивается», с другой стороны «отсутствие на этапе проектирования полного набора требований» приводит к кривой архитектуре. Однако если система «постоянно развивается», то полного набора требований не будет никогда по определению, соответственно и архитектура не может быть спроектирована идеально. Более того, в «постоянно развивающейся» системе по определению «приходится натягивать решения на существующую архитектуру». Вот и получаем такие вот "кривые", но работающие унитазы.

Цитата:

Сообщение от gl00mie

В приведенной статье речь идет о повторном использовании кода и о фатальных ошибках, совершаемых некоторыми командами и целыми компаниями, которые принимают решение выкинуть старый код и начать писать все с нуля; в частности, приводится поучительный пример Netscape, полностью утратившей в результате такого решения свои позиции на рынке браузеров. Как это подтверждает исходный тезис "Не надо по-хорошему, и так работает" или опровергает пользу рефакторинга, я не совсем понимаю. Джоэл, напротив, сам же пишет в этой статье (в вольном переводе):

Вот-вот. Что есть - то есть. И пусть оно имеет "непонятную уродливую" архитектуру, но оно спроектировано, разработано, протестировано и реально уже эксплуатируется пользователями. И скорее всего, поскольку система «постоянно развивается», "непонятная и уродливая" архитектура является именно прямым следствием того, что система реально работает.

ПС: Я не коим образом не стремлюсь опровергнуть пользу рефакторинга. В разумных пределах этот процесс просто жизненно необходим. Но, имхо, рефакторинг:
1. должен выполнятся именно в процессе разработки/доработки (а не как это часто бывает "хорошая мысля приходит апасля", и на ровном месте пошло-поехало).
2. не должен превращаться в переписывание существующей функциональности "с нуля".

ППС: Что-то забавный уродливый унитаз плавно перекочевал почти в философскую дискуссию