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

A>Не внимательно читаешь, я отвечаю за этот проект, что не ясно?
Мне кажется, что ты ставишь неверные цели.
Перед тем, как ставить цель "как сделать лучше", хорошо бы достичь цели "как не навредить"...

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

A>Это очевидно, добавляем слой абстракции — сложность увеличилась, или не? Избавляемся от практики копипаста — сложность увеличилась, т.к. приходится теперь вместо механической работы — думать и понимать как система устроена в целом.

Всё ровно наоборот!
Думать надо не над тем, как доавить фичу, а над тем, как сделать так, чтобы добавить фичу ии найти ошибку можно было как можно более простым и механическим путём...

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

O>Вместо _большого количества_ дурацкой однообразной работы по перелопачиванию субстанции — выстроить систему так, чтобы надо было подумать и _немного_ дописать кода.
O>Вот эту идею надо понять как до руководства донести.
O>Что в долгосрочной перспективе (дольше чем прощёлкивание одной галочки в трекере задач) это выгоднее.

Очень часто это не выгоднее...

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

K>Это точно, не видел. Всегда есть что-нибудь кривое. Или вообще всё

Ну, то есть, ты самый умный? Ничего не настораживает?..

ОК>>Ну а раз у тебя возникает желание переписать какой-то код, то значит он не так уж и плох в первую очередь.

K>Чего-чего?
Ну реальный говнокод срашно трогать. Просто никто не может сказать как оно точно работает, есть куча смежного кода, данных и пользователей, которые уже ориентированы на особенности того говноода, и главное, есть огромная работа по отладке и настройке на конкретных юзкейсах, информация об этом нигде не сохраняется, обычно, и спеки тоже не правятся или отсутствуют. Так что, на самом деле не известно, какая часть особенностей поведения этого говнокода -- ошибки и глюки, а какая -- полезные эвристики.

Так что рефакторинг обозначает обычно, либо потерю в качестве работы кода, либо ограмную работу по отладке, либо точное воспроизведение ричудивого поведения исходного говнокода.
Первые два пути обычно неприемлемо дороги, последний не имеет смысла...

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


ОК>>И что ты предлагаешь? Чтобы каждый очередной девелопер переписывал код предыдущих?
E>Лично я переписываю. Точнее рефакторю безжалостно все, до чего могу дотянуться в рамках выполняемых задач. Как свое рефакторю, так и чужое. <...> Если это не делать, и если каждый в команде это не будет делать, то проект рухнет под тяжестью дерьма в нем.
E>теория разбитых окон, советую ознакомиться
Это вопрос чувства меры и опыта. С одной стороны излишние правки -- излишние риски и удорожание рпзрпботки. С другой стороны, слишком консервативный рефакторинг -- путь к заростанию проекта дерьмицом. Тут надо соблюдать некую золотую середину.

Но ТС ароде как говорит не о том, чтобы по мере поддержки эвоюционно рефакторить код, а о революции, по типу "мы наш, мы новый код напишем", а это уже очень рискованно.

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

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

MM>Мне-то как раз ясно, что ты хочешь сделать хорошо.

Мне, например, тоже ясно, что он хочет сделать хорошо. Но чем боьше alexsoff описывает своё видинее ситуации, тем боьше я сомневаюсь, что у него получится сделать лучше, а не хуже...

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

ОК>Не рухнет. Мой экспириенс говорит что и код с кучей г-на может жить десятками лет.

Лучше всё-таки чистить, но аккуратно и только там, где уже и так надо что-то менять.
Можно, конечно, и рефакторинг целых больших кусков иногда делать, но лучше написать перед этим экономическое обоснование такой деятельности. Это же инвестициия? Ну вот и надо её, как инвестицию оценить, стоит ли оно того...

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

C>>К слову, для этого не обязательно весь код на помойку выкидывать.
A>Рефакторинг это понятно, а не будет ли так, что проще и дешевле переписать все с нуля.

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

Я так тебя понял, что у тебя сейчас "временное затишье перед бурей" и ты в сомнениях куда инвестировать время?
Потрать его на изучение кода + окрытие его тестами. Типа разобрался с чем-то -- написал тест и откомменитровал его.
За одно тесты можешь сделать "с ООП и паттернами", и оценить как они на этой задаче работают
И смотреть как и что можно поменять и как и что в этой системе искать. Если найдёшь, что что-то менять/искать трудно, то там и чини, только сначала тестами покрой...

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

MM>>Если так трудно, я раскрою. Если код пишу я, то готов отвечать за него.
SD>Это, конечно, превосходно. Чем именно вы готовы отвечать? Зарплатой? Свободой (уголовная ответственность)? Жизнью? Если бы вы были готовы нести хоть какую-то ответственность, вы бы не писали ерунды на тему "не хочу отвечать за других". Конечно, не хотите, вы и за себя пока не можете.
На вопросы встречные не отвечаешь. Бестолку продолжать.

MM>>>Считаешь, мне доставляет удовольствие копаться в коде другого программиста? Думаешь, мне нравится заниматься разгребанием говнокода и поиском решений, как поправить то, что изначально можно было написать правильно? Да ни капельки! Если бы мог, всегда держался бы подальше — больно надо париться.

ОК>>Открою тебе один секрет. Это мало кому доставляет удовольствие. Однако люди работают а не кричат что они достойны большего (писать новый код с нуля).
MM>Гдя я написал, что предпочитаю не работать, и кричал, что достоен большего?

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

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

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

