Re[3]: Низкая квалификация работников - О работе

Здравствуйте, alexsoff, Вы писали:
A>Устроился на работу, по функциональным обязанностям должен буду отвечать за разработанные проекты. Но дело в том, что уже до меня был написан проект, разработчик которого, мягко говоря, не был "профи". В коде проекта все слои оказались смешаны, в UI размазана бизнес логика и порой присутствуют такие перлы, что можно только закрыть глаза, например конекшен стринги захардкожены жестко в коде и продублированы по всему приложению — бывает даже случается так, что в одном методе встречается 3-4 места с жестко прописанным конекшен стрингом.

я не уже говорю о копипасте

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

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

V_S>1. Что означает "отвечать" (за разработанные проекты)? Есть ли у тебя достаточные полномочия, какой-никакой бюджет и ресурсы для "отвечания", или же тебя просто-напросто назначили виноватым за все будущие косяки и баги в этом проекте?
Скорее второе.
V_S>Ты должен провести анализ текущего состояния проекта, и прийти к начальству с документом где-то в таком духе: "В подсистеме A вот это сделано так-то и так-то. Это может привести к таким-то косякам и багам в будущем, которые наверняка проявятся у клиента. На исправление требуется столько-то человеко-дней, на тестирование после исправления — столько-то. Приоритетность этого исправления — такая-то." И так далее по всем видимым косякам.... А потом с этим документам — отстаивать свою позицию. Вполне допускаю, что твое начальство либо иначе оценивает значимость этих косяков, либо их приоритетность, либо влияние на бизнес.... — пути начальства ведь неисповедимы, не так ли? Ну, а если после твоей аргументации с тобой согласятся, — тем лучше для тебя, составляй и утверждай план работ и переделывай...
Тут палка о двух концах, в таком виде в котором проект сейчас сможет въехать любой студент, посади его, а через месяц он будет чувствовать себя королем, а я же хочу внедрить паттерны, что несомненно поднимет планку для вхождения. Очевидно, что начальству будет импонировать вариант студента с наименьшими будущими затратами.

Здравствуйте, alexsoff, Вы писали:
A>Здравствуйте, __kot2, Вы писали:
__>>ну а цель-то какая в итоге преследуется? "сделать всем хорошо" или какая-то конкретная?
A>Цель одна: выбрать нужное (переписать все нафиг или надеяться, что разработчик не уйдет)
это не цель. это средство. вы не понимаете, какую цель преследуете. значит, вы неопытный разработчик. значит, от вашего переписывания ни холодно станет, ни жарко. на качество продукта это не повлияет, только займет время, ваше и тестеров и даст новые баги. так бы я размышлял, если бы был вашим начальством

__>>если цель — развитие бизнеса компании, то не трогайте ничего, что уже было оттестировано
A>Да склоняюсь к этому мнению, но боюсь наступление времини Ч, когда что-то будет нужно сделать, а уже поздно

(приложение ориентировано на российское законодательство)
не понял

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

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

A>Да 25, а как это к делу относится?

Некоторые дураки думают, что возраст автоматически делает их умнее

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

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

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

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

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

А вот за паттернофилию можно и канделябром по морде получить

Утомили уже любители пихать паттерны во все щели.

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

A>а я же хочу внедрить паттерны, что несомненно поднимет планку для вхождения

ээ... я начинаю сомневаться что эта тема не троллинг...

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

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

A>Устроился на работу, по функциональным обязанностям должен буду отвечать за разработанные проекты. Но дело в том, что уже до меня был написан проект, разработчик которого, мягко говоря, не был "профи". В коде проекта все слои оказались смешаны, в UI размазана бизнес логика и порой присутствуют такие перлы, что можно только закрыть глаза, например конекшен стринги захардкожены жестко в коде и продублированы по всему приложению — бывает даже случается так, что в одном методе встречается 3-4 места с жестко прописанным конекшен стрингом.

я не уже говорю о копипасте

Здравствуйте, __kot2, Вы писали:
__>это для тебя она станет организованной. а придет новый человек, для него твой код будет свалкой гавна.
я, например, еще не видел ни одного даже суперопытного разработчика, который бы систематически не писал херни по моему мнению. например, один знакомый недавно отколол — memsetом классы инициализировал. и все работало, пока он виртуальные методы не ввел. и че-то сламалася

Здравствуйте, alexsoff, Вы писали:
__>>это не цель. это средство. вы не понимаете, какую цель преследуете. значит, вы неопытный разработчик. значит, от вашего переписывания ни холодно станет, ни жарко. на качество продукта это не повлияет, только займет время, ваше и тестеров и даст новые баги. так бы я размышлял, если бы был вашим начальством
A>Почему именно разработчик, руководитель да "не опытный"? Я знаю как это все переписать нормально. Моей задача — вынести свое мнение начальству.
да потому что идея дурацкая, ничем хорошим не закончится, не говоря уж про незнание того как пишется "не" с прилагательными.

A>>>Да склоняюсь к этому мнению, но боюсь наступление времени Ч, когда что-то будет нужно сделать, а уже поздно

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

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

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

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

Пара-тройка советов:

1. Не говорите сходу начальнику, что ваш предшественник — козел. Либо начальник сам про это знает, но не имеет выбора, либо начальник тоже козел. В любом случае, вас не услышат.
2. Начальство лучше всего понимает, когда ему говорят о проблемах, понятных на его уровне. "Этот код вызывает у меня эстетическую неприязнь" началсьтво не поймет. "Этот код написан так, что любое изменение в нем займет в 10 раз больше времени, чем если бы код был приведен в порядок" звучит гораздо понятмее. Будьте готовы аргументировать свою позицию ("Поскольку в этом коде все связано со всем, любое изменение может сломать все, что угодно. Поэтому каждый раз приходится прогонять все тесты, даже та, которые тестируют области, которые я не трогал. А поскольку система тестирования не автоматизированна, то получается, что я трачу час на, собственно, полезную работу, а потом еще 2 дня на тестирование — поэтому работа идет так медленно".)
3. Подумайте о том, как можно довести до ума этот код эволюционно, а не революционно. Это меньше пугает народ. Хотя бывают программы, которые эволюционно не исправишь, их надо либо принимать, как есть, либо в топку

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

A>Советую не считать себя самым умным.
Где я писал про чсв? Напротив, спросил совета.

A>Шесть человекомесяцев — это сколько в строках кода?
Данный период был затрачен этим разработчиком на написание кода с нуля. В этом проекте много копипаста — строчки не считал.
A>И сколько тебе лет? Небось 25?
Да 25, а как это к делу относится?

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

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

Очень пугает, то что ты противопоставляешь хорошесть кода и порог вхождения в код. Если при "улучшении" кода порог вхождения увеличивается, то скорей всего вместо улучшения происходит усложнение кода.

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

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

MM>Неопытный забил бы на всех давно. Человек совета пришел спросить, а ему вместо этого "в зеркало гляди", да на возраст пеняют.

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

MM>У меня был опыт проекта, в котором участвовал очень своеобразный разработчик. Он намного старше меня и более опытнее, должность тоже была круче. Когда я увидел его код, ужаснулся. Потом решил, может мне опыта не хватает. Потом я тоже приходил на RSDN за подобным советом. Меня выставили таким же дураком, не способным понять всей гениальности затеи... Однако, я тогда смог продавить переписывание модуля. Но то была лишь капля в море. И знаешь что в итоге случилось? Проект не приняли. Ага! Приложение просто не работало нормально, потому что тот опытный разработчик, которого я видите ли не понимал, писал код чертовски хреново. И когда пришло время проверять поделку не в дебаге, а с пользователями, последние офигели от количества недоработок, глупых ошибок и неустоучивости системы. Но я о таком результате говорил с самого появления на проекте. Но! Менеджер взвесил риски и решил не исправлять. Советчики с RSDN тоже подумали, что я шибко молод. И вот вам красноречивый итог.

Заметьте — вы снова вините во всем кого угодно, только не себя. Вы ни на минуту не задумались, на кой ляд вы "продавили переписыывание модуля" вместо банального исправления ошибок и рефакторинга строго по месту (где требуется, а не где хочется оставить свой след). Виноваты все вокруг, кому вы рассказывали о том, какая плохая у вас система.

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

Здравствуйте, alexsoff, Вы писали:
__>>да потому что идея дурацкая, ничем хорошим не закончится
A>Какая идея? переписать или оставить все как есть?
переписать

__>>это для тебя она станет организованной. а придет новый человек, для него твой код будет свалкой гавна. любому человеку именно его стиль кажется самым правильным среди всех.
__>>ты понимаешь, что все, что ты наменяешь, нужно будет заново перетестировать? стоимость этого учитываешь? или ты собрался сразу идеальный код писать? ты уверен, что знаешь как сделать лучше? а насколько лучше? а оно того стоит?
A>Разве применение паттернов, может превратить мешанину кода в еще большее гОвно, неужели ты ставишь мнение таких метров программирования как Фаулер, Эванс,Бэк по структурированию и паттерированию программ в грош?
может. самое важное для меня открытие, постигшее меня где-то после 8 лет разработки это то, что от человеческих усилий проекты часто становятся хуже. люди работают, стараются, улучшают, а они все хуже, хуже и хуже. каждая новая версия — геморрой, новые глюки и тормоза. есть одна известная тут всем компания, которая делают одну sdk, которую мы используем в проектам. так вот эта sdk где-то год назад стала только портиться версия от версии нифига нового нужного, зато стабильно изменения поведения, новые косяки, старые нифига не правятся, приходится только больше воркэраундов писать. то есть компания просто портит ее. и есть множество продуктов, которые компания просто портит своей деятельностью. и ты с больше долей вероятности хочешь этим заняться

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

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

__>да потому что идея дурацкая, ничем хорошим не закончится
Какая идея? переписать или оставить все как есть?

__>это для тебя она станет организованной. а придет новый человек, для него твой код будет свалкой гавна. любому человеку именно его стиль кажется самым правильным среди всех.
__>ты понимаешь, что все, что ты наменяешь, нужно будет заново перетестировать? стоимость этого учитываешь? или ты собрался сразу идеальный код писать? ты уверен, что знаешь как сделать лучше? а насколько лучше? а оно того стоит?
Разве применение паттернов, может превратить мешанину кода в еще большее гОвно, неужели ты ставишь мнение таких метров программирования как Фаулер, Эванс,Бэк по структурированию и паттерированию программ в грош?

__>правильно. выявил, сообщил. занимаешься текущими делами.
От того, что я сообщу будет зависеть чем я буду заниматься далее или клепать новый проект или переписывать существующий.

Устроился на работу, по функциональным обязанностям должен буду отвечать за разработанные проекты. Но дело в том, что уже до меня был написан проект, разработчик которого, мягко говоря, не был "профи". В коде проекта все слои оказались смешаны, в UI размазана бизнес логика и порой присутствуют такие перлы, что можно только закрыть глаза, например конекшен стринги захардкожены жестко в коде и продублированы по всему приложению — бывает даже случается так, что в одном методе встречается 3-4 места с жестко прописанным конекшен стрингом.

я не уже говорю о копипасте

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

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

A>>Советую не считать себя самым умным.
A>Где я писал про чсв? Напротив, спросил совета.

Ну я тебе сказал, что НЕ надо делать.
По моему мнению.

A>>Шесть человекомесяцев — это сколько в строках кода?
A>Данный период был затрачен этим разработчиком на написание кода с нуля. В этом проекте много копипаста — строчки не считал.

Понимаешь... Если программа достаточно маленькая (один мегабайт кода) — то все равно в каком стиле она написана.
Её можно заставить работать просто грубой силой.

A>>И сколько тебе лет? Небось 25?
A>Да 25, а как это к делу относится?

Во первых тащись от того, какой я умный.

Ведь я тебя не видел и сразу угадал.

В этом возрасте все (и я в том числе) считают себя самыми умными.
Потом это проходит. А еще потом (если не бросить учиться) действительно становишься умным.

Программы можно писать в разных стилях.
Упорядочивать их вдоль или поперек. Экономить или на одном или на другом.
Если твой предшественник писал в другом стиле — это не значит что его стиль хуже.
Более того — у тебя есть шанс посмотреть в чем его стиль лучше.
А когда поймешь — использовать плюсы и его и своего стиля.

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

Ну и вообще — умение понимать чужие исходники — отдельный скилл.
Имея его ты становишься могуч как титан.
Берешь чужие исходники, немного допиливаешь, может быть слегка перекомпоновываешь
и микроскопическими усилиями получаешь новый продукт.
А совсем умные умеют писать так, чтобы читать легко было

И вообще — марксизм не догма, а руководство к действию (с) Ленин.

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

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

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

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

A>>Разве применение паттернов, может превратить мешанину кода в еще большее гОвно

W>ДА!!!
W>Для применения паттернов еще и меру знать надо, которой не имеет большинство девов.
Паттерны сами собой появляются в процессе шлифовки кода. Сама система паттернов как таковая имеет смысл только для структуризации существующих навыков и знаний разработчика, а не целенаправленного "внедрения паттернов".

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

A>Устроился на работу, по функциональным обязанностям должен буду отвечать за разработанные проекты. Но дело в том, что уже до меня был написан проект, разработчик которого, мягко говоря, не был "профи". В коде проекта все слои оказались смешаны, в UI размазана бизнес логика и порой присутствуют такие перлы, что можно только закрыть глаза, например конекшен стринги захардкожены жестко в коде и продублированы по всему приложению — бывает даже случается так, что в одном методе встречается 3-4 места с жестко прописанным конекшен стрингом.

я не уже говорю о копипасте

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

K>Некоторые дураки думают, что возраст автоматически делает их умнее

Это назвается опыт — подрастешь — узнаешь

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

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

Товарищ Маузер, очевидно Вы не в полной мере осознвёте все последствия использования глобальных переменных. Размер программы тут не при чём. А вот портабельность кода убивается на раз — на некоторых платформах глобальность, а порой и синглтоны, технологически недопустимы. Пример — android. И пожалуйста, поосторожнее с поучениями молодёжи.

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

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

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

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

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

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

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

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

Здравствуйте, nen777w, Вы писали:
N>гм... а я так делаю, ну только не публично конечно, но есть у меня товарищь с паралельного проэекта вот я ему для поржать кусочки сплавляю,
N>правда без указания афтора.
N>ну и это не говнокод типа забыли чего то там проинициализировать, удалить память и т.п. а реальный говнокод от которого просто убежать и спрятаться хочется

N>я плохо поступаю да? разве другие так не делают

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

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

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

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

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

ОК>С этого проекта ты "свалил достаточно быстро."
Угу, и не жалею. Так как не работал в пустую, когда через год мне б сказали, что уже не надо. А тот мегапроект, кстати, к мелким относился, там всего мегабайт кода (если писать нормально и выдрать копипаст, то вообще килобайт 100 было б). Который запрещено нормально форматировать (форматирование лесенкой — машанина табов и пробелов), а тем более рефакторить. Я как то комсомольцем, который не может без трудностей, не являюсь. Как и не очень мне нравится, когда мою работу явно саботируют, вставляя палки в колеса. Лично мне не пофиг за что получать деньги. И если деньги платят, а я сам не понимаю нахрена, когда туж работу можно было в 10 раз быстрее выполнить, а так даж работа удовольствия не приносит постоянными маразмами — к черту эту работу. Все проекты дерьмо, везде говнокод — это тож самое, что говорить, что все бабы — меркантильные сучки. Не все, надо искать просто лучше. Да, сложнее найти работу мне в результате, признаю — зато когда нахожу, я ей оказываюсь доволен, и это тоже многого стоит.

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

A>Устроился на работу, по функциональным обязанностям должен буду отвечать за разработанные проекты. Но дело в том, что уже до меня был написан проект, разработчик которого, мягко говоря, не был "профи". В коде проекта все слои оказались смешаны, в UI размазана бизнес логика и порой присутствуют такие перлы, что можно только закрыть глаза, например конекшен стринги захардкожены жестко в коде и продублированы по всему приложению — бывает даже случается так, что в одном методе встречается 3-4 места с жестко прописанным конекшен стрингом.

я не уже говорю о копипасте

