CEM>Вообще в IT-сообществе бытует такое мнение, что желание всё переписать — признак ущербности/незрелости. Это не так. Хотя бы потому что мир очень динамично меняется, меняются технологии и языки, переписывать всё мало того, что можно, часто это просто необходимо делать!
Все сильно зависти от предметной области и стека используемых технологий.
Здравствуйте, CEMb, Вы писали:
CEM>Вообще в IT-сообществе бытует такое мнение, что желание всё переписать — признак ущербности/незрелости. Это не так. Хотя бы потому что мир очень динамично меняется, меняются технологии и языки, переписывать всё мало того, что можно, часто это просто необходимо делать!
Есть достаточно большой опыт описанный в книгах типа In Search of Stupidity: Over Twenty Years of High Tech Marketing Disasters и вроде бы даже в статьях Джоеля Спольски, что пока вы бросили старый продукт и кинули все силы на переписывание на более лучших технологиях, конкуреты выпускают новые версии продукта и лечат старые проблемы, оставив вас к моменту выхода суперверсии без денег и без рынка.
Здравствуйте, CEMb, Вы писали:
CEM>По теме: если код достаточно модульный, а причины переписать объективные: надо переписать. CEM>Если код не модульный: надо переписать сначала на модульный. CEM>Если причины не объективные — новопассит CEM>Вообще в IT-сообществе бытует такое мнение, что желание всё переписать — признак ущербности/незрелости. Это не так. Хотя бы потому что мир очень динамично меняется, меняются технологии и языки, переписывать всё мало того, что можно, часто это просто необходимо делать!
Это самообман часто. Люди не понимают предметную область до конца ввиду ее сложности. Поэтому они говорят, что код плохой это из-за кода все непонятно. На самом деле через переписывание они попросту знакомятся с предметной областью, выбивая себе дополнительное время. Причем новички пришедшие в контору уже после переписывания будут точно так же ругать код и точно так же его переписывать.
D>С 1 числа вот копаюсь в коде, и уже три дня (когда более-менее разобрался в нём) бью себя по рукам от желания переписать ***** вообще всё.
Если принять за аксиому, что читать код сложнее чем писать, то желание нового человека переписать даже хороший код вполне объяснимо.
Я условно разделяю говнокод на два типа:
— проблема с архитектурой(бессмысленная иерархия классов, переусложнения, копи-пест)
— локальные проблемы(индусский код, невменяемые названия типов и переменных, грязь в коде, magic numbers)
Обычно оба типа идут вместе, но чего-то больше, а чего-то меньше.
Причем, если кода второго типа много, то его исправить не проще чем первого. К кривой архитектуре можно привыкнуть, если понять ее смысл.
И это достаточная причина для того, чтобы начать переписывать весь проект? На новый язык и технологию? А когда язык и технология изменится опять? Я работаю недолго. Всего лет 15. Но даже за это время в моём направлении было с десяток новых технологий, от которых народ просто прыгал от счастья, и которые не прожили и 3х лет.
D>Доктор Форум, это нормально? Это пройдёт? Надо пить Новопассит?.. Или не стоит прогибаться, надо прогибать?.. С одной стороны, я уверен, что, как я придумаю, будет всем лучше (опыты прошлых работ это показывали), но я-то один, а тут десятки умных людей с высшими образованиями.
Есть замечательный критерий. Надо попытаться оценить людей, делавших проект безотносительно кода самого проекта. Если эти не на порядок хуже, глупее, ленивее, непрофессиональнее тебя, то нет оснований считать, что получится на порядок более читаемый и поддерживаемый проект.
Здравствуйте, turbocode, Вы писали:
T>Лучше присматривай чтобы твой предшественник не прочитал твои заявления, потому что он бы точно рассказал здесь кто из вас лучше.
1. Там смайлик стоит, к своей работе надо относиться серьезно, но не надо слишком серьезно относиться к себе
2. Желание что-то переписать в проектах которые начаты 20+ лет назад — естественно и нормально
Ну и последний рубеж обороны: он по-русски не читает
Здравствуйте, уважаемый Dair, Вы писали:
D>Я тут успешно сменил работу. Теперь работаю в "крупной международной компании" (не шутка).
Поздравляю с новой работой!
D>Тут, как и везде у меня на последних местах работы, есть долгоиграющий проект, который начат годы назад, сейчас в поддерживаемом и развиваемом состоянии.
То есть, данный проект, как я понимаю, приносит вышеупомянутой компани выгоду?
Возможно, позволяет держать некую долю рынка аналогичных программных продуктов?
D>С 1 числа вот копаюсь в коде, и уже три дня (когда более-менее разобрался в нём) бью себя по рукам от желания переписать ***** вообще всё.
Знакомо! Даже очень знакомо!
У меня были аналогичные ситуации — вовремя сдержал себя от данного желания!
Просто проанализировал всё, что меня окружало, и сумел принять верное решение
D>А тут ещё общаюсь с соседними отделами, которые пишут библиотеки, которые вставляются в разные продукты, в том числе и в один из наших, так там ВООБЩЕ караул.
Опять же — знакомо
D>Доктор Форум, это нормально?
Да, вполне нормально.
D>Это пройдёт? Надо пить Новопассит?.. Или не стоит прогибаться, надо прогибать?..
Да, это пройдет. Просто, следует внимательно проанализировать причины, которые привели к данной ситуации.
Первоначально — не спешить кого-либо прогибать/нагибать. В будущем — вполне возможно, что это понадобится.
D>С одной стороны, я уверен, что, как я придумаю, будет всем лучше (опыты прошлых работ это показывали), но я-то один, а тут десятки умных людей с высшими образованиями.
Вне всяких сомнений, что будет всем лучше!
Просто, слудует выбрать правильную траекторию к этому состоянию.
D>Теряюсь.
Не нужно теряться!
Давай анализировать:
В больших компаниях — главное профит (в малых — то же самое).
Компания продаёт Программный Продукт...
Первично — впечатления Заказчика/Конечного пользователя; сроки поставки новых версий; оперативность и качество сопровождения.
Как этот продукт устроен внутри: архитектура; стиль написания кода; имена классов, интерфейсов, методов и переменных — важно, но вторично.
Ещё раз подчеркну — для Заказчика, который финансирует разработку, это вторично.
Так, например, нефункциональный либо непродуманный GUI, или отсутствии пользовательской документации, сразу бросаются в глаза Заказчику
Однако, метод класса, содержащий более тысячи строк (который просто просится разбить его на несколько методов или классов),
вероятно останется виден только для Разработчика...
Только Разработчик, будет по ночам, в кошмарном сне, представлять себе как рефакторит этого монстра!
Вывод: всё делать step-by-step. Не торопиться!
Если ты на работе превые пару недель, то пока — просто изучай проект. Набирайся в нем опыта! Пока — НЕ трогай то, что работает!
Записывай — что НЕ пронравилось в решениях по проекту.
Через полгода — исправишь!
А возможно, над какими-то замечаниями и сам посмеёшся, поняв свои заблуждения.
Ещё один совет:
приглядываться не только к коду, но и к коллегам, которые работают с тобой, или даже связаны с тобой дистанционно;
приглядываться к организации рабочих процессов в компании, к тому, как коллеги выполняют возложенные на них роли.
Вот примерно так
Здравствуйте, namespace, Вы писали:
D>>С 1 числа вот копаюсь в коде, и уже три дня (когда более-менее разобрался в нём) бью себя по рукам от желания переписать ***** вообще всё. N>Если принять за аксиому, что читать код сложнее чем писать, то желание нового человека переписать даже хороший код вполне объяснимо.
Это не аксиома, а заблуждение:
Когда писал код "тот парень", а вот читать приходится мне любимому
Заблуждение это мне знакомо — у самого часто "чешуться руки" периписать с нуля то, что сделал коллега.
Даже более того, признаюсь, если вдруг узнаешь, что до тебя этот код писала колега женского пола, то зуд в руках — удесятеряется
Просто я научился удерживать самого себя от этого.
N>Я условно разделяю говнокод на два типа: N>- проблема с архитектурой(бессмысленная иерархия классов, переусложнения, копи-пест) N>- локальные проблемы(индусский код, невменяемые названия типов и переменных, грязь в коде, magic numbers) N>Обычно оба типа идут вместе, но чего-то больше, а чего-то меньше.
Обычно, проблемы локального типа быстрее бросаются тебе в глаза, при чтении кода. Особенно, если толкового документа по архитектуре нет.
N>Причем, если кода второго типа много, то его исправить не проще чем первого. К кривой архитектуре можно привыкнуть, если понять ее смысл.
+100500
Иногда — то, что поначалу кажется "кривой архитектурой", имеет вполне конкретное объяснение и обоснование.
Это, конечно же, не делает данные решения лучше, но хотя-бы как-то объясняет причины их возникновения.
Здравствуйте, CEMb, Вы писали:
D>>Я тут успешно сменил работу. Теперь работаю в "крупной международной компании" (не шутка). CEM>У тебя же вроде была своя собственная работа?
Ты меня с кем-то путаешь. Никогда не было.
CEM>Если, да, то что заставило тебя сменить её да ещё на КМК(крупную международную компанию)?
Исключительно размер компенсации.
CEM>По теме: если код достаточно модульный, а причины переписать объективные: надо переписать.
Короче, у меня тут был разговор с руководством. Видимо, всё что есть, будем переписывать вообще с нуля, затачивая под кроссплатформенность. Видимо, на Qt.
Так что проехали — легаси будем поддерживать в том же стиле, что есть, пока не будет готова кроссплатформенная версия продукта.
Здравствуйте, AlexGin, Вы писали:
AG>Иногда — то, что поначалу кажется "кривой архитектурой", имеет вполне конкретное объяснение и обоснование.
Cовершенно верно, с учётом только того, что тот, кто может объяснить и обосновать, может уже давно в компании не работать
Здравствуйте, AlexGin, Вы писали:
D>>Я тут успешно сменил работу. Теперь работаю в "крупной международной компании" (не шутка). AG>Поздравляю с новой работой!
Спасибо!
D>>Тут, как и везде у меня на последних местах работы, есть долгоиграющий проект, который начат годы назад, сейчас в поддерживаемом и развиваемом состоянии. AG>То есть, данный проект, как я понимаю, приносит вышеупомянутой компании выгоду?
Ну таааак. Основная прибыль компании от продажи разных b2b-продуктов. При этом есть один (технически два, но под одним названием) b2c-продукт, который (цитирую некоего менеджера от коммерции повышенного звена в этой компании) "был зачат по пьяни, школу как-то заканчивает, и надо выбирать, в какой вуз отправлять". То есть, люди взяли профессиональные продаваемые инструменты и на их базе сделали консюмерский продукт.
По их словам, у них есть сотни тысяч установок и отличный от нулевого ARPU. Компания хочет увеличить долю b2c'шной прибыли. Из проекта по разным причинам ушли лиды и большая часть команды, а тут руководство всполошилось "ай, мы теряем людей, техдир, срочно ищи, вот деньги". Техдир нашёл меня.
AG>Возможно, позволяет держать некую долю рынка аналогичных программных продуктов?
Они про себя гордо говорят что 25%, я не знаю, насколько это правда. Довольно нишевый продукт.
AG>Просто проанализировал всё, что меня окружало, и сумел принять верное решение
Ну, вот, я сдерживаюсь. И это нормально получается, но "умище, умище-то куда девать?"
D>>Доктор Форум, это нормально? AG>Да, вполне нормально.
Спасибо, доктор!
AG>Давай анализировать: AG>В больших компаниях — главное профит (в малых — то же самое). AG>Компания продаёт Программный Продукт... AG>Первично — впечатления Заказчика/Конечного пользователя; сроки поставки новых версий; оперативность и качество сопровождения. AG>Как этот продукт устроен внутри: архитектура; стиль написания кода; имена классов, интерфейсов, методов и переменных — важно, но вторично. AG>Ещё раз подчеркну — для Заказчика, который финансирует разработку, это вторично.
AG>Так, например, нефункциональный либо непродуманный GUI, или отсутствии пользовательской документации, сразу бросаются в глаза Заказчику AG>Однако, метод класса, содержащий более тысячи строк (который просто просится разбить его на несколько методов или классов), AG>вероятно останется виден только для Разработчика... AG>Только Разработчик, будет по ночам, в кошмарном сне, представлять себе как рефакторит этого монстра!
AG>Вывод: всё делать step-by-step. Не торопиться! AG>Если ты на работе первые пару недель, то пока — просто изучай проект. Набирайся в нем опыта! Пока — НЕ трогай то, что работает!
Работаю с 1 ноября. Вот, пошли вторые пара недель
AG>Записывай — что НЕ пронравилось в решениях по проекту. AG>Через полгода — исправишь! AG>А возможно, над какими-то замечаниями и сам посмеёшся, поняв свои заблуждения.
Годно, спасибо. Надо начать.
AG>приглядываться не только к коду, но и к коллегам, которые работают с тобой, или даже связаны с тобой дистанционно; AG>приглядываться к организации рабочих процессов в компании, к тому, как коллеги выполняют возложенные на них роли.
Это мне необходимо делать просто по должностным обязанностям техлида.
AG>Успехов на новом рабочем месте, уважаемый Dair!
Спасибо!
Здравствуйте, De-Bill, Вы писали:
DB>Есть замечательный критерий. Надо попытаться оценить людей, делавших проект безотносительно кода самого проекта. Если эти не на порядок хуже, глупее, ленивее, непрофессиональнее тебя, то нет оснований считать, что получится на порядок более читаемый и поддерживаемый проект.
Сложно оценить тех, кто начинал проект с нуля и писал его пять лет, а потом уволился.
Код можно, да.
Здравствуйте, De-Bill, Вы писали:
DB>Есть замечательный критерий. Надо попытаться оценить людей, делавших проект безотносительно кода самого проекта. Если эти не на порядок хуже, глупее, ленивее, непрофессиональнее тебя, то нет оснований считать, что получится на порядок более читаемый и поддерживаемый проект.
Профессионализм понятие о-о-о-о-чень растяжимое.
Вот случай из конкретно моей практики: проект начат ~25 лет назад на чистом анси-С, лет 10 назад перекочевал на С++. В проекте основа: БД и компилятор, т.е. можно сказать по определению писали не глупые люди, но сейчас им уже по 60+ лет, а в 60 лет довольно тяжело осваивать новые технологии и воспринимать новые отраслевые стандарты программирования, особенно если они по 20-30 лет не меняли работу.
Читабельность/поддерживаемость тоже очень субъективный фактор. То, что было нормально 20 лет назад, сейчас считается плохим тоном.
Здравствуйте, De-Bill, Вы писали: DB>Есть замечательный критерий. Надо попытаться оценить людей, делавших проект безотносительно кода самого проекта. Если эти не на порядок хуже, глупее, ленивее, непрофессиональнее тебя, то нет оснований считать, что получится на порядок более читаемый и поддерживаемый проект.
+ я еще дарю экспресс-критерий оценки качества кода, который можно сделать почти мгновенно без всякого интрументария
процент говна = % файлов содержащих внутри слова helper и util
и при рефакторинге и прочем переписывании надо иметь в виду, что внутри той же команды качество неизменно. сколько бы они не переписывали, лучше не становится. лучше, возможно, может стать, когда это бует делать другая команда
Здравствуйте, turbocode, Вы писали:
D>>>Теряюсь. K>>Почему? Просто когда фиксишь баги начинай проводить небольшой рефакторинг который сильно не влияет на соседний модули, а фичи изолируй и пиши уже в нормальном виде.
T>Баги нужно срочно фиксить максимум за два часа.
Если багу можно починить за 2 часа, то код в котором эта бага относительно хорошо написан чтобы его понять, внести правку, оттестировать и проревьювить.
. Часто тут такое спрашивают. Резюме: L>>- Спрашивать в деталях, что за проект и в каком он состоянии до оффера
DP>Для реально крупного проекта в большой компании это не работает (за исключением пункта 1, и то — не всегда можно углубиться в детали на собеседовании).
Что же то тогда работает?
Хоть и незнаю, что имеется ввиду под "реально крупный проект в большой компании" (мб вы про Microsoft Windows?), но последний пункт — изучать код ->
спрашивать у коллег -> создавать свою базу знаний, доселе работал.
D>Доктор Форум, это нормально? Это пройдёт? Надо пить Новопассит?.. Или не стоит прогибаться, надо прогибать?.. С одной стороны, я уверен, что, как я придумаю, будет всем лучше (опыты прошлых работ это показывали), но я-то один, а тут десятки умных людей с высшими образованиями.
предлагаю атаковать
напади на них
выпотроши весь код втихую сам
а потом покажи как надо, унизь всех
Здравствуйте, Antidote, Вы писали:
mgu>>Это менталитет. Ничего личного, я сам такой и каждый раз, приступая к новому проекту, я хватаюсь за пистолет. Ни у кого больше я не видел позывов "разрушим до основанья, а затем", даже у потомков маоистов.
A>Причём тут менталитет? У нас австрал такой был. Нарушил много
Статистическая погрешность.
mgu>> Если что, мой код по всем параметрам лучше,
A>Вот это здорово, Дартаньяны одобря
По объективным признакам -- функциональность та же, а объём -- в разы, производительность -- в десятки раз...
mgu>>поэтому я выслушиваю претензии из цикла "так не пишут", "другим не понять" и т. п..
A>А вот это очень важно, "гениальные" поделки придётся править и поддерживать обычным людям. Обычно непонятный запутанный код пишут студенты, чтобы "круто"
"Обычным людям" непонятна многопоточность и регулярные выражения. Да чего уж там, они не используют тернарные операторы и инкременты, а с приоритетом операций совсем туго, вот и лепят скобки.
mgu>>Я сам сижу сейчас на подобной куче, и мне уже попало за применение тернарного оператора.
A>Слабая команда?
Это ещё сильная, я видывал похуже.
A>Становиться значимой фигурой в конторе, к которой прислушиваются, и потихоньку менять мир к лучшему Простых рецептов тут нет.
Я, может, местами и д'Артаньян, но уж точно не дон Кихот.
У нас австрал такой был. Нарушил много 
