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

[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, полностью утратившей в результате такого решения свои позиции на рынке браузеров. Как это подтверждает исходный тезис "Не надо по-хорошему, и так работает" или опровергает пользу рефакторинга, я не совсем понимаю. Джоэл, напротив, сам же пишет в этой статье (в вольном переводе):

Цитата:

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