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

[CDR]

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

http://eagleson.livejournal.com/180420.html

Цитата:

Каждый менеджер, управляющий командой, рано или поздно получает сотрудника, который а) ясно видит, как все сейчас в архитектуре продукта неправильно и б) точно знает, как должно быть. В результате сотрудник, конечно, приходит с гениальной идеей “а не затеять ли нам рефакторинг”. После чего на жалкие возражения менеджера типа “да и так работает неплохо, ломается редко, да пользователям не надо”, смело отвечает: “Это все не по уму. А вам просто всем положить на качество архитектуры и кода.” И ходит потом менеджер, рассказывает сказки про бизнес-ниды и риски.

Никому ничего не напоминает?

[gl00mie]

Какой-то прям антирефакторинговый паттерн, извините за великий и могучий... Но если на минутку оставить в стороне эмоции, то что мы увидим?

Цитата:

Строители, которые делали туалет, вмонтировали унитаз, не оставив места для сливного бачка. Когда бетон застыл, они растерялись.
Стоимость переделки (выломать унитаз из бетона, отодвинуть его на другое место, заделать стену и пр.) крайне высока.

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

Цитата:

В сложившейся ситуации нужно ли что-либо менять? Ежу понятно, что нет. А все-таки, может быть, кому-то нужно менять? Получается, что талантливому сантехнику, которому эта картина душу рвет.
В результате сотрудник, конечно, приходит с гениальной идеей “а не затеять ли нам рефакторинг”.

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

[sukhanchik]

В приведенном по ссылке примере не учтено, как правильно выразился gl00mie развитие системы.
Т.е. представим себе, что мы находимся не на территории бывшего СССР, а где-нибудь у буржуев, которые борятся за присвоение им звездочек для отеля.
Т.е. да, все работает, но приезжает комиссия - оценивать отель (нашу базу ), смотрит и видит вот такой бачок. Даа... говорят они - для поднятия с 3 звезд допустим до 4-х - вам нужно сделать.... далее по списку, плюс исправить этот бачок

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

[CDR]

Цитата:

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

Но если на минутку оставить в стороне эмоции, то что мы увидим?Сразу видим непрофессионализм исполнителей.

Профессионализм сантехников обсуждать не берусь.
К тому же не зная исходной ситуации, требований и ТЗ, сложно что-либо сказать по этому поводу.

Цитата:

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

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

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

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

В заключение могу лишь привести классику жанра
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.

[Starling]

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

Лучше изменить конструкцию и делать дальше правильно, с меньшими трудозатратами. При этом данный конкретный санузел можно оставить и в таком виде как достопримечательность)

Тоже самое мы имеем и на проектах. Зачастую в условиях ограниченного бюждета приходится принимать решения, которые будут работать только на этом проекте (или полностью аналогичном). Как пример – мне не раз приходилось делать постановки, которые закрывают функционал немедленного получения, так как:
1. Данный функционал в обозримом будущем не будет востребован заказчиком
2. Попытка автоматизировать БП с сохранением этой функциональности приведет к значительному увеличению трудозатрат, которые стоят денег

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

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

[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. не должен превращаться в переписывание существующей функциональности "с нуля".

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

[petr]

А можно пример с унитазом немного по другому повернуть?

Например мы делали решения для какого-то клиента. Оно получилось не очень красивым (или очень некрасивым), зато работает. Это аналогия с приведенным в примере унитазом.

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

[glibs]

Цитата:

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

...И как... мы должны поступить?...

Вопрос философский. Я пока пришел к такому мнению. Оптимизировать затраты клиента (в этом и вижу свою задачу как консультанта). Но при этом закладываться на развитие системы. Получается всяко разно. Универсальные механизмы не делаю по возможности. Дорого, если их доводить до ума. В архитектуре и коде стараюсь придерживаться ВР. Не брезгую таким подходом — сделать что-то в виде прототипа с малой частью функциональности, временное, чтобы понять как нужно на самом деле, куда двигаться. Т.е. возможно даже в некоторых случаях сделать нечто, что потом гарантированной выкинется и напишется снова, чтобы получить некий опыт или поэкпериментировать. Последний подход нередко экономит много денег заказчику. Часто многие безумные хотелки отпадают или забываются, а если идея вообще абсурдна, то заказчик приходит к пониманию этого малой кровью. А если их сразу проектировать в дизайне, то отбрыкаться от них на этом этапе тяжело. Но чтобы так делать нужно хорошо уметь воображать себе во что может вылиться финальное решение и знать систему, чтобы не пойти изначально не тем путем.

[gl00mie]

Цитата:

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

И как мы ... должны поступить?

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

Цитата:

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

Оптимизировать затраты клиента (в этом и вижу свою задачу как консультанта).
[...]
Но чтобы так делать нужно хорошо уметь воображать себе во что может вылиться финальное решение и знать систему, чтобы не пойти изначально не тем путем.

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

[glibs]

Тут в соседних ветках уже обсуждалась тема неадекватности хотелок многих заказчиков. Консалтинг — это работа с людьми (человеками, личностями, характерами). Нужно не только знать как правильно, но и привести к пониманию этого заказчика. Заказчик тоже, в общем-то, знает чего хочет. Не всегда может видеть правильный путь... и то тоже вопрос очень скользкий по каким критериям этот правильный путь определять. Я не из теоретических соображений пишу. А именно исходя из опыта общения с заказчиками. Бывает так сцепишься с заказчиком а-ля:
— Хочу такую фигню
— Так неправильно
— А мне так надо
Что потом сам долго пытаешься разобраться, как же правильно. Ведь заказчик всегда прав .

[petr]

Продолжу свою мысль...

А если добавить конкурентов. Мы строим туалеты с бочком снаружи, но все работает, технология отлажена, стоит недорого.

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

И кого выберет потенциальный заказчик? Наверное он выберет вариант с туалетом в его привычном виде.

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

[gl00mie]

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