Здравствуйте, alexsoff, Вы писали:

A>Согласен, но я сказал "обычно".
По идее, тебя должен интересовать не общий, а твой конретный случай...

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

K>>Тогда так ли очевидны проблемы от якобы плохого кода?
E>От плохого кода проблема одна — стоимость и время появления новой фичи огромна! В проекте, про который я говорил — выпуск нового релиза вместо плановых трех месяцов затягивался на полтора года. Если новых фич не добавляем, а единственное, что меняем — это дизайн покрасивше, это одно. А когда требования меняются, иногда в последний момент перед релизом, а если не успеете, то не купим — с говнокодом далеко не уедешь.

IMHO нужно смотреть на нетто-эффект. Рефакторинг, а тем более переписывание _работающего_ года может быть очень дорогой операцией.

Здравствуйте, alexsoff, Вы писали:
A>Тут палка о двух концах, в таком виде в котором проект сейчас сможет въехать любой студент, посади его, а через месяц он будет чувствовать себя королем, а я же хочу внедрить паттерны, что несомненно поднимет планку для вхождения. Очевидно, что начальству будет импонировать вариант студента с наименьшими будущими затратами.

Слушай,а ты свои "паттерны" уже использовал в коммерческом проекте или прочитал книгу и решил резко внедрить?

Здравствуйте, Fasa, Вы писали:

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

Автор: alexsoff
Дата: 13.11.11

, есть подозрение, что это не так.

Здравствуйте, Олег К., Вы писали:

A>>Неужели настолько всё плохо ?

ОК>Настолько. Это в России автоматизация в зачаточном состоянии, а в Штатах она уже давно. Любой долгоживущий код становится плохим со временем. Ну и добавь к этому что многие кто внес свою лепту в этот код просто не умеют программировать.

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

Здравствуйте, MxMsk, Вы писали:

A>>Для твоего соседа твой код выглядит так-же непонятно как его код для тебя.
A>>И стиль отличается настолько же.
MM>Получается, опыт никакой роли не играет. Знания ничего не значат. Всё объясняется только неумением читать чужой код?

Вообще, новичок не разберётся в коде опытного программиста, опытный не разберётся в коде новичка (точнее не захочет разбираться).
Можно подумать, что нет никакой разницы.
Но... другой новичок также не сможет разобраться в коде новичка, умение читать чужой код приходит только с опытом, а опытный программист сможет разобраться в коде другого опытного программиста.

Здравствуйте, SkyDance, Вы писали:

Pzz>>А чем плох вялотекущий рефакторинг?

SD>Какую цель имеет перед собой оный рефакторинг? Просто потратить время? Нанести проекту непоправимую пользу? А оно надо? Может, этот проект вообще не планируется развивать в том месте, которое зачем-то вялотекуще рефакторят.

Это не цель, а стиль кодирования.
Есть какая-то изолированная функция, на неё куча тестов. То есть известно, что в целом она работает верно. Но приходится немного модифицировать её. Заглядываем внутрь и видим, что там самый настоящий говнокод. Причём не факт, что писали студенты, возможно предыдущий программист не стал разбираться в функциональности, а просто сверху что-то налепил. Некрасиво, зато быстро и работает.
Но у тебя задача посложнее, просто сбоку прилепить ничего не получится, приходится разбираться в логике. И видишь кучу нестыковок и особенностей. Проще сразу их поправить, чтобы код стал проще, тогда и вносить изменения будет легче. Главное сильно не увлекаться.

Здравствуйте, alexsoff, Вы писали:

A>Здравствуйте, Aviator, Вы писали:
A>>Пропал проект...
A>Давайте говорить за себя

Я скажу за себя. Помню как-то прочитал книжку по шаблонам, хорошую книжку (сине-оранжевую ), ух у меня руки зачесались. Шаблоны так и отскакивали при написании, поразительно сколько вещей можно сделать применяя их, как я раньше без них обходился.
Ну что в результате — проект не пропал, развивается, всё в порядке. Но сл. программисту я не завидую, лучше бы ему первым делом убрать все эти шаблоны, я там реально скрестил утку с ежом, кода стало меньше, но чтобы что-то править надо регулярно подобные книжки читать.

Здравствуйте, alzt, Вы писали:
A>Я скажу за себя. Помню как-то прочитал книжку по шаблонам, хорошую книжку (сине-оранжевую ), ух у меня руки зачесались. Шаблоны так и отскакивали при написании, поразительно сколько вещей можно сделать применяя их, как я раньше без них обходился.
A>Ну что в результате — проект не пропал, развивается, всё в порядке. Но сл. программисту я не завидую, лучше бы ему первым делом убрать все эти шаблоны, я там реально скрестил утку с ежом, кода стало меньше, но чтобы что-то править надо регулярно подобные книжки читать.
я когда прочитал книжку по шаблонам то из интересного увидел только двойную диспетчеризацию (или это вообще не оттуда), больше чисто философски понравились характеристики классов и еще содрал у Александреску смартпойнтер. больше ничего нового и интересного не нашел. никаких фасадов, мостов, прокси и декораторов в реальных проектах нет. синглетон может разве что где-нить затещется и все. все остальное на здравом смысле основано

Здравствуйте, __kot2, Вы писали:

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

