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

U>>Проблема копипасты как раз не в лишней механической работе, а в том что думать при внесении изменений приходится очень много
O>Если для копипастеров не проблема думать "очень много" по сравнению с тем если бы делали "с паттернами", то почему они не выбирают менее трудный путь (при котором думать надо меньше) и не переходят на паттерны?

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

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

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

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

UA>Ты явно перечитался книг — не везде паттерны нужны, а иногда даже вредны.

Они может и не вредны, но сама цель — "паттерны ради паттернов" забавна. Тут явно преобладание теоретических знаний над практическими. Собственно, после внедерения этих самых паттернов подтянутся и практические знания. Так что стратегия в некотором смысле работает на пользу топикстартера.

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

O>>Либо студенты реально делают очень мало, и опытному специалисту не должно составить труда сделать то же самое, потратив десятую часть усилий,
O>>либо страшные сказки о якобы заржавении мозгов с возрастом таки правда?
A>Я не писал, о том, что мне трудно "наращивать функционал", но мне не приятно будет заниматься копипастом иначе текущая "архитектура" другого не позволяет.
A>Данная система 99% будет только расширяться, а сейчас она расширяется только благодаря копипасту.

Я не пойму — кто тебя заставляет копипастить? Если код написан в макаронном стиле с кучей копипаста — тебе же не обязательно дописывать его также.
Да, раздражает, что качества кода не особо, но все свои изменения можно делать качественно. Постепенно уменьшая количество этих копипастов. Конфеткой может код и не станет, но работать будет намного приятнее.

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

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

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

G> Мы вряд ли не видя кода сможем подсказать, а даже и если бы и видели, отвечать-то тебе.
Вот это самый здравый ответ в этой ветке на вопрос, что я задал.

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

A> Что делать в таком случае? Переписывать проект заново, но сомневаюсь, что это поддержит начальство (проект на 6 человеко месяцев) или оставить все как есть, но в этом случае будем молиться на этого разработчика и думать как бы он не ушел.

Никто тебе точно не скажет что делать в твоем конкретном случае без тщательного изучения кода и требований к проекту. А есть требования-то задокументированные? Есть фичелист и тп?

Много раз люди вставали на грабли "перепишем с нуля" делая еще хуже: там был код, и он работал. Начинают переписывать на своем уровне понимания фич и получается что "то забыли, то вот не знали, тут не работает". Потом начинается мучительный багфикс в спешке и допиливание своего же. И результат в итоге ничуть не лучше (а то и хуже!) чем был. Переписать коммерческий проект — это не лабораторную же переделать.

Итого, варианта 3:
1) забить, поддерживать то, что есть, если текущее состояние кода не мешает вести бизнес( а не мозолит кому-то глаза! )
2) постепенный рефакторинг — составляем фичелист, составляем нормальные тесты с хорошим покрытием (очень желаетельно и авто, и ручное, и юнит). Постепенно, шаг за шагом, в отдельном бранче, по кусочку выправляем код. Полностью протестированный кусочек интегрим в основной проект и смотрим реакцию кастомеров или кого еще там. Если хуже не делаем — идем дальше. Если хуже — неправильно поставлен процесс разработки
3) (самый плохой во многих случаях, и самый сложный) переписать с нуля! ура, чистый лист и все такое. начинаем.... с постановки процесса(!!!!!!!) разработки, который включает в себя тщательное(!!!!!!) изучение как текущей функциональности, так и новых требований, документирование этого всего для себя чтобы по этому поставить нормальное тестирование всех видов и этапов (!!!!!!!), и спроектировать основу. Пишем прототип. Проверяем что наш процесс и наш подход к архитектуре работает. Далее итеративно переписываем код. Постоянно тестируем и отправляем промежуточные версии на использование, чтобы заранее знать куда мы идем. Я видел очень мало людей, кто реально может наладить нормальный процесс разработки. И им было не 25 (с уважением, но факт)

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

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

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

Проще будет для разработчика.
Для бизнеса дешевле не будет — просто появится еще один паралельный проект, который нужно сопровождать, багфиксить и саппортить наряду со старым. Т.е. на какое-то время расходы вырастут примерно в 2 раза.
Если к этому добавить риск того, что разработчик, который взялся переписывать код вдруг свалит и на его место придет новый ковбой со своими "паттернами", то хочется сразу поддаться заповеди "don't fix if it works"
И это не считая всяких неочевидных подводных камней в логике приложения, и фиксов, которые вносились в старый код по одной строке. Все это всплывет при переписывании с нуля.

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

Вобщем, моя мысль такая, что ценятся разработчики, которые могут вписаться в комманду, улучшить и упорядочить СУЩЕСТВУЮЩИЙ код с осознанием сроков этих улучшений.
Т.е. "умение работать с чужим кодом" — это не пустая строчка в резюме, а очень важный скилл. И некоторым не помешало бы его прокачать.

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

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

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

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