ОК>>У топикстартера не менее гениальное видение кода. Здесь.
A>А что я тут не правильно сказал? Человек работающий с этим проектом не знает вообще ООП, не знает про интерфейсы, и уж не очевидно ли что если я ввиду любые ООП конструкции(что как бы подразумевает введение паттернов) это повысит планку для вхождения? обоснуйте свой ответ, а не кидайтесь г*ном сударь.

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

Г...ном и не думал кидаться. Извини если что.

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

A>Программы можно писать в разных стилях.
A>Упорядочивать их вдоль или поперек. Экономить или на одном или на другом.
A>Если твой предшественник писал в другом стиле — это не значит что его стиль хуже.
A>Более того — у тебя есть шанс посмотреть в чем его стиль лучше.
A>А когда поймешь — использовать плюсы и его и своего стиля.

кроме "разных стилей" есть хороший код и плохой код.
код в котором не соблюден DRY это плохой код. точка.

это не "стиль", это непрофессионализм — лень, непонимание проблем своего кода, неуважение к коллегам которые будут работать с кодом после тебя.

"держать 1 Мб кода в голове" это вопиющий непрофессионализм. ОК, Вы держите этот код в голове. Завтра придет другой человек, ему дадут этот код и скажут добавить такие-то и такие-то фичи, срок неделя. Он успеет запомнить что вы там накопипастили, какой юнит от какого зависит?
Считаете что с вашим кодом всегда будете работать только вы? Отлично. Пишите как хотите, только другим советы не давайте.

A>А я использую голбальные переменные
а автоматические тесты используете? покрытие больше 90%?

>В коде проекта все слои оказались смешаны, в UI размазана бизнес логика
и
>в таком виде в котором проект сейчас сможет въехать любой студент
Нет ли здесь противоречия? Неопытные студенты с ходу проникают в логику стихийных бесформенных макаронных хитросплетений, но при этом им "не хватает квалификации" постигнуть код структурированный и разнесённый по слоям?

A>Я не писал, о том, что мне трудно "наращивать функционал", но мне не приятно будет заниматься копипастом
Нет, такая аргументация вообще не годится. Читает нас какой-нибудь "начайник", и думает: Ага, опытные становятся разборчивыми, и вместо того чтобы пахать как велят — начинают кочевряжиться "это мне приятно, это неприятно". Значит, надо всячески препятствовать развитию в опытных, мешать "внедрять паттерны", и вообще отдавать таких под командование студентов. Только визуал бейсик и ~~быдло~~код, который пройдёт утверждение Главного Студента!

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

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

У топикстартера не менее гениальное видение кода. Здесь.

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

A>Разве применение паттернов, может превратить мешанину кода в еще большее гОвно,

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

A>неужели ты ставишь мнение таких метров программирования как Фаулер, Эванс,Бэк по структурированию и паттерированию программ в грош?

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

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

MM>>Короче, сиди и не выпендривайся.
A>Не внимательно читаешь, я отвечаю за этот проект, что не ясно?
Это был стёб. Мне то как раз ясно, что ты хочешь сделать хорошо. Меня удивляет, что находятся товарищи, считающие, что вместо советов, лучше тебя опустить и выставить неопытным бестолочем.

MM>>>Короче, сиди и не выпендривайся.
A>>Не внимательно читаешь, я отвечаю за этот проект, что не ясно?
MM>Это был стёб. Мне то как раз ясно, что ты хочешь сделать хорошо. Меня удивляет, что находятся товарищи, считающие, что вместо советов, лучше тебя опустить и выставить неопытным бестолочем.

Никто его не опускает и он таки неопытный. Ты только подумай. Топикстартер хочет с нуля переписать проект в который уже вложены деньги. О каком опыте тут может быть речь?

Ладно этот проект маленький. А что бы он делал с проектом который существенно больше и дольше находится в продакшне?

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

Я видел компании, где далеко не суперкод работал годами (явно больше 4х лет), при том что рынок был более-или-менее конкурентным.

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

Пропал проект...

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

A>А что я тут не правильно сказал?
То, что код, который с втоей точки зрения "лучше", для поддержки сложнее, чем имеющийся...

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

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

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

Ну и вообще, обычно, чем код ЛУЧШЕ, тем он ПРОЩЕ. Проще, а не сожнее. И въехать проще, а не сожнее и т. д...

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

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

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

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

K>Чего-чего?

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

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

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

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

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

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

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

Здравствуйте, Abyx, Вы писали:
A>тут есть какие-то плюсы стиля?
это стиль. если у него убрать венгерскую нотацию, дефайны большими буквами обьявлять, чтобы не спутать с дефайнами ф-ий, не сокращать BinaryResource до BinRes, и убрать второй public, то получится примерно как я пишу.

Здравствуйте, Ulin, Вы писали:
U>То есть нечто, больше относящееся к форматированию. Имена классов типа "BinRes", "a", "b", "ptr" и тп. это в моем понимании просто кривой код, подлежащий рефакторингу.
рефакторинг это пустая трата времени. это лишь адаптация одного стиля под другой. если программа работает, значит она выполняет свои ф-ии и не надо в нее лезть своими ручками. если настолько кривая, что не работает, то ее и не существует.

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

>>>/** Creates an RTCPCompoundPacket instance from the data in \c rawpack, installing a memory manager if specified. */
__>куски кода с такими комментами неудобно комментить — они всегда рождают дополнительные маты при портировании и отладке, так как обычно при портировании ничего сразу не собирается, надо это делать частями потихоньку

откройте для себя #if 0

>>>RTCPCompoundPacket(uint8_t *packet, size_t len, bool deletedata = true, RTPMemoryManager *memmgr = 0);
__>так это С++ или С? почему packed голым указателем? почему указатель = 0? хотя бы NULL нужно писать
__>составные имена переменных стоило бы для лучшей читабельности разделять подчеркиваниями deletedata -> delete_data

да, в C++ используются raw non-owning указатели

>>> int GetCreationError() { return error; }
__>о, ужас, они про исключения слышали?
__>получается, можно создать класс имеющий невалидное состоние. зачем? это очень неудобно

исключения могут быть запрещены в требованиях к проекту, такое бывает.

>>> /** Starts the iteration over the individual RTCP packets in the RTCP compound packet. */
>>> void GotoFirstPacket() { rtcppackit = rtcppacklist.begin(); }
>>> RTCPPacket *GetNextPacket() { if (rtcppackit == rtcppacklist.end()) return 0; RTCPPacket *p = *rtcppackit; rtcppackit++; return p; }

__>сделали свой интерфейс для итератора. а зачем?

итератор и "итератор STL" это разные вещи.

>>> size_t GetCompoundPacketLength() { return compoundpacketlength; }
__>почему метод неконстантный?

потому что он завтра он будет менять члены класса

>>> void ClearPacketList(); — этот метод вообще не нужен, если сделать контейнер не std::list<RTCPPacket *>, а std::list<SmartPtr<RTCPPacket> >

SmartPtr — это какой? shared_ptr? так он тяжелый и время жизни объекта будет недетерминированное

>>>#ifdef RTPDEBUG
>>> void Dump();
>>>#endif // RTPDEBUG <- коммент для дебилов?

так в coding style guide написано

>>>std::list<RTCPPacket *>::const_iterator
__>слабо было обявить сразу typedef'ом, чтобы по 100 раз не писать std::list<RTCPPacket *> ?

а что, сложно читать?

