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

[gl00mie]

Цитата:

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

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

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

Цитата:

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

Заметьте, очень часто при внедрении DAX, требуется разработать какой-либо новый модуль. В подавляющем большинстве случаев он со временем превращается «во Франкенштейна, неуклюже соштопанного из разнородных лоскутков». Что мешает внедренцам создать с нуля идеальную архитектуру?

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

Цитата:

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

В заключение могу лишь привести классику жанра
http://www.joelonsoftware.com/articl...000000069.html

Цитата:

As a corollary of this axiom, you can ask almost any programmer today about the code they are working on. "It's a big hairy mess," they will tell you. "I'd like nothing better than to throw it out and start over."
<поскипано>
The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed.

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

Цитата:

Основная причина, почему программисты могут утверждать, что код является непонятной мешаниной, - это проблемы архитектуры. [...] Подобные проблемы могут быть решены, по одной за раз, за счет аккуратного перемещения участков кода, рефакторинга, изменения интерфейсов. Даже достаточно серьезные архитектурные изменения могут быть осуществлены без необходимости выбрасывать старый код.

[CDR]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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