A>Рефакторинг это понятно, а не будет ли так, что проще и дешевле переписать все с нуля.
Я не уверен что проще. Если код хреновый, то требования и документация обычно на порядок хуже, и даже близко не отражают то, что нужно. Внутри куча хитрых костылей, которые являются фичами, но почему их кто туда поставил — никто не знает. Потому проблема в том, что ты не знаешь что ты переписываешь. Не знаешь ни требования, ни почему так сделано — лучшая документация, которая у тебя есть — это говнокод, в котором надо разбираться. У меня был случай — дают огроменный набор файлов, которые даже не в репозитории, и говорят — сделайте чтоб быстрее работало и сделайте многопоточным. Это даже не собирается, если что — пришлось сначала написать билд скрипт и все такое, поместить в репозиторий. На вопрос — а как эту хрень запустить и что это вообще такое, отвечают, что не знают. Начинаю запускать — отрабатывает мгновенно. Что там ускорять непонятно. Потом начал дебажить, оказывается, что чтоб все работало, запускать нужно строго в 0 часов 0 минут, иначе будет мгновенный выход. Подобных анекдотичных случае в этим модулем было до черта, я к счастью с него свалил достаточно быстро. А кто был после меня — те его героическими усилиями отрефакторили за год. Поняли что это за хрень только после рефакторинга. Но. Сказали, что уже типа не надо, вот немного другая задача, возьмите другие исходники этого же самого дерьма, которые еще древнее, свой рефакторинг откатывайте, так как не понятно как проверить, с сидите в этом говне ковыряйтесь, но без изменения архитектуры. Да — архитектура гениальна, что угодно можно реализовать на такой архитектуре. Все связано со всем через глобальные переменные. Все методы статические. Правда методами это можно считать весьма условно, типичный метод — 5000 строк дикого копипаста из вложенных if for case switch.
Короче для себя я решил, что меньше чем за 5000 баксов в месяц я в говнокоде ковыряться не буду больше ни за что на свете.

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

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

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

Не получается. Тренируй скилл чтения на русском языке.
Знания, конечно что-то значат. Только их хорошо бы как-то демонстрировать, перед тем, как кидаться какашками.
Смотря что Вы понимаете под словом "всё". Посты подобные тому, который начал ветку именно неумением читать чужой код.

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

E>Короче для себя я решил, что меньше чем за 5000 баксов в месяц я в говнокоде ковыряться не буду больше ни за что на свете.

Это не Д***софт Новосибирский случаем был? Проект Г***ая к***а? Впрочем, до них этим проектом кто только не занимался.

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

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

Зависит от ситуации. Крайние случаи следующие:

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

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

Когда ситуация нечто среднее между этими крайними случаями, то надо разбираться индивидуально.

Также отмечу следующее:

1) Код следует переписывать не сразу весь, а отдельными модулями.

2) Если оцениваемое время переписывания модуля порядка двух недель, то можно переписывать смело. Если больше, то надо хорошо подумать.

3) Перед переписыванием желательно в течении определенного времени поподдерживать старый код, добавляя функциональность и правя баги по мелочи. Это позволяет разобраться в предметной области и понять, что переписываемый модуль должен делать.

4) При переписывании стремится писать код как можно проще. Т.е. в идеале без дублирования и с минимально возможным количеством слоев абстракций.

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

A> Что делать в таком случае? Переписывать проект заново, но сомневаюсь, что это поддержит начальство (проект на 6 человеко месяцев) или оставить все как есть, но в этом случае будем молиться на этого разработчика и думать как бы он не ушел.

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

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

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

А вы не бойтесь. Если бы код работал как надо, вы бы уже лет пять сидели без работы, а, может, и десять (не знаю вашего возраста, но склоняюсь к 5-ти).

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

A>не знает про интерфейсы

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

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

A> Если код не смотрит наружу, то нафиг интерфейсы.
А как же тестирование, DI?

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

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

A>> Если код не смотрит наружу, то нафиг интерфейсы.
A>А как же тестирование, DI?

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

ОК>>У тебя как-то все очень легко получается. И время на все есть. И на форум тоже есть. Меня терзают смутные сомнения.
E>Есть время, потому как за кодом слежу, и не довожу до такого состояния, когда подвиги требуется совершать . А вот кто дерьмо не разгребает — у тех времени никогда нет.

Потому что проект маленький. Поэтому и можешь.

ОК>>Не рухнет. Мой экспириенс говорит что и код с кучей г-на может жить десятками лет.
E>Жить то может. Вот только при наличии конкурентов мой опыт говорит, что через 4 года конкуренты начнут тебя догонять, если в проекте куча говна, а далее обгонять. Ну а если конкурентов нет, то да — может и 50 лет прожить.

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