SD>Ого! Впервые встречаю такую юзабилити, которую просто придумали — и бац, она уже есть, и программистам не надо "кодировать формочки" На моей памяти, именно юзабилистские заморочки (особенно на вебе) выносили мозги программистам А вовсе не супер-пупер алгоритмы, для знания которых нужно аж целый день вчитываться в алголист.мануал.ру

Просто задачи разные бывают. Бывают и такие, где GUI самая простая часть системы...

M>>>>Это не Д***софт Новосибирский случаем был? Проект Г***ая к***а? Впрочем, до них этим проектом кто только не занимался.
E>>>Нет, это вообще американский проект был. Хотя, сейчас посмотрел — еще жив, правда логотип фирмы давно уже другой . Интересно, дерьмо стали разгребать или нет ...

ОК>>Так и живут. Большинство проектов в Штатах в подобном состоянии, плюс-минус.
A>Неужели настолько всё плохо ?

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

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

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

E>То, что код, который с втоей точки зрения "лучше", для поддержки сложнее, чем имеющийся...
Лучше в плане требований к начальным знаниям. скажем в процедурном коде не совсем нужно знать про ООП.

E>Во-первых, вовсе и не всегда интерфейсы и ООП уместны.
В случае тестирования очень даже и уместны, вот только не нужно говорить, что тестирование это плохо
E>Во-вторых, чисто по моей практике, многие люди как-то странно ООП применяют.
E>Скажем многие пишут иерархии, анаогичные седующей:

фигура;
E>треугольник : фигура;
E>квадрат : фигура;
E>пентагон : фигура;
E>шестиугольник : фигура;

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

E>Ну и вообще, обычно, чем код ЛУЧШЕ, тем он ПРОЩЕ. Проще, а не сожнее. И въехать проще, а не сожнее и т. д...
Код обычно лучше, когда он слабосвязанный и с легкостью подвергается изменениям. А что бы такого достичь нужно очень хорошо въехать в предметную область и/или постоянно находится в рефакторинге.

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

A>Лучше в плане требований к начальным знаниям. скажем в процедурном коде не совсем нужно знать про ООП.
Так может это и хорошо?..

E>>Во-первых, вовсе и не всегда интерфейсы и ООП уместны.
A>В случае тестирования очень даже и уместны, вот только не нужно говорить, что тестирование это плохо
Ну тестирование -- он по разному может быть устроено.
Можешь рассказать что-нибудь о задаче и требованиях? Хотя бы в общих чертах?
Зачем там ООП, например?

E>

E>фигура;
E>треугольник : фигура;
E>>квадрат : фигура;
E>>пентагон : фигура;
E>>шестиугольник : фигура;

A>Вам не кажется, что иерархии от контекста и способов дальнейшего применения должны зависеть?
Кажется. Интересно узнать контекст, где уместна приведённая...


A>Код обычно лучше, когда он слабосвязанный и с легкостью подвергается изменениям. А что бы такого достичь нужно очень хорошо въехать в предметную область и/или постоянно находится в рефакторинге.
Не всегда верно, как первое, так и второе утверждения...
Расскажи что-то про задачу, и про особенности текущей реализации, если уже разобрался. Тебе дадут более конкретные советы, скорее всего...

E>Просто задачи разные бывают. Бывают и такие, где GUI самая простая часть системы...

Бывают, конечно. Но даже в таких задачах, если вдруг UI требуется доделывать (али переделывать), на сие мероприятие нужно выделять время.

A>>Лучше в плане требований к начальным знаниям. скажем в процедурном коде не совсем нужно знать про ООП.
E>Так может это и хорошо?..

Так то ж старая тема. Сделать простой код сложным — легко. Сделать сложный простым — напротив, весьма и весьма непросто.

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

SD>Бывают, конечно. Но даже в таких задачах, если вдруг UI требуется доделывать (али переделывать), на сие мероприятие нужно выделять время.
При вменяемом управлении разработкой на любую работу нао выделять потребные ресурсы...

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

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

ОК>Мне тоже много чего не нравится в нашей индустрии но что поделаешь? Вообще считаю что если умеешь хорошо программировать, то надо создавать свой коммерческий проект. Так что и ты пробуй.
Ок

Здравствуйте, Erop, Вы писали:
E>Так может это и хорошо?..
Я сторонник проектирования по предметной области хорошо описанной Эвансом.

E>Ну тестирование -- он по разному может быть устроено.
Причем тут устроено, главное чтобы оно отвечало конечной цели -а именно отлов ошибок при рефакторинге.
E>Можешь рассказать что-нибудь о задаче и требованиях? Хотя бы в общих чертах?
Уже не зачем, решение принято в пользу постепенного рефакторинга с применением тестов.

A>>Код обычно лучше, когда он слабосвязанный и с легкостью подвергается изменениям. А что бы такого достичь нужно очень хорошо въехать в предметную область и/или постоянно находится в рефакторинге.
E>Не всегда верно, как первое, так и второе утверждения...
Согласен, но я сказал "обычно".
Тебе дадут более конкретные советы, скорее всего...
Меня интересовали прежде всего истории, когда проект полностью переписывался, но как оказалось — никто этим не занимался и поддержки это не получило.

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

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