Так там особо и нет паттернов. Там есть использование шаблонов, вот их то я и начал использовать там где надо и где не надо, книга Вандевурда.

Здравствуйте, Aviator, Вы писали:

A>Слушай,а ты свои "паттерны" уже использовал в коммерческом проекте или прочитал книгу и решил резко внедрить?
Конечно, и не представляю как без них
а)Избавиться от дублирования и запутанности (Domain, Layers)
б)Написать нормальные тесты. (DI IoC)
в)Отделить логику от представления. (MVC MVP)

Здравствуйте, alexsoff, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>Слушай,а ты свои "паттерны" уже использовал в коммерческом проекте или прочитал книгу и решил резко внедрить?
A>Конечно, и не представляю как без них
Без каких конкретно?

A>а)Избавиться от дублирования и запутанности (Domain, Layers)
Какое отношение дублирование и запутанность имеет к Layers и Domain, что вообще понимается под последним кстати?

A>б)Написать нормальные тесты. (DI IoC)
Какое отношение написание тестов имеет отношение к IoC?

Здравствуйте, Aviator, Вы писали:

A>Без каких конкретно?
Основные я перечислил.

A>Какое отношение дублирование и запутанность имеет к Layers и Domain, что вообще понимается под последним кстати?
Это видно на практике (с ходу простой пример сложно придумать), а по второму вопросу http://martinfowler.com/eaaCatalog/domainModel.html

A>>б)Написать нормальные тесты. (DI IoC)
A>Какое отношение написание тестов имеет отношение к IoC?
DI это частный случай IoC.

Здравствуйте, alexsoff, Вы писали:

A>>Какое отношение дублирование и запутанность имеет к Layers и Domain, что вообще понимается под последним кстати?
A>Это видно на практике (с ходу простой пример сложно придумать), а по второму вопросу http://martinfowler.com/eaaCatalog/domainModel.html
Т.е. до статьи Фаулера можно было писать исключительно дублирующийся и запутанный код? Ну а разделение на слои конечно же делает код понятным и исключает дублирование.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, SkyDance, Вы писали:

Pzz>>>А чем плох вялотекущий рефакторинг?

SD>>Какую цель имеет перед собой оный рефакторинг? Просто потратить время? Нанести проекту непоправимую пользу? А оно надо? Может, этот проект вообще не планируется развивать в том месте, которое зачем-то вялотекуще рефакторят.

Pzz>Как и уборка помещения: 1) санитарно-гигееническую: поддержание в коде порядка 2) дисциплинарную: код, в котором убираются, вызывает меньшее желание в него срать

Зачем регулярно убирать помещение, в котором годами никто не появляется? Например склад долговременного хранения?

Здравствуйте, Олег К., Вы писали:

G>>Может, все может быть.
G>>А кто заставляет тебя принимать решения, к которым ты пока готов? Работодатель погнался за дешевизной или это твоя инициатива? В любом случае в такую ситуацию лучше не попадать. Мы вряд ли не видя кода сможем подсказать, а даже и если бы и видели, отвечать-то тебе.

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

Здравствуйте, Aviator, Вы писали:

A>Т.е. до статьи Фаулера можно было писать исключительно дублирующийся и запутанный код?
Причем тут это? его труд заключается в том, что он многие вещи систематизировал.
A>Ну а разделение на слои конечно же делает код понятным и исключает дублирование.
Это зависит от реализации, разделение на слои помогает скорее разделить ответственность кода, опять таки сильно зависит от реализации.
A>Скорее всего значительно хуже. Автор топика напихает туда всяких "слоёв" и "паттернов", в результате код превратится в технологическую помойку. А на каждый фич реквест будет требоваться по месяцу кодирования, так как именно эта фича не вписывается в гениальную внедрённую архитектуру.
"Спасибо" конечно на добром слове. Вы я вижу неплохо справляетесь с ролью "прорицателя".

Здравствуйте, alexsoff, Вы писали:

A>"Спасибо" конечно на добром слове. Вы я вижу неплохо справляетесь с ролью "прорицателя".

У меня сложилось впечатление (возможно ошибочное), что бы создали эту тему, чтобы услышать: "Да, да, молодец, мы думаем точно так же". И очень удивлены существованием альтернативных точек зрения.

Здравствуйте, Kerk, Вы писали:

K>У меня сложилось впечатление (возможно ошибочное), что бы создали эту тему, чтобы услышать: "Да, да, молодец, мы думаем точно так же". И очень удивлены существованием альтернативных точек зрения.
Я создал эту тему, чтобы услышать, что у кого-то был опыт (успешный или не успешный) в переписывании проектов с нуля, а не о том, что у меня низкая квалификация и я вообще должен провалить проект.
А на каждый фич реквест будет требоваться по месяцу кодирования, так как именно эта фича не вписывается в гениальную внедрённую архитектуру.
A>А на каждый фич реквест будет требоваться по месяцу кодирования, так как именно эта фича не вписывается в гениальную внедрённую архитектуру.
Я сторонник agile процесса и DDD, при которых не исключается,а наоборот приветствуется постоянный рефакторинг.

Здравствуйте, Ведмедь, Вы писали:

В>Зачем регулярно убирать помещение, в котором годами никто не появляется? Например склад долговременного хранения?

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