__>переходим на С++ файл
>>>RTCPCompoundPacket::RTCPCompoundPacket(RTPRawPacket &rawpack, RTPMemoryManager *mgr) : RTPMemoryObject(mgr)
>>>{
>>> compoundpacket = 0;
>>> compoundpacketlength = 0;
>>> error = 0;
__>народу бы почитать про списки инициализации

вопрос вкуса, в данном случае список инициализации ничего не поменял бы

>>> error = ParseData(data,datalen);
>>> if (error < 0)
>>> return;
__>суперработа с исключительными ситуациями

__> rawpack.ZeroData();
__>он в конструкторе изменяет состояние передаваемого обьекта?????

ну и что? rawpack.GetData() тоже могло бы менять состояние rawpack

>>> compoundpacket = packet;
>>> compoundpacketlength = packetlen;
>>> deletepacket = deletedata;
__>такие повторяющиеся блоки иногда имеет смысл выделить в структурку. вообще, там три конструктора с дублированием инициализации этой структурки. если кто-нить добавить туда еще что-то, то надо будет не забыть подписать инициализацию о всех конструкторах — неудобно

не критично

>>> switch (rtcphdr->packettype)
>>> {
>>> case RTP_RTCPTYPE_SR:
>>> p = RTPNew(GetMemoryManager(),RTPMEM_TYPE_CLASS_RTCPSRPACKET) RTCPSRPacket(data,length);
>>> break;
>>> case RTP_RTCPTYPE_RR:
>>> p = RTPNew(GetMemoryManager(),RTPMEM_TYPE_CLASS_RTCPRRPACKET) RTCPRRPacket(data,length);
>>> .........
__>это стоило бы выделить в отдельный метод

+1

__>+ по дурацки построена работа с менеджером памяти. что-то мне подсказывает что в С++ его не нужно тащить в каждый класс
__>даже простое удаление жутко выглядит
>>> RTPDelete(*it,GetMemoryManager());
__>вот забудешь так, удалишь как обычный обьект — и никто ведь не предупредит даже! или выделишь просто через new. потенциальное море граблей.

delete statement должен быть запрещен вне библиотек, по coding style guide

__>вывод — код — полное гавно. но оно (скорее всего) рабочее! а, значит, код годный и все замечательно. ну писал его сишник, что ж теперь. главное, чтобы все работало

вывод — вы плохо знаете С++

U>Как тебе такой код? Тоже ведь работает. Зачем его рефакторить? Такой миленький кодик...

Если вы планируете прямо сейчас что-то расширять с загрузкой иконок, не вижу сложностей зарефакторить код. Если не планируете — зачем вообще в этот код лезть?
Код, на самом деле, очень простой, его даже вчерашний студент поймет. А вот если вы это перепишете, скажем, с использованием напрашивающейся Factory, читать станет резко сложнее, понимать — тоже.
А вообще, без контекста непонятно, зачем и кому был нужен такой код. Почему такая сложная загрузка иконок — вот с чем надо разобраться. Требования к коду неясны, поэтому неизвестно, можно ли зарефакторить его так, чтобы он стал сильно лучше.

"Плохой код — результат плохо продуманных требований!" (разрешаю цитировать без упоминания моего авторства

)

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

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

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

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

Posted via RSDN NNTP Server 2.1 beta

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

K>Некоторые дураки думают, что возраст автоматически делает их умнее

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

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

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

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

Posted via RSDN NNTP Server 2.1 beta

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

K>Я видел компании, где далеко не суперкод работал годами (явно больше 4х лет), при том что рынок был более-или-менее конкурентным.
Можно подумать я не видел. Взять тот же Лотус Нотес. Плюются все, начиная от пользователей и заканчивая разработчиками, а сидят и продолжают жевать кактус. Ибо бабки уже куча народа потратила, деваться некуда. Признать свои ошибки для тех, кто эту систему покупал, выбирал и внедрял — означает распрощаться с неплохой должностью. Те же Oracle — я представляю какой капец у них творится сейчас в коде, если за такое количество лет не могут сделать, чтоб без плясок с бубнами можно было легко создавать базы. Тривиальная операция — нет, блин, обязательно лезть черти в какой конфиг, который меняется от версии к версии и ручками там прописывать.
Подсадили на себя кучу народа, неплохой маркетинг — и все, если ты начнешь сомневаться в том, что Oracle необходимо пихать абсолютно везде — 9 из 10 высокопоставленных менеджеров посчитают тебя некомпетентным. Ибо любой студент знает, что Oracle — это самая лучшая самая универсальная СУБД на все случаи жизни, которая решит абсолютно все проблемы, а кто в этом сомневается — тот недоучка. А Лотус — самая лучшая и самая удобная и безглючная система документооборота. Даже для базы с пятью таблицами и десятью тысячами записей абсолютно необходимо ставить самую дорогую версию Oracle!
Инерция, блин.

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

__>вы видели когда-нить ассемблерный код, который генерирует компилятор? там же вообще месиво. самый суперговнокод лучше и понятнее, чем то, что генерирует и исполняет процессор в конечном итоге.

Ты не понимаешь разницы между продуктом работы компилятора и исходным кодом?

A>Как я уже сказал, последствия могут быть одни — если этот разработчик уйдет, то я буду поддерживать данный проект.
срок жизни российского разработчика как у танка на поле боя, в топку код
p.s.
пример из жизни, работали с легаси кодом, я оценил в 7 месяцев переписывание целиком, сказали нельзя, четыре месяца писали к нему фичу, через 4 месяца выяснилось что неправильно поняли как что устроено и пришлось все выбросить, а кода то всего 75 000 строк

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

A>Устроился на работу, по функциональным обязанностям должен буду отвечать за разработанные проекты. Но дело в том, что уже до меня был написан проект, разработчик которого, мягко говоря, не был "профи".
Для российских программистов любой, написанный не ими код, обладает фатальным недостатком — код написан не ими

Если серьезно, код уж сильно не нравится, но аффтор рядом, займитесь потихоньку рефакторингом, делов-то.

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

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

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

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

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

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

A>>Понимаешь... Если программа достаточно маленькая (один мегабайт кода) — то все равно в каком стиле она написана.
A>>Её можно заставить работать просто грубой силой.
A>Эта программа постоянно расширяется, так чтобы ее расширить приходится править код по всему проекту. Помнишь анек про обезьяну и банан: "да, что тут думать — трясти надо"?

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

A>>Во первых тащись от того, какой я умный.

Ведь я тебя не видел и сразу угадал.

A>Да ладно, граватар тоже не заметил?

Не-а.

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

Ну вот, уже понимаешь, что любое утверждение не догма.

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

Нуу... это у тебя предрассудки. Дороже не значит лучше. Не только к программированию относится.

Да и вообще — 90% приходится использовать компоненты соседа Васи.
Ну жизнь так устроена.

В программистских конторах.

A>Разве применение паттернов, может превратить мешанину кода в еще большее гОвно,

Да, может. Особенно если паттерны бездумно применяются свеженьким выпускником ВУЗа, годков так 22-26. Как раз ваш случай.

A>неужели ты ставишь мнение таких метров программирования как Фаулер, Эванс,Бэк по структурированию и паттерированию программ в грош?

Любым инструментом можно сделать хорошо. Скажем, скальпелем. А можно и убить пациента вконец. Так же и запиливание паттернов поверх спагетти-кода может кого угодно убить.

A>От того, что я сообщу будет зависеть чем я буду заниматься далее или клепать новый проект или переписывать существующий.

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

Pzz>2. Начальство лучше всего понимает, когда ему говорят о проблемах, понятных на его уровне. "Этот код вызывает у меня эстетическую неприязнь" началсьтво не поймет. "Этот код написан так, что любое изменение в нем займет в 10 раз больше времени, чем если бы код был приведен в порядок" звучит гораздо понятмее.

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

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

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

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

SD>>Да, может. Особенно если паттерны бездумно применяются свеженьким выпускником ВУЗа, годков так 22-26. Как раз ваш случай.
A>Вот не нужно делать таких выводов вы мой бекграунд не знаете.
Ты не путай! Это ты не имеешь права оценивать других, а вот другим оценивать тебя можно

Запомни:

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

Качество — зло. Паттерны — зло. Архитектура — глупость. Работает — не трогай. В конце концов, Булгария тоже плавала!

Короче, сиди и не выпендривайся.

K>>>Рефакторить или отказаться с этим работать, других вариантов для уважающего себя профи просто нет

ОК>>Виден совет непрофессионала. Код которому 10-20-30 лет и который писала куча людей которые больше не работают в компании ты тоже начнешь сразу переписывать или отказываться с ним работать?

K>Точно, как это я не сообразил. Настоящие "профи" код никогда не рефакторят

K>Я всегда переписываю код, который крив. Неважно кто его писал и когда.

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

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

У тебя как-то все очень легко получается. И время на все есть. И на форум тоже есть. Меня терзают смутные сомнения.

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

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

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

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

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

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

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

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

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

ОК>Ладно этот проект маленький. А что бы он делал с проектом который существенно больше и дольше находится в продакшне?
У меня был опыт проекта, в котором участвовал очень своеобразный разработчик. Он намного старше меня и более опытнее, должность тоже была круче. Когда я увидел его код, ужаснулся. Потом решил, может мне опыта не хватает. Потом я тоже приходил на RSDN за подобным советом. Меня выставили таким же дураком, не способным понять всей гениальности затеи... Однако, я тогда смог продавить переписывание модуля. Но то была лишь капля в море. И знаешь что в итоге случилось? Проект не приняли. Ага! Приложение просто не работало нормально, потому что тот опытный разработчик, которого я видите ли не понимал, писал код чертовски хреново. И когда пришло время проверять поделку не в дебаге, а с пользователями, последние офигели от количества недоработок, глупых ошибок и неустоучивости системы. Но я о таком результате говорил с самого появления на проекте. Но! Менеджер взвесил риски и решил не исправлять. Советчики с RSDN тоже подумали, что я шибко молод. И вот вам красноречивый итог.

> но тут возникает вопрос, не быстрее ли выкинуть код и переписать с нуля?

Переписать с кучей паттернов, с кучей исключений, держащися только на 90% покрытии тестами и гарантированно не работающим за пределами оных, поскольку ты под дебагером стараешься на код не смотреть.
Ну что я тут могу сказать, вперед и с песней! Гарантия, что следующий после тебя программист поднимет такую же ветку, каких тут уже сотни.

Posted via RSDN NNTP Server 2.1 beta

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

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

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

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

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

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

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

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

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

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

A>>А ты уверен, что туда надо тащить DI и покрывать тестами?
A>Ну вот на форуме дают советы не использовать юнит тесты.

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

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

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

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

В большинстве случаев разработка софтвария ближе к марафону, чем к стометровке. Никто не планирует написание программы с максимальной скоростью с целью ее выбросить через месяц и начать все заново. Даже пресловутая идея сначала написать прототип, а потом нормальную программу, в среднем кончается одним из двух: либо прототип объявляется нормальной программой и доводится до ума (а не переписывается), либо все списывается в утиль и проект закрывается. Стоимость развития и поддержки имеет значение, даже если вы не можете знать наверняка, взлетит ваш проект или нет.

SD>Потому как, еще раз объясняю, ресурсы, которые вы сегодня потратили на рефакторинг, конкуренты потратили на улучшение, например, юзабилити — и завтра их продукт покупают, а ваш — нет. И весь ваш рефаторинг оказался ненужным, потому что никто его так и не увидел.

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

Так что содержание кода в порядке и юзабилитя — совершенно ортогональные вещи.

K>>Я видел компании, где далеко не суперкод работал годами (явно больше 4х лет), при том что рынок был более-или-менее конкурентным.
E>Можно подумать я не видел. Взять тот же Лотус Нотес. Плюются все, начиная от пользователей и заканчивая разработчиками, а сидят и продолжают жевать кактус. Ибо бабки уже куча народа потратила, деваться некуда. Признать свои ошибки для тех, кто эту систему покупал, выбирал и внедрял — означает распрощаться с неплохой должностью. Те же Oracle — я представляю какой капец у них творится сейчас в коде, если за такое количество лет не могут сделать, чтоб без плясок с бубнами можно было легко создавать базы. Тривиальная операция — нет, блин, обязательно лезть черти в какой конфиг, который меняется от версии к версии и ручками там прописывать.
E>Подсадили на себя кучу народа, неплохой маркетинг — и все, если ты начнешь сомневаться в том, что Oracle необходимо пихать абсолютно везде — 9 из 10 высокопоставленных менеджеров посчитают тебя некомпетентным. Ибо любой студент знает, что Oracle — это самая лучшая самая универсальная СУБД на все случаи жизни, которая решит абсолютно все проблемы, а кто в этом сомневается — тот недоучка. А Лотус — самая лучшая и самая удобная и безглючная система документооборота. Даже для базы с пятью таблицами и десятью тысячами записей абсолютно необходимо ставить самую дорогую версию Oracle!
E>Инерция, блин.

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

SD>>PS: справедливости ради, у меня был аналогичный опыт. Правда, ничего никому переписывать не дозволили, так, поковырялись совочком в какашках, сверху натянули блестящую обертку и так прямо и продавали. Вроде ничего, жалобы были, решались в рабочем порядке.
MM>Справедливости ради, ты не можешь знать, был ли у тебя аналогичный опыт. Если уж так хочется мериться, я участвовал в семи проектах, шесть из которых были внедрены. Четыре проекта имели гораздо более многолетнюю историю развития до моего прихода, в отличии от заваленного. Почему на этих четырех проектах мне не стреляло переписывать подсистемы, а только частичный рефакторинг?

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

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

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

K>Тогда так ли очевидны проблемы от якобы плохого кода?

Конечно очевидны, баттхерт называется

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

A>Разве применение паттернов, может превратить мешанину кода в еще большее гОвно

ДА!!!
Для применения паттернов еще и меру знать надо, которой не имеет большинство девов.

Pzz>В большинстве случаев разработка софтвария ближе к марафону, чем к стометровке.

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

Pzz>Ну вообще-то, юзабилитей должны заниматься какие-то совсем другие люди, не программисты. Юзабилитя — это не кодирование формочек, а придумывание, что в этих формочках должно быть нарисовано.

Ого! Впервые встречаю такую юзабилити, которую просто придумали — и бац, она уже есть, и программистам не надо "кодировать формочки"

На моей памяти, именно юзабилистские заморочки (особенно на вебе) выносили мозги программистам

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

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

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

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

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

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

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

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

А это обычно не важно

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

Так что оцнивать стоит не только стоимости но и риски.

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

И смотреть как и что можно поменять и как и что в этой системе искать. Если найдёшь, что что-то менять/искать трудно, то там и чини, только сначала тестами покрой...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, alzt, Вы писали:
A>Я скажу за себя. Помню как-то прочитал книжку по шаблонам, хорошую книжку (сине-оранжевую

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

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

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

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

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

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

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

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

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

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

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

SD>Ого! Впервые встречаю такую юзабилити, которую просто придумали — и бац, она уже есть, и программистам не надо "кодировать формочки"

На моей памяти, именно юзабилистские заморочки (особенно на вебе) выносили мозги программистам

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

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

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

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

Чего вы на ТС гоните? Он уже принял верное решение обойтись без революций. Это очень хороший признак, IMHO...

A>скажите, вот это — стиль?

Да, стиль. Что именно вас возмущает в приведенном кусочке кода?

Здравствуйте, Ulin, Вы писали:
U>Ну вот, например, вполне ровный, на мой взгляд, код из либы JRTPLIB (http://research.edm.uhasselt.be/~jori/page/index.php?n=CS.Jrtplib):
пример, конечно, мал, я бы хотел некую реализацию какого-то класса,
поэтому давайте возьму лучше rtcpcompoundpacket
начнем с rtcpcompoundpacket.h

>>/** Creates an RTCPCompoundPacket instance from the data in \c rawpack, installing a memory manager if specified. */
куски кода с такими комментами неудобно комментить — они всегда рождают дополнительные маты при портировании и отладке, так как обычно при портировании ничего сразу не собирается, надо это делать частями потихоньку

>>RTCPCompoundPacket(uint8_t *packet, size_t len, bool deletedata = true, RTPMemoryManager *memmgr = 0);
так это С++ или С? почему packed голым указателем? почему указатель = 0? хотя бы NULL нужно писать
составные имена переменных стоило бы для лучшей читабельности разделять подчеркиваниями deletedata -> delete_data

>> int GetCreationError() { return error; }
о, ужас, они про исключения слышали?
получается, можно создать класс имеющий невалидное состоние. зачем? это очень неудобно

что это за паскалевское именование?

>> /** Starts the iteration over the individual RTCP packets in the RTCP compound packet. */
>> void GotoFirstPacket() { rtcppackit = rtcppacklist.begin(); }
>> RTCPPacket *GetNextPacket() { if (rtcppackit == rtcppacklist.end()) return 0; RTCPPacket *p = *rtcppackit; rtcppackit++; return p; }

сделали свой интерфейс для итератора. а зачем?

>> size_t GetCompoundPacketLength() { return compoundpacketlength; }
почему метод неконстантный?

>> void ClearPacketList(); — этот метод вообще не нужен, если сделать контейнер не std::list<RTCPPacket *>, а std::list<SmartPtr<RTCPPacket> >

судя по коду реализации RTCPCompoundPacket можно было бы сделать константным классом — он инициализируется данными в конструкторе и всегда остается неизменным. везде забыты константные идентификаторы, соотв-но вместо GotoFirstPacket(), GetNextPacket() можно было просто выдавать константный референс на контейнер

>>#ifdef RTPDEBUG
>> void Dump();
>>#endif // RTPDEBUG <- коммент для дебилов?

>>std::list<RTCPPacket *>::const_iterator
слабо было обявить сразу typedef'ом, чтобы по 100 раз не писать std::list<RTCPPacket *> ?

переходим на С++ файл
>>RTCPCompoundPacket::RTCPCompoundPacket(RTPRawPacket &rawpack, RTPMemoryManager *mgr) : RTPMemoryObject(mgr)
>>{
>> compoundpacket = 0;
>> compoundpacketlength = 0;
>> error = 0;
народу бы почитать про списки инициализации

>> error = ParseData(data,datalen);
>> if (error < 0)
>> return;
суперработа с исключительными ситуациями

rawpack.ZeroData();
он в конструкторе изменяет состояние передаваемого обьекта?????

>> compoundpacket = packet;
>> compoundpacketlength = packetlen;
>> deletepacket = deletedata;
такие повторяющиеся блоки иногда имеет смысл выделить в структурку. вообще, там три конструктора с дублированием инициализации этой структурки. если кто-нить добавить туда еще что-то, то надо будет не забыть подписать инициализацию о всех конструкторах — неудобно

>> switch (rtcphdr->packettype)
>> {
>> case RTP_RTCPTYPE_SR:
>> p = RTPNew(GetMemoryManager(),RTPMEM_TYPE_CLASS_RTCPSRPACKET) RTCPSRPacket(data,length);
>> break;
>> case RTP_RTCPTYPE_RR:
>> p = RTPNew(GetMemoryManager(),RTPMEM_TYPE_CLASS_RTCPRRPACKET) RTCPRRPacket(data,length);
>> .........
это стоило бы выделить в отдельный метод

+ по дурацки построена работа с менеджером памяти. что-то мне подсказывает что в С++ его не нужно тащить в каждый класс
даже простое удаление жутко выглядит
>> RTPDelete(*it,GetMemoryManager());
вот забудешь так, удалишь как обычный обьект — и никто ведь не предупредит даже! или выделишь просто через new. потенциальное море граблей.

вывод — код — полное гавно. но оно (скорее всего) рабочее! а, значит, код годный и все замечательно. ну писал его сишник, что ж теперь. главное, чтобы все работало

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

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

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

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

Имея в качестве мотивации усложнение проекта для увеличения порога вхождения можно улучшить проект?

Тут изначально позиция ухудшить проект и за счёт этого стать "незаменимым".

Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, __kot2, Вы писали:
>>>>/** Creates an RTCPCompoundPacket instance from the data in \c rawpack, installing a memory manager if specified. */
__>>куски кода с такими комментами неудобно комментить — они всегда рождают дополнительные маты при портировании и отладке, так как обычно при портировании ничего сразу не собирается, надо это делать частями потихоньку
A>откройте для себя #if 0
вот видите, еще одно мнение. но конкретно с вами бы я работать не стал. во-первых вы слишком пафосны. когда я писал, что такие комменты неудобно комментить, я именно имел в виду, что их неудобно комментить, а не то, что я не знаю, как.

>>>>RTCPCompoundPacket(uint8_t *packet, size_t len, bool deletedata = true, RTPMemoryManager *memmgr = 0);
__>>так это С++ или С? почему packed голым указателем? почему указатель = 0? хотя бы NULL нужно писать
__>>составные имена переменных стоило бы для лучшей читабельности разделять подчеркиваниями deletedata -> delete_data
A>да, в C++ используются raw non-owning указатели
для совместимости с С. если что-то не запрещено, то не значит, что это нужно везде использовать, там где можно грамотнее. вы наверное удивитесь, но ездить задом на машине по дороге тоже не запрещено и вы имеете на это полное право.

>>>> int GetCreationError() { return error; }
__>>о, ужас, они про исключения слышали?
__>>получается, можно создать класс имеющий невалидное состоние. зачем? это очень неудобно
A>исключения могут быть запрещены в требованиях к проекту, такое бывает.
согласен.

>>>> /** Starts the iteration over the individual RTCP packets in the RTCP compound packet. */
>>>> void GotoFirstPacket() { rtcppackit = rtcppacklist.begin(); }
>>>> RTCPPacket *GetNextPacket() { if (rtcppackit == rtcppacklist.end()) return 0; RTCPPacket *p = *rtcppackit; rtcppackit++; return p; }
__>>сделали свой интерфейс для итератора. а зачем?
A>итератор и "итератор STL" это разные вещи.
зачем использовать свой, если есть stl?

>>>> size_t GetCompoundPacketLength() { return compoundpacketlength; }
__>>почему метод неконстантный?
A>потому что он завтра он будет менять члены класса
завтра метод ВзятьДлиннуПакета станет неконстантным?

>>>> void ClearPacketList(); — этот метод вообще не нужен, если сделать контейнер не std::list<RTCPPacket *>, а std::list<SmartPtr<RTCPPacket> >
A>SmartPtr — это какой? shared_ptr? так он тяжелый и время жизни объекта будет недетерминированное
любой смартпойнтер адаптированный под нужды проекта

>>>>std::list<RTCPPacket *>::const_iterator
__>>слабо было обявить сразу typedef'ом, чтобы по 100 раз не писать std::list<RTCPPacket *> ?
A>а что, сложно читать?
писать длинно

__>>переходим на С++ файл
>>>>RTCPCompoundPacket::RTCPCompoundPacket(RTPRawPacket &rawpack, RTPMemoryManager *mgr) : RTPMemoryObject(mgr)
>>>>{
>>>> compoundpacket = 0;
>>>> compoundpacketlength = 0;
>>>> error = 0;
__>>народу бы почитать про списки инициализации
A>вопрос вкуса, в данном случае список инициализации ничего не поменял бы
"вкус" это и есть часть стиля

__>> rawpack.ZeroData();
__>>он в конструкторе изменяет состояние передаваемого обьекта?????
A>ну и что? rawpack.GetData() тоже могло бы менять состояние rawpack
нажатие педали тормоза в машине тоже может включать правый поворотник. но зачем? код должен преследовать принцип минимальной неожиданности. это часть стиля. у вас скорее всего такого принципа нет. я бы с вами в проекте работать не захотел бы.

>>>> compoundpacket = packet;
>>>> compoundpacketlength = packetlen;
>>>> deletepacket = deletedata;
__>>такие повторяющиеся блоки иногда имеет смысл выделить в структурку. вообще, там три конструктора с дублированием инициализации этой структурки. если кто-нить добавить туда еще что-то, то надо будет не забыть подписать инициализацию о всех конструкторах — неудобно
A>не критично
это классическая копипаста. вы говорите, что избегать ее некритично. еще минус вам в желание с вами работать.

__>>+ по дурацки построена работа с менеджером памяти. что-то мне подсказывает что в С++ его не нужно тащить в каждый класс
__>>даже простое удаление жутко выглядит
>>>> RTPDelete(*it,GetMemoryManager());
__>>вот забудешь так, удалишь как обычный обьект — и никто ведь не предупредит даже! или выделишь просто через new. потенциальное море граблей.
A>delete statement должен быть запрещен вне библиотек, по coding style guide
какой-то странный этот coding style guide. он в сбербанке случаем был разработан? надо же голову включать что разумно, а что нет и для каждого проекта его адаптировать.

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

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

>>> Это зависит только от квалификации. Если у вас не получается сделать лучше — ... (ну вы поняли).

G>>А может быть дело в том, что у вас недостаточно квалификации для поддержки и рефакторинга чужого кода? Не кричать "шеф! все пропало!!!", когда копипастинг можно просто спокойно отрефакторить и вынести в отдельный класс?

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

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

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

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

Здравствуйте, raydac, Вы писали:
R>взвесьте последствия для себя
Как я уже сказал, последствия могут быть одни — если этот разработчик уйдет, то я буду поддерживать данный проект.

Здравствуйте, __kot2, Вы писали:
__>ну а цель-то какая в итоге преследуется? "сделать всем хорошо" или какая-то конкретная?
Цель одна: выбрать нужное (переписать все нафиг или надеяться, что разработчик не уйдет)
__>если цель поднять свой уровень — занимайтесь переписыванием
Данный проект не относится к rocket science, да и к тому же я участвовал в создании подобных проектов
__>если цель — развитие бизнеса компании, то не трогайте ничего, что уже было оттестировано
Да склоняюсь к этому мнению, но боюсь наступление времини Ч, когда что-то будет нужно сделать, а уже поздно

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

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

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

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

A>Советую не считать себя самым умным.
Что, вообще нельзя критиковать? Уровень у всех программистов одинаковый?

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

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

A>>Да склоняюсь к этому мнению, но боюсь наступление времени Ч, когда что-то будет нужно сделать, а уже поздно

(приложение ориентировано на российское законодательство)
__>не понял
Разве не очевидно, что стоимость внесение изменений в код без архитектуры дороже, чем в организованный?

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

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

A>Понимаешь... Если программа достаточно маленькая (один мегабайт кода) — то все равно в каком стиле она написана.
A>Её можно заставить работать просто грубой силой.
Эта программа постоянно расширяется, так чтобы ее расширить приходится править код по всему проекту. Помнишь анек про обезьяну и банан: "да, что тут думать — трясти надо"?

A>Во первых тащись от того, какой я умный.

Ведь я тебя не видел и сразу угадал.

Да ладно, граватар тоже не заметил?

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

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

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

AS>Если серьезно, код уж сильно не нравится, но аффтор рядом, займитесь потихоньку рефакторингом, делов-то.
А у этого "аффтора" сейчас нет времени, т.к. он занят постоянной правкой кода в разных местах и другими делами.

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

Pzz>1. Не говорите сходу начальнику, что ваш предшественник — козел. Либо начальник сам про это знает, но не имеет выбора, либо начальник тоже козел. В любом случае, вас не услышат.
Зачем сразу так категорично? предшественник ведь не со зла так написал, а от того, что нет соответствующей квалификации.
Pzz>2. Начальство лучше всего понимает, когда ему говорят о проблемах, понятных на его уровне. "Этот код вызывает у меня эстетическую неприязнь" началсьтво не поймет. "Этот код написан так, что любое изменение в нем займет в 10 раз больше времени, чем если бы код был приведен в порядок" звучит гораздо понятмее. Будьте готовы аргументировать свою позицию ("Поскольку в этом коде все связано со всем, любое изменение может сломать все, что угодно. Поэтому каждый раз приходится прогонять все тесты, даже та, которые тестируют области, которые я не трогал. А поскольку система тестирования не автоматизированна, то получается, что я трачу час на, собственно, полезную работу, а потом еще 2 дня на тестирование — поэтому работа идет так медленно".)
Да нет тестов, код выносится сразу на продакшен или там правится, недавно заставил перейти на svn

Pzz>3. Подумайте о том, как можно довести до ума этот код эволюционно, а не революционно.
угу

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

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

1. Что означает "отвечать" (за разработанные проекты)? Есть ли у тебя достаточные полномочия, какой-никакой бюджет и ресурсы для "отвечания", или же тебя просто-напросто назначили виноватым за все будущие косяки и баги в этом проекте?
2. Если ты просто придешь к начальству с супер-пупер-предложением "А давайте перепишем весь проект нафиг! Все прежние разработчики дураки, я один — д'Артаньян и весь в белом!" — тебя не поддержат, и это правильно.
Ты должен провести анализ текущего состояния проекта, и прийти к начальству с документом где-то в таком духе: "В подсистеме A вот это сделано так-то и так-то. Это может привести к таким-то косякам и багам в будущем, которые наверняка проявятся у клиента. На исправление требуется столько-то человеко-дней, на тестирование после исправления — столько-то. Приоритетность этого исправления — такая-то." И так далее по всем видимым косякам.... А потом с этим документам — отстаивать свою позицию. Вполне допускаю, что твое начальство либо иначе оценивает значимость этих косяков, либо их приоритетность, либо влияние на бизнес.... — пути начальства ведь неисповедимы, не так ли? Ну, а если после твоей аргументации с тобой согласятся, — тем лучше для тебя, составляй и утверждай план работ и переделывай...

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

A>.... а я же хочу внедрить паттерны, что несомненно поднимет планку для вхождения. Очевидно, что начальству будет импонировать вариант студента с наименьшими будущими затратами.

Задай себе простой вопрос (а самое главное — честно на него себе же ответь!): для бизнеса действительно так уж нужны всякие там "паттерны" в коде, или же и без них все как-то сложится?

Если нет — я (пока) вполне солидарен с твоим начальством: "паттерны" не несут никаких прибылей для бизнеса, а сулят одни только убытки.

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

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

A> Очевидно, что начальству будет импонировать вариант студента с наименьшими будущими затратами.

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

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

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

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

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

L>Начальству в моем понимании нужен работающий продукт, его не интересует, как вы этого добьетесь
Работающий продукт — это часть понятия "как вы этого добьётесь", и обычно тоже не интересует.

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

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

Pzz>>1. Не говорите сходу начальнику, что ваш предшественник — козел. Либо начальник сам про это знает, но не имеет выбора, либо начальник тоже козел. В любом случае, вас не услышат.
A>Зачем сразу так категорично? предшественник ведь не со зла так написал, а от того, что нет соответствующей квалификации.

Вот это и не надо никому говорить. Вообще, не надо говорить про людей, квалифицированные они или нет, говорите про код.

A>Да нет тестов, код выносится сразу на продакшен или там правится, недавно заставил перейти на svn

Ну видите, как хорошо. Вам удалось внедрить SVN — к вашему мнению прислушиваются

Здравствуйте, __kot2, Вы писали:
Хотел поставить вам +3, но что то сайт перестал давать такую возможность

Все верно говорите + обычно кто кричит больше всех, что надо переписать все и везде — в результате вообще готов завалить проект.

Строки подключения — это не самое страшное.
Вот когда кривая архитектура

При этом проект уже запущен, переписывать ничего нельзя, плюс требуется следовать принятым в это проекте практикам.
В проект вносятся постоянно поправки, он растет и развивается.
Но! Даже самые элементарные операции вызывают дикие тормоза и мильён обращений к базе.

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

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

A>>Советую не считать себя самым умным.
MM>Что, вообще нельзя критиковать? Уровень у всех программистов одинаковый?

Да как тебе сказать... Напоминаю о необходимости смотреть в зеркало. Только и всего.
Для твоего соседа твой код выглядит так-же непонятно как его код для тебя.
И стиль отличается настолько же.

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

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

A>>Программы можно писать в разных стилях.
A>>Упорядочивать их вдоль или поперек. Экономить или на одном или на другом.
A>>Если твой предшественник писал в другом стиле — это не значит что его стиль хуже.
A>>Более того — у тебя есть шанс посмотреть в чем его стиль лучше.
A>>А когда поймешь — использовать плюсы и его и своего стиля.

A>кроме "разных стилей" есть хороший код и плохой код.
A>код в котором не соблюден DRY это плохой код. точка.

Вы так говорите, как будто видели этот код. А Вы его не видели.
С вероятностью 90% этот код не хуже того, который порождает топик-стартер.

A>это не "стиль", это непрофессионализм — лень, непонимание проблем своего кода, неуважение к коллегам которые будут работать с кодом после тебя.

Вам поди тоже 25 лет? Нет, Вам наверное меньше

Вы явно младше топик-стартера.

A>"держать 1 Мб кода в голове" это вопиющий непрофессионализм. ОК, Вы держите этот код в голове. Завтра придет другой человек, ему дадут этот код и скажут добавить такие-то и такие-то фичи, срок неделя. Он успеет запомнить что вы там накопипастили, какой юнит от какого зависит?

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

Например, могу написать не на С++ а на Питоне. Потому что на Питоне будет в три раза короче — не мегабайт а 300 КБайт.

A>Считаете что с вашим кодом всегда будете работать только вы? Отлично. Пишите как хотите, только другим советы не давайте.

Не хами. Особенно не хами, если не можешь удержать в голове 1 мегабайт кода.
1 мегабайт — это очень мало, уж поверь мне.
Как раз недавно пришлось вьезжать в чужой проект такого размера и прикручивать новую фичу.
Вьехал и вкрутил. За неделю, да.

A>>А я использую голбальные переменные
A>а автоматические тесты используете? покрытие больше 90%?

Использую. Сколько процентов — не считал. Этим другие люди занимаются.

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

A>Вы так говорите, как будто видели этот код. А Вы его не видели.
A>С вероятностью 90% этот код не хуже того, который порождает топик-стартер.

я видел разный legacy код, такой же описывает ТС.
и судя по тому что ТС называет конкретные проблемы кода, которые наплодил автор кода, ТС не будет писать код хуже, IMO

A>>это не "стиль", это непрофессионализм — лень, непонимание проблем своего кода, неуважение к коллегам которые будут работать с кодом после тебя.

A>Вам поди тоже 25 лет? Нет, Вам наверное меньше

Вы явно младше топик-стартера.

примерно на год меньше, экстрасенсорный вы наш

A>>"держать 1 Мб кода в голове" это вопиющий непрофессионализм. ОК, Вы держите этот код в голове. Завтра придет другой человек, ему дадут этот код и скажут добавить такие-то и такие-то фичи, срок неделя. Он успеет запомнить что вы там накопипастили, какой юнит от какого зависит?

A>Понимаешь, вьюношь... Вы сначала читать научитесь. Нет не код, сначала русский язык.
A>Если я оптимизирую маленькую программу не так как большую, это не значит, что я занимаюсь копи-пастом.
A>Я просто оптимизирую по другому. Для маленькой программы не нужны такие накладные расходы, как для большой.
A>(Вот это Вы должны были прочитать и не прочли). А разорались тут на весь интернет.

A>Например, могу написать не на С++ а на Питоне. Потому что на Питоне будет в три раза короче — не мегабайт а 300 КБайт.

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

A>>Считаете что с вашим кодом всегда будете работать только вы? Отлично. Пишите как хотите, только другим советы не давайте.

A>Не хами. Особенно не хами, если не можешь удержать в голове 1 мегабайт кода.
A>1 мегабайт — это очень мало, уж поверь мне.
A>Как раз недавно пришлось вьезжать в чужой проект такого размера и прикручивать новую фичу.
A>Вьехал и вкрутил. За неделю, да.

Один мегабайт может очень много.
Просто видимо вам постоянно попадаются 1 Мб хорошего кода, в мне 500 Кб плохого. Такое возможно, с точки зрения статистики.
Я не знаю какой код был у вас, но я имею ввиду проекты такого рода:
600Кб кода на дельфи, все в 1 файле, с асм вставками, (это когда коммент {FEEL THE POWER OF THE ASSEMBLER} и сотня строк асма сомнительного качества)
200-300Кб кода на дельфи, почти весь код в TForm1,
500Кб кода на С++ (MFC), запомнился тем что надо было поменять копипасту в пяти местах, потом после тестирования нашлось шестое, а потом седьмое,
~300 кода на Си в .cpp файлах (GUI — WinAPI), с кучей extern'ов внутри .cpp и прочих неразборчивых связей, кучей копипасты, switch'ами в сотни строк.

Когда на 10 строчек кода приходится восемь "WTF?!" — это не стиль. И кода становится очень много.
Да, я не могу сходу удержать в голове этот код, так чтобы можно было в нем что-то поправить и не сломать. (а как узнать что не сломал? иногда для тестирования нужен реальный сервер или реальное железо, которого нет)

A>>>А я использую голбальные переменные
A>>а автоматические тесты используете? покрытие больше 90%?

A>Использую. Сколько процентов — не считал. Этим другие люди занимаются.
и вам не говорят. вот такие нехорошие люди.

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

G>наглость минусовать неоднократно когда тебя пытаются поправить.
Кнопка [-] называется "не согласен", и только для это и предназначена, уважаемый кармолюб.

G>Я бы, например, твой код отлаживать наверное не смог бы нормально, поскольку у тебя там исключения на каждом шагу генерируются.
Да, генерируются. И я тоже люблю использовать отладчик (что плохо), и не вижу никаких проблем с исключениями при отладке. Может вы отладчиком пользоваться не умеете? (Я не вижу другого объяснения)

G>Постарайся просто принять как рабочую точку зрения, что тебе пишут более опытные товарищи, понять ты это сможешь несколько позже, с приходом опыта.
Возраста или опыта? Что-то "опытный товарищ" больше интересовался возрастом, а не опытом разработки.
Я всегда рад послушать\почитать мнение авторитетов, но к тому же Р.Мартину (aka Uncle Bob) я прислушиваюсь больше чем к alpha21264. Хз, у него как-то убедительнее получается писать, наверное.

G>Принимать и поддерживать плохой код часто лучше, чем переписывать все и сразу.
G>Перепишешь и не факт, что лучше сделаешь.
Это зависит только от квалификации. Если у вас не получается сделать лучше — ... (ну вы поняли).

> Это зависит только от квалификации. Если у вас не получается сделать лучше — ... (ну вы поняли).

А может быть дело в том, что у вас недостаточно квалификации для поддержки и рефакторинга чужого кода? Не кричать "шеф! все пропало!!!", когда копипастинг можно просто спокойно отрефакторить и вынести в отдельный класс?

Posted via RSDN NNTP Server 2.1 beta

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

>> Это зависит только от квалификации. Если у вас не получается сделать лучше — ... (ну вы поняли).

G>А может быть дело в том, что у вас недостаточно квалификации для поддержки и рефакторинга чужого кода? Не кричать "шеф! все пропало!!!", когда копипастинг можно просто спокойно отрефакторить и вынести в отдельный класс?

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

но тут возникает вопрос, не быстрее ли выкинуть код и переписать с нуля?

A>Устроился на работу, по функциональным обязанностям должен буду отвечать за разработанные проекты. Но дело в том, что уже до меня был написан проект, разработчик которого, мягко говоря, не был "профи". В коде проекта все слои оказались смешаны, в UI размазана бизнес логика и порой присутствуют такие перлы, что можно только закрыть глаза, например конекшен стринги захардкожены жестко в коде и продублированы по всему приложению — бывает даже случается так, что в одном методе встречается 3-4 места с жестко прописанным конекшен стрингом.

я не уже говорю о копипасте

Бывали места, где имя функции содержало вперемешку кирилический символы и латиницу.

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

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

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

A>но в этом случае будем молиться на этого разработчика и думать как бы он не ушел.

Молиться подавно не надо. Надо уметь подхватить проект если что. Тем более что проект малюсенький.

P.S. Ты только представь если бы ты унаследовал проект которому 10 — 15 лет и писала его куча разных людей. Тоже бы горел желанием его переписать?

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

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

Я боюсь представить что будет если каждый последущий разработчик будет переписывать код предшественника(ов).

R>>взвесьте последствия для себя
A>Как я уже сказал, последствия могут быть одни — если этот разработчик уйдет, то я буду поддерживать данный проект.

Нормальная и стандартная ситуация.

__>Здравствуйте, __kot2, Вы писали:
__>>это для тебя она станет организованной. а придет новый человек, для него твой код будет свалкой гавна.
__>я, например, еще не видел ни одного даже суперопытного разработчика, который бы систематически не писал херни по моему мнению. например, один знакомый недавно отколол — memsetом классы инициализировал. и все работало, пока он виртуальные методы не ввел. и че-то сламалася

Ну это явно сразу что плохой разработчик. Для того чтобы не инициализировать объекты memset-ом суперопытным быть не надо.

SD>Пишите уж лучше новый, раз существующий — существует и работает. Если им пользуются — не трогайте без необходимости. Совет из жизненного опыта.

Добавлю. Это полезный опыт уметь работать с чужим кодом.

A>>Советую не считать себя самым умным.
MM>Что, вообще нельзя критиковать? Уровень у всех программистов одинаковый?

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

K>Рефакторить или отказаться с этим работать, других вариантов для уважающего себя профи просто нет

Виден совет непрофессионала. Код которому 10-20-30 лет и который писала куча людей которые больше не работают в компании ты тоже начнешь сразу переписывать или отказываться с ним работать?

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

Судя по желанию всюду пихать паттерны и все переписать у него ее вообще нет.

E>Сидеть на такой работе, где говнокод ковырять — это деградация в любом случае.

Такова работа программиста — ковыряться в коде предшественников.

E>Это никогда себя не окупит! Денег у тебя не будет столько, сколько могло бы быть в Москве, даже в случае, если ты наивысшую для простого неблатного смертного карьеру сделаешь, уйдя из программирования. А проект можно даже не пытаться вытягивать — один хрен тебе даж спасибо никто не скажет — это не надо никому.

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

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

K>>Рефакторить или отказаться с этим работать, других вариантов для уважающего себя профи просто нет

ОК>Виден совет непрофессионала. Код которому 10-20-30 лет и который писала куча людей которые больше не работают в компании ты тоже начнешь сразу переписывать или отказываться с ним работать?

Точно, как это я не сообразил. Настоящие "профи" код никогда не рефакторят

Я всегда переписываю код, который крив. Неважно кто его писал и когда.

Здравствуйте, Олег К., Вы писали:
ОК>У топикстартера не менее гениальное видение кода. Здесь.
А что я тут не правильно сказал? Человек работающий с этим проектом не знает вообще ООП, не знает про интерфейсы, и уж не очевидно ли что если я ввиду любые ООП конструкции(что как бы подразумевает введение паттернов) это повысит планку для вхождения? обоснуйте свой ответ, а не кидайтесь г*ном сударь.

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

SD>Да, может. Особенно если паттерны бездумно применяются свеженьким выпускником ВУЗа, годков так 22-26. Как раз ваш случай.
Вот не нужно делать таких выводов вы мой бекграунд не знаете.
SD>Любым инструментом можно сделать хорошо. Скажем, скальпелем. А можно и убить пациента вконец. Так же и запиливание паттернов поверх спагетти-кода может кого угодно убить.
Если использовать стандарты, то даже скальпелем не убьешь.
SD>Пишите уж лучше новый, раз существующий — существует и работает. Если им пользуются — не трогайте без необходимости. Совет из жизненного опыта.
Только при условии, что я не буду за него отвечать.

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

MM>Запомни:
MM>Качество — зло. Паттерны — зло. Архитектура — глупость. Работает — не трогай. В конце концов, Булгария тоже плавала!
Хочется добавить: да здравствует, мать анархия!
MM>Короче, сиди и не выпендривайся.
Не внимательно читаешь, я отвечаю за этот проект, что не ясно?

Здравствуйте, Undying, Вы писали:
U>Паттерны это инструмент. Инструмент можно применить правильно, тогда он упростит код и вхождение в код в том числе. Можно неправильно, тогда код кардинально усложнится.
Но это не значит, что от него нужно держаться подальше.

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

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

ОК>Судя по желанию всюду пихать паттерны и все переписать у него ее вообще нет.
Ну, я уверен на 100%, что под паттернами подразумевается максимум MVC и работа с базой через пул соединений. Так как сколько не видел сторонников паттернов, у которых они от зубов отскакивают — ни один не применяет их там, где нужно, да и где не нужно тоже — времени не хватает

.

E>>Сидеть на такой работе, где говнокод ковырять — это деградация в любом случае.
ОК>Такова работа программиста — ковыряться в коде предшественников.
Только код предшественников может быть разным. Иногда у предшественников есть чему поучиться. Но это бывает только в случае, если найм поставлен на основе реального кода, а это большая редкость.

ОК>Ну почему сразу вытягивать? Топикстартер описал обычную рабочую ситуацию.
Когда изначально даж SVN не было

? Сплошной копипаст, все связано со всем через глобальные переменные, код даже не процедурный, а куча вложенных if for switch? Проходили, знаем про такие проекты. Чем больше у конкурентов таких рабочих ситуаций, тем нам лучше, что могу сказать

ОК>>Ну почему сразу вытягивать? Топикстартер описал обычную рабочую ситуацию.
E>Когда изначально даж SVN не было

.

И что ты предлагаешь? Чтобы каждый очередной девелопер переписывал код предыдущих?

У конкурентов примерно аналогично.

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

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

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

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

Чего-чего?

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

__>>это для тебя она станет организованной. а придет новый человек, для него твой код будет свалкой гавна. любому человеку именно его стиль кажется самым правильным среди всех.
__>>ты понимаешь, что все, что ты наменяешь, нужно будет заново перетестировать? стоимость этого учитываешь? или ты собрался сразу идеальный код писать? ты уверен, что знаешь как сделать лучше? а насколько лучше? а оно того стоит?
A>Разве применение паттернов, может превратить мешанину кода в еще большее гОвно,
легко. патерны нифига не панацея, их тоже можно неправильно применить.
A> неужели ты ставишь мнение таких метров программирования как Фаулер, Эванс,Бэк по структурированию и паттерированию программ в грош?
не знаю как он, а я их гениями не считаю.

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

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

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

. А вот кто дерьмо не разгребает — у тех времени никогда нет.

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

__>если цель поднятие чсв, то публично высмеивайте коллегу за его косяки

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

я плохо поступаю да? разве другие так не делают

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

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

A>Устроился на работу, по функциональным обязанностям должен буду отвечать за разработанные проекты. Но дело в том, что уже до меня был написан проект, разработчик которого, мягко говоря, не был "профи". В коде проекта все слои оказались смешаны, в UI размазана бизнес логика и порой присутствуют такие перлы, что можно только закрыть глаза, например конекшен стринги захардкожены жестко в коде и продублированы по всему приложению — бывает даже случается так, что в одном методе встречается 3-4 места с жестко прописанным конекшен стрингом.

я не уже говорю о копипасте

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

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

Надо начинать с малого:

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

Потом более глубокий:
— Пересмотреть логическую структуру кода, разделить слои или что там у вас.

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

Или копаться в чужом коде и делать его лучше это не для гуру?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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) При переписывании стремится писать код как можно проще. Т.е. в идеале без дублирования и с минимально возможным количеством слоев абстракций.

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

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

. Интересно, дерьмо стали разгребать или нет

...

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

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

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

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

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

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

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

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

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

. А вот кто дерьмо не разгребает — у тех времени никогда нет.

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

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

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

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

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

P.S. Дешивизна тут не при чем. Дорогие програмисты тоже плохой пишут. Это просто говорит как хорошо человек умеет продавать себя.

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

. Интересно, дерьмо стали разгребать или нет

...

Так и живут. Большинство проектов в Штатах в подобном состоянии, плюс-минус. А ты бы в Штатах работать не смог, судя по заявлениям чуть выше.

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

Вообще-то ему дельные советы дают. Не переписывать ничего а работать в рамках текущей задачи и/или рефакторить по-немногу если есть возможность.

ОК>>Ладно этот проект маленький. А что бы он делал с проектом который существенно больше и дольше находится в продакшне?
MM>У меня был опыт проекта, в котором участвовал очень своеобразный разработчик. Он намного старше меня и более опытнее, должность тоже была круче. Когда я увидел его код, ужаснулся. Потом решил, может мне опыта не хватает. Потом я тоже приходил на RSDN за подобным советом. Меня выставили таким же дураком, не способным понять всей гениальности затеи... Однако, я тогда смог продавить переписывание модуля. Но то была лишь капля в море. И знаешь что в итоге случилось? Проект не приняли. Ага! Приложение просто не работало нормально, потому что тот опытный разработчик, которого я видите ли не понимал, писал код чертовски хреново. И когда пришло время проверять поделку не в дебаге, а с пользователями, последние офигели от количества недоработок, глупых ошибок и неустоучивости системы. Но я о таком результате говорил с самого появления на проекте. Но! Менеджер взвесил риски и решил не исправлять. Советчики с RSDN тоже подумали, что я шибко молод. И вот вам красноречивый итог.

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

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

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

A>А ты уверен, что туда надо тащить DI и покрывать тестами?
Ну вот на форуме дают советы не использовать юнит тесты.

Начать с определения своей зоны ответственности.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

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

ОК>Потому что проект маленький. Поэтому и можешь.
Вообще то, большой проект состоит из множества средних. Средние — из множества мелких. Всякие "глупости" вроде декомпозиции придумали довольно давно. При этом декомпозируют проект даже фирмы, где копипаст и костыли являются основными методологиями разработки. При этом даже модули, которые всего занимают 100 000 строк (копипастнутые, которые при нормальном коде легко сократить до 20 000) почему то на практике оказываются тоже говнокодом. А вот модуль из миллиона строк, который ну никак нельзя разбить на мелкие модули по 100 000 строк, я как то представить не могу. У меня уж на "маленьком" проекте порядка 20 модулей пока, например. И если они разрастутся, что ориентироваться станет тяжело — я каждый модуль без проблем в состоянии еще поделить. Пока необходимости нет, но о выделении еще нескольких модулей уже подумываю.

SD>>Да, может. Особенно если паттерны бездумно применяются свеженьким выпускником ВУЗа, годков так 22-26. Как раз ваш случай.
A>Вот не нужно делать таких выводов вы мой бекграунд не знаете.

Так расскажите же, что у вас за опыт (кто такой бекграунд и почему его Ожегов не знает?).

A>Если использовать стандарты, то даже скальпелем не убьешь.

Вброс засчитан.

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

Так и заявляйте начальнику. Впрочем... я вам открою страшную тайну, вы и так _ни за что_ не отвечаете. На вас никакой ответственности не налагается. Допустили баг — ну допустили, исправите. Все. Вас не лишат зарплаты (запрещено по ТК), у вас не отберут квартиру, вас в тюрьму не посадят. О какой ответственности вы вообще заявляете

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

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

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

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

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

Если вы пишете код ради кода, ваш подход имеет право на жизнь.

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

Потому как, еще раз объясняю, ресурсы, которые вы сегодня потратили на рефакторинг, конкуренты потратили на улучшение, например, юзабилити — и завтра их продукт покупают, а ваш — нет. И весь ваш рефаторинг оказался ненужным, потому что никто его так и не увидел.

ОК>>Потому что проект маленький. Поэтому и можешь.
E>Вообще то, большой проект состоит из множества средних. Средние — из множества мелких. Всякие "глупости" вроде декомпозиции придумали довольно давно. При этом декомпозируют проект даже фирмы, где копипаст и костыли являются основными методологиями разработки. При этом даже модули, которые всего занимают 100 000 строк (копипастнутые, которые при нормальном коде легко сократить до 20 000) почему то на практике оказываются тоже говнокодом. А вот модуль из миллиона строк, который ну никак нельзя разбить на мелкие модули по 100 000 строк, я как то представить не могу. У меня уж на "маленьком" проекте порядка 20 модулей пока, например. И если они разрастутся, что ориентироваться станет тяжело — я каждый модуль без проблем в состоянии еще поделить. Пока необходимости нет, но о выделении еще нескольких модулей уже подумываю.

С этого проекта ты "свалил достаточно быстро."

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

SD>Заметьте — вы снова вините во всем кого угодно, только не себя. Вы ни на минуту не задумались, на кой ляд вы "продавили переписыывание модуля" вместо банального исправления ошибок и рефакторинга строго по месту (где требуется, а не где хочется оставить свой след). Виноваты все вокруг, кому вы рассказывали о том, какая плохая у вас система.
Ага, про тот говнокод, о котором я когда-то спрашивал, мне тоже самое писали. История повторяется. Ну, конечно. Переходил кто-то дорогу на зеленый свет, и вдруг из-за угла вылетает машина и сбивает. Виноват прохожий, не иначе. Что сказать то хочу. Извини, но я приложил все усилия, чтобы спасти проект, вплоть до взятия на себя обязанностей более опытного и больше меня зарабатывающего человека, когда ведущий программист осознал куда катится проект. Я всегда готов отвечать за свои баги и ошибки, но за чужое разгильдяйство — нет уж.

SD>PS: справедливости ради, у меня был аналогичный опыт. Правда, ничего никому переписывать не дозволили, так, поковырялись совочком в какашках, сверху натянули блестящую обертку и так прямо и продавали. Вроде ничего, жалобы были, решались в рабочем порядке.
Справедливости ради, ты не можешь знать, был ли у тебя аналогичный опыт. Если уж так хочется мериться, я участвовал в семи проектах, шесть из которых были внедрены. Четыре проекта имели гораздо более многолетнюю историю развития до моего прихода, в отличии от заваленного. Почему на этих четырех проектах мне не стреляло переписывать подсистемы, а только частичный рефакторинг?

MM> Я всегда готов отвечать за свои баги и ошибки, но за чужое разгильдяйство — нет уж.

Вот потому вы и программист. Причем, вижу, молодой. До 30 уж наверняка.
Рассуждения вида "да я один весь в белом", максимализм в полной мере, желание померяться проектами (какое достижение — 7 проектов!!!). Хорошо хоть строками кода не меряетесь. Ну или количеством написанных юнит-тестов.

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

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

"Жениться бы вам, барин!" (С)

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

SD>Вот потому вы и программист. Причем, вижу, молодой. До 30 уж наверняка.
SD>Рассуждения вида "да я один весь в белом", максимализм в полной мере, желание померяться проектами (какое достижение — 7 проектов!!!). Хорошо хоть строками кода не меряетесь. Ну или количеством написанных юнит-тестов.
Если так трудно, я раскрою. Если код пишу я, то готов отвечать за него. Если код написал другой программист, и мне нужно исправить его баг, я тоже готов отвечать за это исправление. Если же я вижу баг, но руководитель не дает мне время на исправление, почему я должен отвечать за это?

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

SD>"Жениться бы вам, барин!" (С)
Смешно читать обвинение в желании померяться от человека, с первого поста принявшегося телепатить возраст.
Смешно читать обвинение в нежелании разбираться от человека, который проигнорировал факт того, что это был единственный проект.

SD>>Вот потому вы и программист. Причем, вижу, молодой. До 30 уж наверняка.
SD>>Рассуждения вида "да я один весь в белом", максимализм в полной мере, желание померяться проектами (какое достижение — 7 проектов!!!). Хорошо хоть строками кода не меряетесь. Ну или количеством написанных юнит-тестов.
MM>Если так трудно, я раскрою. Если код пишу я, то готов отвечать за него. Если код написал другой программист, и мне нужно исправить его баг, я тоже готов отвечать за это исправление. Если же я вижу баг, но руководитель не дает мне время на исправление, почему я должен отвечать за это?

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

Ты так договоришь тут потому что привык писать много кода с нуля. Отвыкай от этого!

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

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

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

. Интересно, дерьмо стали разгребать или нет

...

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

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

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

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

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

Тогда так ли очевидны проблемы от якобы плохого кода?

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

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

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

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

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

Я же почему возражаю взрослому SkyDrive-у. В его рассуждениях есть громадный изъян (это если забыть про телепатию): он исходит из того, что в жизни на все можно повлиять, а это не так.

ОК>Ты так договоришь тут потому что привык писать много кода с нуля. Отвыкай от этого!
Объясняю на пальцах. Было 7 проектов. Из них 4 были начаты не при мне. Из них 3, в которых я ничего не предлагал переписывать с нуля, и спокойно правил баги, и рефакторил, если это было необходимо для требований заказчика. 1(!) проект из тех четырех оказался полон дерьма. Где здесь привычка к написанию кода с нуля?

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

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

MM>Если так трудно, я раскрою. Если код пишу я, то готов отвечать за него.

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

MM>Смешно читать обвинение в желании померяться от человека, с первого поста принявшегося телепатить возраст.

Вы же меряться начали, не я. Возраст телепатить большого ума не надо, чем более радикальны и забавны суждения, тем возраст меньше. Да и e-mail ваш как бы намекает, да.

>>я плохо поступаю да? разве другие так не делают

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

Ну это у Вас проект такой. А если проект где писало много авторов и ты (т.е. Я) получаешься самый древний, а тут набрали народ новый, и новую версию заказчик захотел, и быстренько-быстренько наваяли нового кода с копипастом старого.
А потом происходит мега задача от заказчика — модернизация, переходим на юникод!!! Волей не волей что в процессе перехода нужно перекупаться во всём г-не. Уже кстати 2 недели барахтаюсь.
И ты понимаешь что надо рефакторинг этому богатству делать а делаешь косметику, потому что впереди непроходимые кучи.
Вот так бывает, думаю не только у меня.

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

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

SD>>Пишите уж лучше новый, раз существующий — существует и работает. Если им пользуются — не трогайте без необходимости. Совет из жизненного опыта.
A>Только при условии, что я не буду за него отвечать.
Тут есть, как минимум, две противоположенные опасности.
1) Ты можешь просто не понимать, почему оно так написано. Может так оказаться, что архитектура не так уж и плоха. Скажем, система может сожержать относитеьно компактный framework + кучу writeonly кода, который пишется по конкретным каким-то запросам, и никоогда не поддерживается, а переписывается заново. Или ещё какой-нибудь хитрый сценарий может быть задействован. В общем может так оказаться, что быо сделано так, что любой студент мог легко добавить типичную фичу, а ты сделаешь так, что это станет сложной задачей, для грамотного инженера.

2) Всё реально плохо, код написан через одно место и всюду по случаю и непоследовательно. Тогда, наверняка никто не знает точно, как именно оно работает. Зато уже есть какие-то пользователи, сценарии, зависимый код или данные, и т. д.
И если ты начнёшь писать "правильный" код по спекам, то окажется, что он делает вовсе и не то, что надо пользователям...

В юбом случае ты попадаешь на удорожание поддержки, что не есть гуд.
Так что могу тебе дать такой совет. Прежде чем ломать, попробуй изучить, разобраться и понять, как поддерживать имеющийся код.
Потом что-то делай, только и исключительно ради каких-то прагматических и понятных целей.
Если у тебя мало опыта в разработке, то согласовывай цели + проноз стоимости их достижения с начальником.
перед этим выясни, сколь дорого обходиось достижение аналогичных целей в прошлом. Ты должен быть ДЕШЕВЛЕ, если ты ЛУЧШЕ...

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 требуется доделывать (али переделывать), на сие мероприятие нужно выделять время.

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

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

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

Я сторонник проектирования по предметной области хорошо описанной Эвансом.

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

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

Меня интересовали прежде всего истории, когда проект полностью переписывался, но как оказалось — никто этим не занимался и поддержки это не получило.

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

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

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

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

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

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

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

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

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

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

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

A>Здравствуйте, Aviator, Вы писали:
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
Т.е. до статьи Фаулера можно было писать исключительно дублирующийся и запутанный код? Ну а разделение на слои конечно же делает код понятным и исключает дублирование.

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, Kerk, Вы писали:
K>Ну так люди и делятся своим опытом. Который говорит, что желание все переписать очень часто говорит о низкой квалификации. Я бы не стал в этом видеть личные нападки.
желание все переписать возникает из-за несоответствия своим правильным понятиям о том, как надо писать с тем, что есть. возникает оно обычно из-за того, что человеку только что обьяснили единственно верный способ разработки. или же он книжку прочитал о таком способе разработки. опытные же люди к заявлениям об единственной правильности относятся скептически, они видели в работе код разной степени гавенности, видели разные подходы в разработке и понимают, что возможно для данного проекта ничего страшного с кодом не происходит. было и похуже

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

A>Это не цель, а стиль кодирования.
A>Есть какая-то изолированная функция, на неё куча тестов. То есть известно, что в целом она работает верно. Но приходится немного модифицировать её.

Так это как раз и есть "рефакторинг по месту". Когда _уже сейчас_ нужно что-то делать с данной функцией.
Я же возражал против "вялотекущего рефакторинга ради вероятной перспективы в отдаленном будущем". Если у рефакторинга нет конкретной цели и его проведение не обусловлено никакими причинами кроме "хочу сделать чтобы было хорошо" — вот против такого рефакторинга я возражаю.

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

Одному мне видится противоречие в двух рядом стоящих фразах одного сообщения одного автора?

Pzz>Вы не представляете, сколько раз мне рассказывали эту сказку.

А вы не представляете, сколько раз я слышал сказку про "вот сейчас потренируемся, и потом за 5 минут добежим". Или, как вариант, "да осталось буквально еще пару зубьев у пилы наточить, а там — весь лес спилим за полчаса!"
Разумеется, ни сейчас, ни потом лес так и не спиливался.

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

Угу.
А ваш проект первой версии формочек на рынок так и не вышел, потому что проект закрыли. Каждый счастлив, каждый получил опыт.

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

SD>А вы не представляете, сколько раз я слышал сказку про "вот сейчас потренируемся, и потом за 5 минут добежим". Или, как вариант, "да осталось буквально еще пару зубьев у пилы наточить, а там — весь лес спилим за полчаса!"
SD>Разумеется, ни сейчас, ни потом лес так и не спиливался.

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

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

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

Поддерживаю.

Да и вообще, ругать чужой код не прилично. Потому что вы не знаете, в каких условиях работал тот программист, когда писал говнокод. Может быть ему просто мало платили и трахали мозги каждый день, требуя немедленных результатов, вот он им и выдавал. А вы бы со своим грамотным подходом просто не справились бы в поставленные сроки. Кто знает кто знает.

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

S>Поддерживаю.

S>Да и вообще, ругать чужой код не прилично. Потому что вы не знаете, в каких условиях работал тот программист, когда писал говнокод. Может быть ему просто мало платили и трахали мозги каждый день, требуя немедленных результатов, вот он им и выдавал. А вы бы со своим грамотным подходом просто не справились бы в поставленные сроки. Кто знает кто знает.

Есть такое но также и есть то, что некоторые такое накодят, даже в идеальных условиях.

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

SD>Не совсем. Я бы даже сказал, совсем не. Разработка софта больше похожа на серию стометровок.

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

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

A>>Есть какая-то изолированная функция, на неё куча тестов. То есть известно, что в целом она работает верно. Но приходится немного модифицировать её.

SD>Так это как раз и есть "рефакторинг по месту". Когда _уже сейчас_ нужно что-то делать с данной функцией.
SD>Я же возражал против "вялотекущего рефакторинга ради вероятной перспективы в отдаленном будущем".

Видно наше понимание велотекущего рефакторинга несколько отличается. В моём представлении, если ты видишь что строка "НашаСамаяГлавнаяТаблицаВБазеДанных" повторяется во многих местах, то можно создать для неё константу или макрос, причём даже не обязательно устранять все использования этой строки, а только те, которые оказались под рукой.

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

A>Видно наше понимание велотекущего рефакторинга несколько отличается. В моём представлении, если ты видишь что строка "НашаСамаяГлавнаяТаблицаВБазеДанных" повторяется во многих местах, то можно создать для неё константу или макрос, причём даже не обязательно устранять все использования этой строки, а только те, которые оказались под рукой.

Чтобы никому не было обидно — в одном месте константу, для тех, что под рукой, в другой — макрос.

#ifndef _waxie_binary_resource_h_
#define _waxie_binary_resource_h_

#include <string>

class BinRes
{
public:
    BinRes();
    virtual ~BinRes();

public:
    static bool ExtractBinResource( wchar_t *strCustomResName, int nResourceId, wchar_t *strOutputName );
};

#endif

тут есть какие-то плюсы стиля?

A>Видно наше понимание велотекущего рефакторинга несколько отличается. В моём представлении, если ты видишь что строка "НашаСамаяГлавнаяТаблицаВБазеДанных" повторяется во многих местах, то можно создать для неё константу или макрос, причём даже не обязательно устранять все использования этой строки, а только те, которые оказались под рукой.

Так я вообще про другое писал, вы попробуйте внимательнее прочитать.
Я возражал против "рефакторинга на перспективу". В особенности если перспектива эта исключительно туманна.

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

__>Здравствуйте, Abyx, Вы писали:
A>>тут есть какие-то плюсы стиля?
__>это стиль. если у него убрать венгерскую нотацию, дефайны большими буквами обьявлять, чтобы не спутать с дефайнами ф-ий, не сокращать BinaryResource до BinRes, и убрать второй public, то получится примерно как я пишу.

Осталось определиться что же есть такое "стиль". Например, в моем понимании, стиль это вот например:

class BinaryResource {

vs

class BinaryResource
{

или

BinaryResource
GetResource(ResourceId id)

vs

BinaryResource GetResource(ResourceId id);

Или, например, стиль именования переменных (pascale, camel..)

То есть нечто, больше относящееся к форматированию. Имена классов типа "BinRes", "a", "b", "ptr" и тп. это в моем понимании просто кривой код, подлежащий рефакторингу.
Использование хедера #include <string> и при этом параметры типа wchar_t скорее всего тоже кривость. Но тут уже надо разбираться с конкретным случаем.

> То есть нечто, больше относящееся к форматированию. Имена классов типа "BinRes", "a", "b", "ptr" и тп. это в моем понимании просто кривой код, подлежащий рефакторингу.
> Использование хедера #include <string> и при этом параметры типа wchar_t скорее всего тоже кривость. Но тут уже надо разбираться с конкретным случаем.

Оппа. Рефакторинг это оказывается переименование идентификаторов. Чудненько, а то я думаю чего это народ все обсуждает, митингует. Теперь я в теме тоже могу обсуждать рефакторинг

Posted via RSDN NNTP Server 2.1 beta

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

>> То есть нечто, больше относящееся к форматированию. Имена классов типа "BinRes", "a", "b", "ptr" и тп. это в моем понимании просто кривой код, подлежащий рефакторингу.
>> Использование хедера #include <string> и при этом параметры типа wchar_t скорее всего тоже кривость. Но тут уже надо разбираться с конкретным случаем.

G>Оппа. Рефакторинг это оказывается переименование идентификаторов. Чудненько, а то я думаю чего это народ все обсуждает, митингует. Теперь я в теме тоже могу обсуждать рефакторинг

А что вас удивляет? Да, рефакторинг, это в том числе и переименование идентификаторов

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

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

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

Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Ulin, Вы писали:
U>>То есть нечто, больше относящееся к форматированию. Имена классов типа "BinRes", "a", "b", "ptr" и тп. это в моем понимании просто кривой код, подлежащий рефакторингу.
__>рефакторинг это пустая трата времени. это лишь адаптация одного стиля под другой. если программа работает, значит она выполняет свои ф-ии и не надо в нее лезть своими ручками. если настолько кривая, что не работает, то ее и не существует.
добавлю, чтобы правильно поняли
в программировании есть сущности, которые взаимодействуют по определенным интерфейсам. сущности группируются в другие сущности, взаимодействующих с другими группами по другим интерфейсам.
если у нас нет какого-то нужного нам интерфейса, значит нам нужно его сделать, введя новые обьекты и использовав интерфейсы к существующим обьектам
если какой-то интерфейс не работает, значит у нас нет рабочего интерфейса — мы либо правим уже существующий код, либо пишем свой код, смотря что быстрее.
если интерфейс работает, то какая разница как он работает?
расширение интерфейса — дело обычно гиблое, так как обьекты должны быть атомарными. и если кто-то навалил все в одну кучу, то нам не стоит заниматься тем же.

Здравствуйте, Ulin, Вы писали:
U>Я бы, все таки, различал понятия другого стиля и кривого кода. Другой стиль рефакторить, конечно же, смысла нет совершенно никакого. А вот кривой код резко увеличивает стоимость внесения изменений. И его рефакторить часто просто приходится. Особенно когда добавление фичи все равно может много чего поломать, тут уж грех не воспользоваться и не отрефакторить изменяемый модуль.
давайте вы приведете пример "некривого кода", а я скажу почему он по-моему мнению кривой и как его нужно изменить? мне аж самому интересно, что из этого получится.

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

__>давайте вы приведете пример "некривого кода", а я скажу почему он по-моему мнению кривой и как его нужно изменить? мне аж самому интересно, что из этого получится.

Ну вот, например, вполне ровный, на мой взгляд, код из либы JRTPLIB (http://research.edm.uhasselt.be/~jori/page/index.php?n=CS.Jrtplib):

class JRTPLIB_IMPORTEXPORT RTCPSenderReportInfo
{
public:
    RTCPSenderReportInfo():ntptimestamp(0,0),receivetime(0,0)        { hasinfo = false; rtptimestamp = 0; packetcount = 0; bytecount = 0; }
    void Set(const RTPNTPTime &ntptime,uint32_t rtptime,uint32_t pcount,
             uint32_t bcount,const RTPTime &rcvtime)            { ntptimestamp = ntptime; rtptimestamp = rtptime; packetcount = pcount; bytecount = bcount; receivetime = rcvtime; hasinfo = true; }
    
    bool HasInfo() const                            { return hasinfo; }
    RTPNTPTime GetNTPTimestamp() const                    { return ntptimestamp; }
    uint32_t GetRTPTimestamp() const                    { return rtptimestamp; }
    uint32_t GetPacketCount() const                        { return packetcount; }
    uint32_t GetByteCount() const                        { return bytecount; }
    RTPTime GetReceiveTime() const                        { return receivetime; }
private:
    bool hasinfo;
    RTPNTPTime ntptimestamp;
    uint32_t rtptimestamp;
    uint32_t packetcount;
    uint32_t bytecount;
    RTPTime receivetime;
};

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

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

__>вывод — код — полное гавно. но оно (скорее всего) рабочее! а, значит, код годный и все замечательно. ну писал его сишник, что ж теперь. главное, чтобы все работало

Ну, некоторые замечания можно оспорить, конечно

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

В целом могу подытожить так: любому рефакторингу есть свое время и место.
1. Если на проекте затишье — почему-бы не замутить рефакторинг по, например, вашим замечаниям, в отдельном бранче, стабилизировать его и подлить в транк?
2. Если рынок требует фичи или завтра, или никогда — лепим копипасты, всячески портим себе карму, но успеваем в срок, в надежде на п.1
3. Если новая фича никак не лезет в существующую реализацию — делаем минимально возможный рефакторинг. Тут просто и выхода другого может не быть. Альтернатива — заплатки на заплатки, и, как следствие, время стабилизации умножаем на 3, хрупкость системы еще больше увеличена — следующие фичи уже умножат время дебага на 10. Если, конечно, не работает п.2

Здравствуйте, Ulin, Вы писали:
U>Но, вот, например, повторяющихся куска, которых было изначально два, резко понадобилось двадцать. Что будем делать? Продолжать копипаст, или, все-таки, вынесем этот код в одно место? То есть, таки сделаем рефакторинг?
я стараюсь вообще не делать повторов ни кода ни данных. соотв-но в моей части повторов не будет. у других — да хоть 20.

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

U>2. Если рынок требует фичи или завтра, или никогда — лепим копипасты, всячески портим себе карму, но успеваем в срок, в надежде на п.1
это вам решать, копипастить код или нет. если он где-то был скопипастен, то вам это делать необязательно.

U>3. Если новая фича никак не лезет в существующую реализацию — делаем минимально возможный рефакторинг. Тут просто и выхода другого может не быть. Альтернатива — заплатки на заплатки, и, как следствие, время стабилизации умножаем на 3, хрупкость системы еще больше увеличена — следующие фичи уже умножат время дебага на 10. Если, конечно, не работает п.2
я делал рефакторинг. тогда, когда не понимал, как проект вообще делать. попробовал одним способом, не получилось, понял, что нужно с другого угла зайти. рефакторинг говорит о том, что проект делают недостаточно компетентные люди. периодический или хронический рефакторинг — проект не будет доделан до нормального состояния никогда.

> 3. Если новая фича никак не лезет в существующую реализацию — делаем минимально возможный рефакторинг.

То есть максимально-возможно переименовываем идентификаторы.
бу-га-га-га....

Posted via RSDN NNTP Server 2.1 beta

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

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

Ну а как ты хотел? "О работе" это же не совсем профильный форум, тут не надо быть экспертом, чтобы отвечать. Так что не стоит удивляться ответам в стиле "у тебя кривые руки", хорошо хоть мудаком не назвали. Вон Octothorp-у в недавней теме про МММ повезло меньше. см. тут.

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

I>Товарищ Маузер, очевидно Вы не в полной мере осознвёте все последствия использования глобальных переменных. Размер программы тут не при чём. А вот портабельность кода убивается на раз — на некоторых платформах глобальность, а порой и синглтоны, технологически недопустимы. Пример — android. И пожалуйста, поосторожнее с поучениями молодёжи.

Если мне придется писать на Андроид, то глобальные переменные не будут самой большой проблеммой.
Там вообще Ява, а я пишу на С++

I>PS. О себе. Вырос, набрался опыта, осознал, ужаснулся, весь опыт выкинул нахрен как вредный, и больше накапливать не буду. Темпы сейчас такие...

Это значит у Вас не тот опыт. Вероятно он у Вас изначально был "низкоуровневый"

Он у вас был уровня "глобальные переменные вредны", а должен быть "не кидайся какашками в коллегу".

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

>>>RTCPCompoundPacket(uint8_t *packet, size_t len, bool deletedata = true, RTPMemoryManager *memmgr = 0);
__>так это С++ или С? почему packed голым указателем?
А что уже в С++ отменили голые указатели?

>>почему указатель = 0? хотя бы NULL нужно писать
Хотя бы потому что это по стандарту

>>> int GetCreationError() { return error; }
__>о, ужас, они про исключения слышали?
Расскжите это Гуглу

__>что это за паскалевское именование?
CamelCase ничем не хуже других конвенций и человек может писать так как это принято в код-снадарте той конторы где он работает.

__>судя по коду реализации RTCPCompoundPacket можно было бы сделать константным классом — он инициализируется данными в конструкторе и всегда остается неизменным. везде забыты константные идентификаторы, соотв-но вместо GotoFirstPacket(), GetNextPacket() можно было просто выдавать константный референс на контейнер

>>>#ifdef RTPDEBUG
>>> void Dump();
>>>#endif // RTPDEBUG <- коммент для дебилов?

Если будут куча вложенных #ifdef, то "дебилами" уже можно назвать кто так не делает.

Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, __kot2, Вы писали:
>>>>RTCPCompoundPacket(uint8_t *packet, size_t len, bool deletedata = true, RTPMemoryManager *memmgr = 0);
__>>так это С++ или С? почему packed голым указателем?
AJD>А что уже в С++ отменили голые указатели?
вот видите, у вас свое мнение насчет правильного кода. и так со всеми. в чем отличие моего мнения от вашего?
я считаю, что в С++ необходимости в голых указателях, тем более на uchar* нету вообще. для этого есть контейнеры — там внутри и len и проверка индексов (если ее дописать

).

>>>почему указатель = 0? хотя бы NULL нужно писать
AJD>Хотя бы потому что это по стандарту
NULL лучше глазами выделяется, сразу видно что это указатель. к тому же проще будет привести к новому стандарту просто заменив все NULL на nullptr, а = 0 придется глазами выглядывать везде

>>>> int GetCreationError() { return error; }
__>>о, ужас, они про исключения слышали?
AJD>Расскжите это Гуглу
зачем? тем более гугл большой. каждому рассказывать? если обьект может принимать невалидное состояние это всегда гемор. тогда иногда обусловленный чем-то, а иногда так сделали, потому что не понимают, что это гемор.

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

AJD>Если будут куча вложенных #ifdef, то "дебилами" уже можно назвать кто так не делает.
я думаю коммент написал какой-нить вижуал ассист, потому что человеку бы он в голову никогда не пришел — соотв-ующий ему ifdef всего строчкой выше.

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

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

A>>Разве применение паттернов, может превратить мешанину кода в еще большее гОвно,

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

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

A>>неужели ты ставишь мнение таких метров программирования как Фаулер, Эванс,Бэк по структурированию и паттерированию программ в грош?
U>Паттерны это инструмент. Инструмент можно применить правильно, тогда он упростит код и вхождение в код в том числе. Можно неправильно, тогда код кардинально усложнится.
Чем сильнее инструмент, тем больше последствий от ошибок и неверного применения.

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

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

K>>>Рефакторить или отказаться с этим работать, других вариантов для уважающего себя профи просто нет

ОК>>Виден совет непрофессионала. Код которому 10-20-30 лет и который писала куча людей которые больше не работают в компании ты тоже начнешь сразу переписывать или отказываться с ним работать?

K>Точно, как это я не сообразил. Настоящие "профи" код никогда не рефакторят

K>Я всегда переписываю код, который крив. Неважно кто его писал и когда.
Ты представляешь объём работ для переписывания кода, который писала команда людей лет этак 10? И не паттерны внедряла, а выполняла бизнес задачи? И когда полное знание о работе ряда компонент потеряны во времени? Ты думаешь майкрософт очень довольна кодом NT и с огромным удовольствием не выкинула бы нафик её на помойку, переписав на новые рельсы с учётом текущих условий?

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

A>Имея в качестве мотивации усложнение проекта для увеличения порога вхождения можно улучшить проект?

Тут изначально позиция ухудшить проект и за счёт этого стать "незаменимым".

Ну по всякому бывает. Зависит от того, что чел сможет после "вхождения" делать.

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

A>>скажите, вот это — стиль?

SD>Да, стиль. Что именно вас возмущает в приведенном кусочке кода?

вы видимо не так поняли.
это production код, весь заголовочный файл целиком.

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

видимо автора научили что в *любом* классе должен быть конструктор и виртуальный деструктор, вот он так и пишет.
он бы и type traits с виртуальным деструктором писал, если бы знал что это такое

и еще меня возмущает #include <string> потому что в этом файле он не используются

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

__>я считаю, что в С++ необходимости в голых указателях, тем более на uchar* нету вообще. для этого есть контейнеры — там внутри и len и проверка индексов (если ее дописать

).
Ты видишь интерфейс но понятия не имеешь как и откуда его используют. Поэтому судить надо тут голый указатель или нет просто не имеешь права. Вызывающая сторона к примеру вполне может передавать кусок из середины какого либо буфера.

>>>>> int GetCreationError() { return error; }
__>>>о, ужас, они про исключения слышали?
AJD>>Расскжите это Гуглу
__>зачем? тем более гугл большой. каждому рассказывать? если обьект может принимать невалидное состояние это всегда гемор. тогда иногда обусловленный чем-то, а иногда так сделали, потому что не понимают, что это гемор.
Есть такая широко распространённая практика как запрет на использование исключений. Весьма разумная между прочим когда применяется там где реально оно того стоит. Поэтому опять таки критика мимо.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

A>>итератор и "итератор STL" это разные вещи.
__>зачем использовать свой, если есть stl?
Потому как STL суть неподконтрольная сторонняя библиотека, версию которую трудно зафиксировать без волевого манагерского решения и которая уже подкидывала подляны наподобие разных характеристик своей работы в разных версиях.

A>>а что, сложно читать?
__>писать длинно
Это проблемы пишущего.

__>>> rawpack.ZeroData();
__>>>он в конструкторе изменяет состояние передаваемого обьекта?????
A>>ну и что? rawpack.GetData() тоже могло бы менять состояние rawpack
__>нажатие педали тормоза в машине тоже может включать правый поворотник. но зачем? код должен преследовать принцип минимальной неожиданности. это часть стиля. у вас скорее всего такого принципа нет. я бы с вами в проекте работать не захотел бы.
Ну например будет инкрементить какой нить counter внутри, для сбора какой нить статистики или ещё чего.
Пропуск const на самом деле тут показывает что писал код сишник, не ++сник. Ошибка не фатальная, так что нет смысла так тщательно к ней придираться.

A>>delete statement должен быть запрещен вне библиотек, по coding style guide
__>какой-то странный этот coding style guide. он в сбербанке случаем был разработан? надо же голову включать что разумно, а что нет и для каждого проекта его адаптировать.
Полноценно судить о codestyle без знаний всей специфики проекта не представляется возможным.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Banned by IT, Вы писали:
__>>я считаю, что в С++ необходимости в голых указателях, тем более на uchar* нету вообще. для этого есть контейнеры — там внутри и len и проверка индексов (если ее дописать

).
BBI>Ты видишь интерфейс но понятия не имеешь как и откуда его используют. Поэтому судить надо тут голый указатель или нет просто не имеешь права. Вызывающая сторона к примеру вполне может передавать кусок из середины какого либо буфера.
значит нужен интерфейс доступа, а не просто голый указатель

__>>зачем? тем более гугл большой. каждому рассказывать? если обьект может принимать невалидное состояние это всегда гемор. тогда иногда обусловленный чем-то, а иногда так сделали, потому что не понимают, что это гемор.
BBI>Есть такая широко распространённая практика как запрет на использование исключений. Весьма разумная между прочим когда применяется там где реально оно того стоит. Поэтому опять таки критика мимо.
с этим я согласен. вообще, никогда ни в одном проекте за 11 лет с этим не сталкивался на практике, но да, слышал, что бывает такое.

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

__>>>я считаю, что в С++ необходимости в голых указателях, тем более на uchar* нету вообще. для этого есть контейнеры — там внутри и len и проверка индексов (если ее дописать

).
BBI>>Ты видишь интерфейс но понятия не имеешь как и откуда его используют. Поэтому судить надо тут голый указатель или нет просто не имеешь права. Вызывающая сторона к примеру вполне может передавать кусок из середины какого либо буфера.
__>значит нужен интерфейс доступа, а не просто голый указатель
Например?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Banned by IT, Вы писали:
A>>>итератор и "итератор STL" это разные вещи.
__>>зачем использовать свой, если есть stl?
BBI>Потому как STL суть неподконтрольная сторонняя библиотека, версию которую трудно зафиксировать без волевого манагерского решения и которая уже подкидывала подляны наподобие разных характеристик своей работы в разных версиях.
итератор — наипримитивнейшая вещь. но если stl ной версии не доверяешь, то можно и свой итератор написать. а вот вносить ф-ал итератора в класс это смесь бульдога с носорогом. но с пивом канает.

A>>>а что, сложно читать?
__>>писать длинно
BBI>Это проблемы пишущего.
и модифицируюещго. это тоже вид копипасты. захотел сменить вид контейнера — сиди правь везде ошибки компиляции

__>>>> rawpack.ZeroData();
__>>>>он в конструкторе изменяет состояние передаваемого обьекта?????
A>>>ну и что? rawpack.GetData() тоже могло бы менять состояние rawpack
__>>нажатие педали тормоза в машине тоже может включать правый поворотник. но зачем? код должен преследовать принцип минимальной неожиданности. это часть стиля. у вас скорее всего такого принципа нет. я бы с вами в проекте работать не захотел бы.
BBI>Ну например будет инкрементить какой нить counter внутри, для сбора какой нить статистики или ещё чего.
насколько я помню это решается указанием volatile у counter. или че-то в этом роде. в общем, решение есть

BBI>Пропуск const на самом деле тут показывает что писал код сишник, не ++сник. Ошибка не фатальная, так что нет смысла так тщательно к ней придираться.
согласен. но код-то от этого лучше не становится

A>>>delete statement должен быть запрещен вне библиотек, по coding style guide
__>>какой-то странный этот coding style guide. он в сбербанке случаем был разработан? надо же голову включать что разумно, а что нет и для каждого проекта его адаптировать.
BBI>Полноценно судить о codestyle без знаний всей специфики проекта не представляется возможным.
зато по уровню владения языком того сишника, который этот код писал мне кажется понятно, что он не знает, как кастомные менеджеры памяти в С++ делаются и тут в явном виде городит свой велосипед

Здравствуйте, Banned by IT, Вы писали:
BBI>Здравствуйте, __kot2, Вы писали:
__>>>>я считаю, что в С++ необходимости в голых указателях, тем более на uchar* нету вообще. для этого есть контейнеры — там внутри и len и проверка индексов (если ее дописать

).
BBI>>>Ты видишь интерфейс но понятия не имеешь как и откуда его используют. Поэтому судить надо тут голый указатель или нет просто не имеешь права. Вызывающая сторона к примеру вполне может передавать кусок из середины какого либо буфера.
__>>значит нужен интерфейс доступа, а не просто голый указатель
BBI>Например?
некий класс имеющий метод или поле length (или size) и имеющий оператор [] или, если нужно, ф-ию которая дает указатель на кусок. возможно, еще что-то умеющий делать. может быть в стиле стрима

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

__>Здравствуйте, Banned by IT, Вы писали:
BBI>>Здравствуйте, __kot2, Вы писали:
__>>>>>я считаю, что в С++ необходимости в голых указателях, тем более на uchar* нету вообще. для этого есть контейнеры — там внутри и len и проверка индексов (если ее дописать

).
BBI>>>>Ты видишь интерфейс но понятия не имеешь как и откуда его используют. Поэтому судить надо тут голый указатель или нет просто не имеешь права. Вызывающая сторона к примеру вполне может передавать кусок из середины какого либо буфера.
__>>>значит нужен интерфейс доступа, а не просто голый указатель
BBI>>Например?
__>некий класс имеющий метод или поле length (или size) и имеющий оператор [] или, если нужно, ф-ию которая дает указатель на кусок. возможно, еще что-то умеющий делать. может быть в стиле стрима
ИМХО это будет уже overkill.
Для публичной либы важно выдать наружу максимально простой и эффективный интерфейс. Максимум что тут можно сделать: wrapper над const void* + size_t. Практической пользы правда от такого будет ноль.
Либа, которая будет заставлять переоборачивать данные или же использовать только свои контейнеры имеет высокие шансы быть отправленной "на помоечку" (тм)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

__>>>нажатие педали тормоза в машине тоже может включать правый поворотник. но зачем? код должен преследовать принцип минимальной неожиданности. это часть стиля. у вас скорее всего такого принципа нет. я бы с вами в проекте работать не захотел бы.
BBI>>Ну например будет инкрементить какой нить counter внутри, для сбора какой нить статистики или ещё чего.
__>насколько я помню это решается указанием volatile у counter. или че-то в этом роде. в общем, решение есть
mutable, но это костыль в разы покруче отсутствия const. Ибо только запутывает: вроде как функция декларирует что ничего не меняет но всё таки меняет. Уж лучше пусть её const не объявлять, будет куда честнее.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Banned by IT, Вы писали:
BBI>Для публичной либы важно выдать наружу максимально простой и эффективный интерфейс. Максимум что тут можно сделать: wrapper над const void* + size_t. Практической пользы правда от такого будет ноль.
ну если такую цель преследовать, то это итератор над char * + size_t. это если в С++ стиле писать.
конкретно я ничего не имею против кода этой библиотеки. по сравнению со среднестатистическим кодом он прекрасен. самое главное — чтобы код работал. но я хочу показать, что код далеко не идеальный. вообще, я эту тему поднял говоря, что любой хороший код неидеален. конкретно эта библиотека содержит достаточное кол-во косяков, велосипедов и возможных проблем на ровном месте. но она отличная по сути.

BBI>Либа, которая будет заставлять переоборачивать данные или же использовать только свои контейнеры имеет высокие шансы быть отправленной "на помоечку" (тм)
мне кажется что им все-таки стоило ввести не указатель на данные, а стрим, как в Яве принято. там все отлично ложится.
а то так если глянуть, одна сплошая бомба какая-то:

RTCPSRPacket::RTCPSRPacket(uint8_t *data,size_t datalength)
: RTCPPacket(SR,data,datalength)
{
knownformat = false;

RTCPCommonHeader *hdr;
size_t len = datalength;
size_t expectedlength;

hdr = (RTCPCommonHeader *)data;
if (hdr->padding) БАБАХ!!!
{
uint8_t padcount = data[datalength-1]; БАБАХ!!

Здравствуйте, Banned by IT, Вы писали:
__>>>>нажатие педали тормоза в машине тоже может включать правый поворотник. но зачем? код должен преследовать принцип минимальной неожиданности. это часть стиля. у вас скорее всего такого принципа нет. я бы с вами в проекте работать не захотел бы.
BBI>>>Ну например будет инкрементить какой нить counter внутри, для сбора какой нить статистики или ещё чего.
__>>насколько я помню это решается указанием volatile у counter. или че-то в этом роде. в общем, решение есть
BBI>mutable, но это костыль в разы покруче отсутствия const. Ибо только запутывает: вроде как функция декларирует что ничего не меняет но всё таки меняет. Уж лучше пусть её const не объявлять, будет куда честнее.
const пишут те, кто понимает концепцию неизменяемых обьектов. неизменяемые обьекты это очень круто и удобно. но конечно же в команде найдутся те, кто будет "собирать статистику вызовов" или искать другое оправдание не использовать const — вот специально для них ввели mutable

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

BBI>>mutable, но это костыль в разы покруче отсутствия const. Ибо только запутывает: вроде как функция декларирует что ничего не меняет но всё таки меняет. Уж лучше пусть её const не объявлять, будет куда честнее.
__>const пишут те, кто понимает концепцию неизменяемых обьектов. неизменяемые обьекты это очень круто и удобно. но конечно же в команде найдутся те, кто будет "собирать статистику вызовов" или искать другое оправдание не использовать const — вот специально для них ввели mutable

Нет. mutable в таком контексте использовать — себе дороже.
Его вообще крайне редко следует использовать, примерно как goto — только если без него ещё хуже получается.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Banned by IT, Вы писали:
BBI>Нет. mutable в таком контексте использовать — себе дороже.
BBI>Его вообще крайне редко следует использовать, примерно как goto — только если без него ещё хуже получается.
я никогда в жизни не использовал mutable
но и методы которые по логике вещей не должны менять состояние обьектая всегда делаю const и никогда в жизни не было таких проблем, что "однажды оно может стать неконстантным". это кажется таким же бредом, как если бы кто-то писал код так, что однажды плюс может стать минусом

__>насколько я помню это решается указанием volatile у counter. или че-то в этом роде. в общем, решение есть

не volatile, a mutable. С volatile аккуратнее там, очень спорная штука в С++.

Здравствуйте, SkyDance, Вы писали:
__>>насколько я помню это решается указанием volatile у counter. или че-то в этом роде. в общем, решение есть
SD>не volatile, a mutable. С volatile аккуратнее там, очень спорная штука в С++.
вообще, я бы не стал включать mutable в язык. если кому-то нужна такая возможность, то кто мешает конст кастом откастить this и спокойно менять хоть таблицу виртуальных методов?

это ничуть не хуже будет смотреться

__>вообще, я бы не стал включать mutable в язык. если кому-то нужна такая возможность, то кто мешает конст кастом откастить this и спокойно менять хоть таблицу виртуальных методов?

это ничуть не хуже будет смотреться

Не-не-не. Когда применяется какая-то "магия", там сразу и не видно, зачем все эти "касты" и прочая лабуда.
Для того и нужны keywords, чтобы explicitly показать — "вот они, грабли" (С) Большинство программистов при виде необычных keywords (тех же mutable, volatile, static) сразу напрягаются и начинают быть более внимательными. А при виде г-кода просто вздыхают "ну вот опять", и не уделяют ему дОлжного внимания.

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

__>>вообще, я бы не стал включать mutable в язык. если кому-то нужна такая возможность, то кто мешает конст кастом откастить this и спокойно менять хоть таблицу виртуальных методов?

это ничуть не хуже будет смотреться

SD>Не-не-не. Когда применяется какая-то "магия", там сразу и не видно, зачем все эти "касты" и прочая лабуда.
SD>Для того и нужны keywords, чтобы explicitly показать — "вот они, грабли" (С) Большинство программистов при виде необычных keywords (тех же mutable, volatile, static) сразу напрягаются и начинают быть более внимательными. А при виде г-кода просто вздыхают "ну вот опять", и не уделяют ему дОлжного внимания.
в общем-то да, но коммент в стиле
************************************************************
*********** ЭТО WORKAROUND ДЛЯ БАГА GCC — 78642!!! *********
********** НЕ ТРОГАТЬ!! ***********************************
************************************************************

обходятся без keywords и заметнее

HRESULT LoadIcons(
    UINT cVals,                 // In: Count of property values
    const CEPROPVAL* pVals,     // In: Property values.
    DWORD dwFlags               // In: flags that control how we load the icons
)
{
    UNREFERENCED_PARAMETER(cVals);
    HRESULT hr = S_OK;
    DWORD dwPhoneFeatureLevel = 0;
    DWORD dwMLFeatureLevel = 0;
    DWORD dwVoIPFeatureLevel = 0;

    SetRssiBitmapFunctions();

    ASSERT(pVals);
    ASSERT(cVals == ipropLast);

    static const UINT c_AllVMFlags = (NSF_NEW_VM_LINE1 | NSF_NEW_VM_LINE2 | NSF_NEW_VM_VOIP | _NSF_GSM_VMAIL_ONELINE);

    CHRA(GetDeviceFeatureLevel(DFLI_ML_EX, &dwMLFeatureLevel));
    CHRA(GetDeviceFeatureLevel(DFLI_PHONE, &dwPhoneFeatureLevel));
    CHRA(GetDeviceFeatureLevel(DFLI_VOIP , &dwVoIPFeatureLevel));

    // Get property values.
    UINT uPhoneStatus, uSignalStrength, cActiveCalls, uInputState, uBatteryStr, uBatteryFlags, uNotify, uSynchronize, uBluetooth, uSpeakerphone, uSignalStrengthRaw, uCellSystemAvailable, uCellSystemConnected, uWiFi, uPhoneStatusEx;
    uPhoneStatus = (pVals[ipropPhoneStatus].wFlags & CEDB_PROPNOTFOUND) ? 0 : pVals[ipropPhoneStatus].val.ulVal;
    uBatteryStr = (pVals[ipropBattery].wFlags & CEDB_PROPNOTFOUND) ? 0 : BATTERY_STRENGTH(pVals[ipropBattery].val.ulVal);
    uBatteryFlags = (pVals[ipropBattery].wFlags & CEDB_PROPNOTFOUND) ? 0 : BATTERY_FLAGS(pVals[ipropBattery].val.ulVal);
    uSignalStrength = (pVals[ipropSignalStrength].wFlags & CEDB_PROPNOTFOUND) ? 0 :pVals[ipropSignalStrength].val.ulVal;
    uSignalStrengthRaw = (pVals[ipropSignalStrengthRaw].wFlags & CEDB_PROPNOTFOUND) ? 0 :pVals[ipropSignalStrengthRaw].val.ulVal;
    cActiveCalls = (pVals[ipropIconCallCount].wFlags & CEDB_PROPNOTFOUND) ? 0 :pVals[ipropIconCallCount].val.ulVal;
    uInputState = (pVals[ipropInputState].wFlags & CEDB_PROPNOTFOUND) ? 0 : pVals[ipropInputState].val.ulVal;
    uNotify = (pVals[ipropNotify].wFlags & CEDB_PROPNOTFOUND) ? 0 : pVals[ipropNotify].val.ulVal;
    uSynchronize = (pVals[ipropSynchronize].wFlags & CEDB_PROPNOTFOUND) ? 0 : pVals[ipropSynchronize].val.ulVal;
    uBluetooth = (pVals[ipropBluetooth].wFlags & CEDB_PROPNOTFOUND) ? 0 : pVals[ipropBluetooth].val.ulVal;
    uSpeakerphone = (pVals[ipropSpeakerphone].wFlags & CEDB_PROPNOTFOUND) ? 0 : pVals[ipropSpeakerphone].val.ulVal;
    uCellSystemAvailable = (pVals[ipropCellSystemAvailable].wFlags & CEDB_PROPNOTFOUND) ? 0 : pVals[ipropCellSystemAvailable].val.ulVal;
    uCellSystemConnected = (pVals[ipropCellSystemConnected].wFlags & CEDB_PROPNOTFOUND) ? 0 : pVals[ipropCellSystemConnected].val.ulVal;
    uWiFi = (pVals[ipropWiFi].wFlags & CEDB_PROPNOTFOUND) ? 0 : pVals[ipropWiFi].val.ulVal;
    uPhoneStatusEx = (pVals[ipropPhoneStatusEx].wFlags & CEDB_PROPNOTFOUND) ? 0 : pVals[ipropPhoneStatusEx].val.ulVal;

    //If we are in data call assume that connected flag is set
    ASSERT( ((uPhoneStatus & PSF_DATA_CALL) && uCellSystemConnected) || (!(uPhoneStatus & PSF_DATA_CALL) && !uCellSystemConnected) );
    ASSERT( ((uPhoneStatus & PSF_GPRS_CONNECTION) && 
            (uCellSystemConnected & (CSCF_GPRS | CSCF_EDGE | CSCF_HSDPA | CSCF_UMTS))) 
            || (!(uPhoneStatus & PSF_GPRS_CONNECTION) && 
            !(uCellSystemConnected & ( CSCF_GPRS | CSCF_EDGE | CSCF_HSDPA | CSCF_UMTS))) 
          );
    
//...

        BOOL fCaseHit;
        fCaseHit = ((pc->uPhoneStatus == NA || (pc->uPhoneStatus != NA && ((uPhoneStatus & pc->uPhoneStatus) == pc->uPhoneStatus))) &&
                    (pc->uPhoneStatusEx == NA || (pc->uPhoneStatusEx != NA && ((uPhoneStatusEx & pc->uPhoneStatusEx) == pc->uPhoneStatusEx))) &&
                    (pc->cActiveCalls == NA || (pc->cActiveCalls != NA && NULL != pfncCallCompare && pfncCallCompare(cActiveCalls, pc->cActiveCalls))) &&
                    (pc->uBatteryStr == NA || (pc->uBatteryStr != NA && uBatteryStr >= pc->uBatteryStr)) &&
                    (pc->uBatteryFlags == NA || (pc->uBatteryFlags != NA && ((uBatteryFlags & pc->uBatteryFlags) == pc->uBatteryFlags))) &&
                    (pc->uSignalStr == NA || (pc->uSignalStr != NA && uSignalStrength >= pc->uSignalStr)) &&
                    (pc->uInputState == NA || (pc->uInputState != NA && ((uInputState & pc->uInputState) == pc->uInputState))) &&
                    (pc->uNotify == NA || (pc->uNotify != NA && ((uNotify & pc->uNotify) == pc->uNotify))) &&
                    (pc->uSynchronize == NA || (pc->uSynchronize != NA && ((uSynchronize & pc->uSynchronize) == pc->uSynchronize))) &&
                    (pc->uBluetooth == NA || (pc->uBluetooth != NA && ((uBluetooth & pc->uBluetooth) == pc->uBluetooth))) &&
                    (pc->uCellSystemAvailable == NA || (pc->uCellSystemAvailable != NA && ((uCellSystemAvailable & pc->uCellSystemAvailable) == pc->uCellSystemAvailable))) &&
                    (pc->uCellSystemConnected == NA || (pc->uCellSystemConnected != NA && ((uCellSystemConnected & pc->uCellSystemConnected) == pc->uCellSystemConnected))) &&
                    (pc->uWiFi == NA || (pc->uWiFi != NA && ((uWiFi & pc->uWiFi) == pc->uWiFi)))
                   );

        ASSERT(pc->iiDestGrp < m_cIconsMax && pc->iiDestGrp >= 0
            && pc->iiDefault < m_cIconsMax && pc->iiDefault >= (int)NA); // Invalid index in table

        if (fCaseHit)
        {
            if ((dwFlags & SSDDF_BLINK_OFF) && pc->fBlink)
            {
                m_rgiIcons[pc->iiDestGrp] = pc->iBmpDefault;
            }
            else if (pc->iBmpSet == iBmpSHNotif)
            {
                if (m_iSHNotifIcon[pc->iBmpDefault] >= 0)
                {
                    // Put index of m_hilSHNotifIcons to HIWORD.
                    m_rgiIcons[pc->iiDestGrp] = (int)MAKELONG(pc->iBmpSet, m_iSHNotifIcon[pc->iBmpDefault]);
                }
            }
            else
            {
                if (pc->iBmpSet == iBmpCustom)
                {
                    // HIWORD(uInputState) is the index into m_hilCustomIcons of the icon to be displayed
                    // Put the index of m_hilCustomIcons to HIWORD.
                    m_rgiIcons[pc->iiDestGrp] = (int)MAKELONG(pc->iBmpSet, HIWORD(uInputState));
                }
                else
                {
                    m_rgiIcons[pc->iiDestGrp] = pc->iBmpSet;
                }
            }
        }

// and so on and so forth

Здравствуйте, uncommon, Вы писали:
U>Как тебе такой код? Тоже ведь работает. Зачем его рефакторить? Такой миленький кодик...
ну он работу свою делает или нет?

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

__>Здравствуйте, uncommon, Вы писали:
U>>Как тебе такой код? Тоже ведь работает. Зачем его рефакторить? Такой миленький кодик...
__>ну он работу свою делает или нет?

Еще как делает. Скрипя и пыхтя, но делает.

Здравствуйте, uncommon, Вы писали:
U>Здравствуйте, __kot2, Вы писали:
__>>Здравствуйте, uncommon, Вы писали:
U>>>Как тебе такой код? Тоже ведь работает. Зачем его рефакторить? Такой миленький кодик...
__>>ну он работу свою делает или нет?
U>Еще как делает. Скрипя и пыхтя, но делает.
ну и чего туда лезть?

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

U>>Еще как делает. Скрипя и пыхтя, но делает.
__>ну и чего туда лезть?

Например, чтобы добавить фичу

Здравствуйте, Ulin, Вы писали:
U>Здравствуйте, __kot2, Вы писали:
U>>>Еще как делает. Скрипя и пыхтя, но делает.
__>>ну и чего туда лезть?
U>Например, чтобы добавить фичу
какая фича нужна ф-ии по загрузке иконок, которая бы не добавлялась туда двумя строчками?

вы видели когда-нить ассемблерный код, который генерирует компилятор? там же вообще месиво. самый суперговнокод лучше и понятнее, чем то, что генерирует и исполняет процессор в конечном итоге. но как вы этим кодом пользуетесь? просто по интерфейсу вызова ф-ий. представьте что у вас только хэдеры есть и библиотека в качестве .lib — таким образом вы будете использовать вообще непонятно как работающий код, если на него взглянуть дизассемблером. пока у вас нет необходимости менять этот код, вам без разницы как он устроен. но менять нужно не каждый код. если код протестирован и имеет полный интерфейс то вот вам на здоровье рабочий код. менять там больше нечего — только сломаете. если вам нужна поддержка новых фич, то не стоит сразу лезть и с шашкой ее вкорячивать туда. я писал фичи даже не зная вообще как работает эта вещь. например, фича — брать данные не только из файла, а из памяти. смотрим — либо заполняем руками структуру, которая используется в итоге и отдаем ее, либо пишем MemoryFile и подменяем им их файл и спокойно читаем/пишем из памяти.
не надо сидеть и все переписывать. изменения должны быть минимальны.

	От:	__kot2
	Дата:	13.11.11 09:41
	Оценка:	75 (16) +4

	От:	alexsoff
	Дата:	13.11.11 11:16
	Оценка:

	От:	__kot2
	Дата:	13.11.11 10:06
	Оценка:	+9

	От:	Klatu
	Дата:	13.11.11 10:03
	Оценка:	2 (2) +4 -2

	От:	Lloyd
	Дата:	13.11.11 17:36
	Оценка:	2 (2) +5

	От:	vb-develop
	Дата:	13.11.11 17:26
	Оценка:	+3 -1

	От:	Loooser
	Дата:	13.11.11 11:57
	Оценка:	1 (1) +3 -1

От:	Pzz	https://github.com/alexpevzner
Дата:	13.11.11 10:47
Оценка:	1 (1) +3

	От:	alpha21264
	Дата:	13.11.11 10:25
	Оценка:	1 (1) -2

	От:	SkyDance
	Дата:	16.11.11 05:16
	Оценка:	1 (1) +2

	От:	Aviator
	Дата:	18.11.11 15:13
	Оценка:	1 (1) +2

	От:	Undying
	Дата:	14.11.11 07:47
	Оценка:	2 (1) +1

	От:	Олег К.
	Дата:	14.11.11 06:31
	Оценка:	1 (1) +1

От:	kosmik	http://www.linkedin.com/in/kosmik
Дата:	15.11.11 15:58
Оценка:	+2

От:	raydac	http://www.igormaznitsa.com
Дата:	13.11.11 09:56
Оценка:	-1

	От:	Ведмедь
	Дата:	16.11.11 10:55
	Оценка:	+1

От:	Denis Mingulov	http://denis.mingulov.com
Дата:	17.11.11 10:01
Оценка: