A>>Что делать в таком случае? Переписывать проект заново, но сомневаюсь, что это поддержит начальство (проект на 6 человеко месяцев) или оставить все как есть, но в этом случае будем молиться на этого разработчика и думать как бы он не ушел.
R>я бы переписал, впрочем я обычно так и поступаю всегда, так как еще мин.обороны сша в 70-х выяснило что внесение изменений в готовую софтину на порядки дороже написания новой, но этот подход сейчас считается непрофессиональным и порицается, так что прежде чем менять посмотрите по сторонам и взвесьте последствия для себя
Я боюсь представить что будет если каждый последущий разработчик будет переписывать код предшественника(ов).
__>Здравствуйте, __kot2, Вы писали: __>>это для тебя она станет организованной. а придет новый человек, для него твой код будет свалкой гавна. __>я, например, еще не видел ни одного даже суперопытного разработчика, который бы систематически не писал херни по моему мнению. например, один знакомый недавно отколол — memsetом классы инициализировал. и все работало, пока он виртуальные методы не ввел. и че-то сламалася
Ну это явно сразу что плохой разработчик. Для того чтобы не инициализировать объекты memset-ом суперопытным быть не надо.
K>Рефакторить или отказаться с этим работать, других вариантов для уважающего себя профи просто нет
Виден совет непрофессионала. Код которому 10-20-30 лет и который писала куча людей которые больше не работают в компании ты тоже начнешь сразу переписывать или отказываться с ним работать?
A>Тут палка о двух концах, в таком виде в котором проект сейчас сможет въехать любой студент, посади его, а через месяц он будет чувствовать себя королем, а я же хочу внедрить паттерны, что несомненно поднимет планку для вхождения. Очевидно, что начальству будет импонировать вариант студента с наименьшими будущими затратами.
A>>Что делать в таком случае? Переписывать проект заново, но сомневаюсь, что это поддержит начальство (проект на 6 человеко месяцев) или оставить все как есть, но в этом случае будем молиться на этого разработчика и думать как бы он не ушел. E>Лучше всего в Москву валить в твоем случае. Хоть на удаленку, хоть как — любыми средствами. Чем раньше, тем лучше — промедление смерти подобно. У тебя явно избыточная квалификация для твоего работодателя.
Судя по желанию всюду пихать паттерны и все переписать у него ее вообще нет.
E>Сидеть на такой работе, где говнокод ковырять — это деградация в любом случае.
Такова работа программиста — ковыряться в коде предшественников.
E>Это никогда себя не окупит! Денег у тебя не будет столько, сколько могло бы быть в Москве, даже в случае, если ты наивысшую для простого неблатного смертного карьеру сделаешь, уйдя из программирования. А проект можно даже не пытаться вытягивать — один хрен тебе даж спасибо никто не скажет — это не надо никому.
Ну почему сразу вытягивать? Топикстартер описал обычную рабочую ситуацию.
A>>Что делать в таком случае? Переписывать проект заново, но сомневаюсь, что это поддержит начальство (проект на 6 человеко месяцев) или оставить все как есть, но в этом случае будем молиться на этого разработчика и думать как бы он не ушел.
L>Когда делаешь задачу/фикс, то каждый раз делай чуть больше, чем нужно для реализации задачи — отрефактори и причеши ближлежащие методы/классы, перегруппируй код, вынеси повторяющиеся куски кода, исправь ворнинги и хинты решарпера, добавь тесты. Так мало-помалу может и приведешь в божеский вид. L>Главное не бросайся переписывать с нуля — говнокод сложен для понимания и легко неправильно понять "гениальные" мысли предшественника и поломать рабочий код.
У топикстартера не менее гениальное видение кода. Здесь.
Здравствуйте, Олег К., Вы писали:
K>>Рефакторить или отказаться с этим работать, других вариантов для уважающего себя профи просто нет
ОК>Виден совет непрофессионала. Код которому 10-20-30 лет и который писала куча людей которые больше не работают в компании ты тоже начнешь сразу переписывать или отказываться с ним работать?
Точно, как это я не сообразил. Настоящие "профи" код никогда не рефакторят
Я всегда переписываю код, который крив. Неважно кто его писал и когда.
А что я тут не правильно сказал? Человек работающий с этим проектом не знает вообще ООП, не знает про интерфейсы, и уж не очевидно ли что если я ввиду любые ООП конструкции(что как бы подразумевает введение паттернов) это повысит планку для вхождения? обоснуйте свой ответ, а не кидайтесь г*ном сударь.
SD>Да, может. Особенно если паттерны бездумно применяются свеженьким выпускником ВУЗа, годков так 22-26. Как раз ваш случай.
Вот не нужно делать таких выводов вы мой бекграунд не знаете. SD>Любым инструментом можно сделать хорошо. Скажем, скальпелем. А можно и убить пациента вконец. Так же и запиливание паттернов поверх спагетти-кода может кого угодно убить.
Если использовать стандарты, то даже скальпелем не убьешь. SD>Пишите уж лучше новый, раз существующий — существует и работает. Если им пользуются — не трогайте без необходимости. Совет из жизненного опыта.
Только при условии, что я не буду за него отвечать.
Здравствуйте, alexsoff, Вы писали:
SD>>Да, может. Особенно если паттерны бездумно применяются свеженьким выпускником ВУЗа, годков так 22-26. Как раз ваш случай. A>Вот не нужно делать таких выводов вы мой бекграунд не знаете.
Ты не путай! Это ты не имеешь права оценивать других, а вот другим оценивать тебя можно
Запомни: Ты лох, остальные молодцы.
Ты не можешь видеть проблемы в других программистах, зато они видят тебя насквозь.
Ты не должен предлагать начальнику ничего исправлять, зато другим можно исправлять тебя самого.
Ты не смеешь трогать чужой код, не посмотрев в зеркало. Насмотревшись в зеркало, вспомни пункт 1.
Качество — зло. Паттерны — зло. Архитектура — глупость. Работает — не трогай. В конце концов, Булгария тоже плавала!
Здравствуйте, MxMsk, Вы писали:
MM>Запомни: MM>Качество — зло. Паттерны — зло. Архитектура — глупость. Работает — не трогай. В конце концов, Булгария тоже плавала!
Хочется добавить: да здравствует, мать анархия! MM>Короче, сиди и не выпендривайся.
Не внимательно читаешь, я отвечаю за этот проект, что не ясно?
Здравствуйте, alexsoff, Вы писали:
A>Разве применение паттернов, может превратить мешанину кода в еще большее гОвно,
С легкостью. При этом простое дублирование устраняется рефакторингом на раз, т.е. это рутинная, иногда занимающая много времени, но в общем несложная работа. Код с кучей лишних слоев абстракций (в частности ненужных паттернов) рефакторингу поддается очень плохо. Причем если код с дублированием можно переписывать по частям, то код со слоями лишних паттернов обычно нет. Соответственно плохой код без кучи слоев абстракций и паттернов я всегда предпочту плохому коду с паттернами.
A>неужели ты ставишь мнение таких метров программирования как Фаулер, Эванс,Бэк по структурированию и паттерированию программ в грош?
Паттерны это инструмент. Инструмент можно применить правильно, тогда он упростит код и вхождение в код в том числе. Можно неправильно, тогда код кардинально усложнится.
Здравствуйте, alexsoff, Вы писали:
A>А что я тут не правильно сказал? Человек работающий с этим проектом не знает вообще ООП, не знает про интерфейсы, и уж не очевидно ли что если я ввиду любые ООП конструкции(что как бы подразумевает введение паттернов) это повысит планку для вхождения? обоснуйте свой ответ, а не кидайтесь г*ном сударь.
Очень пугает, то что ты противопоставляешь хорошесть кода и порог вхождения в код. Если при "улучшении" кода порог вхождения увеличивается, то скорей всего вместо улучшения происходит усложнение кода.
Здравствуйте, Undying, Вы писали:
U>Очень пугает, то что ты противопоставляешь хорошесть кода и порог вхождения в код. Если при "улучшении" кода порог вхождения увеличивается, то скорей всего вместо улучшения происходит усложнение кода.
Это очевидно, добавляем слой абстракции — сложность увеличилась, или не? Избавляемся от практики копипаста — сложность увеличилась, т.к. приходится теперь вместо механической работы — думать и понимать как система устроена в целом.
Здравствуйте, Undying, Вы писали: U>Паттерны это инструмент. Инструмент можно применить правильно, тогда он упростит код и вхождение в код в том числе. Можно неправильно, тогда код кардинально усложнится.
Но это не значит, что от него нужно держаться подальше.
A>Избавляемся от практики копипаста — сложность увеличилась, т.к. приходится теперь вместо механической работы — думать и понимать как система устроена в целом.
Вместо _большого количества_ дурацкой однообразной работы по перелопачиванию субстанции — выстроить систему так, чтобы надо было подумать и _немного_ дописать кода.
Вот эту идею надо понять как до руководства донести.
Что в долгосрочной перспективе (дольше чем прощёлкивание одной галочки в трекере задач) это выгоднее.
Здравствуйте, Олег К., Вы писали:
ОК>Судя по желанию всюду пихать паттерны и все переписать у него ее вообще нет.
Ну, я уверен на 100%, что под паттернами подразумевается максимум MVC и работа с базой через пул соединений. Так как сколько не видел сторонников паттернов, у которых они от зубов отскакивают — ни один не применяет их там, где нужно, да и где не нужно тоже — времени не хватает .
E>>Сидеть на такой работе, где говнокод ковырять — это деградация в любом случае. ОК>Такова работа программиста — ковыряться в коде предшественников.
Только код предшественников может быть разным. Иногда у предшественников есть чему поучиться. Но это бывает только в случае, если найм поставлен на основе реального кода, а это большая редкость.
ОК>Ну почему сразу вытягивать? Топикстартер описал обычную рабочую ситуацию.
Когда изначально даж SVN не было ? Сплошной копипаст, все связано со всем через глобальные переменные, код даже не процедурный, а куча вложенных if for switch? Проходили, знаем про такие проекты. Чем больше у конкурентов таких рабочих ситуаций, тем нам лучше, что могу сказать .
