Здравствуйте, Кодёнок, Вы писали:
Кё>Без сомнения, критерии «хорошести» субъективны. И твоя попытка разобрать качество на примерах обречена на провал.
Я знаю. Просто хотел проиллюстрировать это на примере. Так сказать, для наглядности.
Кё>Только такая разница, картина рисуется один раз и плохую картину достаточно сжечь, а «субъективно плохой» код после определенной критической массы начнет вызывать совершенно объективную головную боль и девелоперов, и у тестеров, и у саппорта, и у маркетинга.
Так-с, похоже предмет спора тут отсутствует Мой поинт в том, что каждая хорошая картина хороша по-своему, но большинство плохих картин плохи схожими вещами...
Здравствуйте, koandrew, Вы писали:
K>По-моему, основная цель code review (помимо испольования "эффекта свежих глаз") — это сделать код понятным для всех членов конкретной команды, та самая метрика WTF/sec.
Хм. Ты имеешь в виду code review (проверку кода автором этого же кода), или же code inspection (проверку другими специалистами)? (это термины PSP/TSP). Основная цель code inspection — это поиск дефектов в коде с целью их последующего устранения. Когда это перестает быть целью, процедура попросту не окупается.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Хм. Ты имеешь в виду code review (проверку кода автором этого же кода), или же code inspection (проверку другими специалистами)? (это термины PSP/TSP). Основная цель code inspection — это поиск дефектов в коде с целью их последующего устранения. Когда это перестает быть целью, процедура попросту не окупается.
Code review в этом значении — вещь ИМХО абсолютно бесполезная. Что до code inspection — обнаружение дефектов — это side-эффект от того, что код становится понятнее (т.е. рефакторится по итогам инспекции). И как я многократно убеждался на практике, экономический эффект от понятности кода весьма существеннен сразу по ряду причин, среди которых, например, лучшая learning curve для новичка, меньшая "багоёмкость" кода, простота поддержки/модификации...
Ситуация та же средних размеров проект около полмиллиона строк кода
разрабатывается в течении десяти лет. Скорость выпуска версий где — то 2-3 в год.
Когда прищел в проект был шокирован слегка , код местами просто мясо , местами неплохо
в зависмости от квалификации разработчиков.
Понимание как рефакторить прищло не сразу, где то около года просто заваривался в каше проекта.
Главный вывод просто рассуждать на словах и что то доказывать на мелких примерах коллегам не очень реально.
Надо найти подходящий момент и выбить при планировании неплохое время для реализации какой нибудь ключевой функциональности,
что бы была возможность порефакторить. И реализовать это так чтобы полезность была просто неоспорима и очевидна коллегам.
Например мне удалось выбить полтора месяца на реализацию некоего редактора метаданных и показать на деле как можно избежать порядка нескольких десятков тысяч строк стереотипного хардкода. Прищлось конечно рискнуть и реально поднапрячся потому что график версий никто не отменял . Однако когда двумя тычками мышки ты решаешь задачу которую раньше имплементировали 2-3 дня это производит впечатление поверь.
А дальше больше , когда доверие возросло удалось выбить еще больше времени и продвинуть концепцию метаданных на весь проект. И что удивительно через некоторое время я заметил что коллеги уже сами стали сильно интересоватся как бы и им приобщится к новым веяниям.
Бывало такое — разбирался с чужим кодом, написанным за долгие годы в виде фарша.
Я считаю, что если нет времени на переписывание и изменение, то лучше смириться и работать на проекте не напрягая свои нервы.
Новые модули можно писать как считаешь нужным (многослойность, MVC, юнит-тесты), если есть такая возможность, а если её нет... ну что же, придётся писать в том же ключе, что и предыдущие авторы.
S>Однако когда двумя тычками мышки ты решаешь задачу которую раньше имплементировали 2-3 дня это производит впечатление поверь.
Одна лишь в этом проблема: кроме морального, никакого другого удовлетворения в итоге не получаешь. Испытано на собственной шкуре. Сделал за 2 недели хорошую программу, которая полностью избавила от необходимости "врукопашную" писать кучу кода, сэкономил не меньше 4х человеко-месяцев и попутно решил кучу других проблем вроде предоставления внешнего API. И что? Да ничего, даже похвалы не было.
В следующий раз геройствовать не буду. Зачем.
V>Советов тут красивых тебе могут надавать море, особенно в стиле чисто V>академических методов (SE>Путь в тысячу миль начинается с первого шага. ). V>А по сути или ты подружишься с оным челом и за бутылкой вы решите че V>делать дальше и как, либо ты его подставишь и выпрешь, либо свалишь сам.
На сей торжественной ноте, предлогаю собраться и выпить
Здравствуйте, SkyDance, Вы писали:
SD>Одна лишь в этом проблема: кроме морального, никакого другого удовлетворения в итоге не получаешь. Испытано на собственной шкуре. Сделал за 2 недели хорошую программу, которая полностью избавила от необходимости "врукопашную" писать кучу кода, сэкономил не меньше 4х человеко-месяцев и попутно решил кучу других проблем вроде предоставления внешнего API. И что? Да ничего, даже похвалы не было. SD>В следующий раз геройствовать не буду. Зачем.
И зря стратегия "Выполнить работу Не тупо", на достаточно длинных отрезках времени даст лучшие результаты в том числе и материальные в сравнении со стратегией "Выполнить работу Тупо". А самое главное такая стратегия значительно меньше корреллирует со внешними обстоятельствами.
SkyDance пишет: > > Одна лишь в этом проблема: кроме морального, никакого другого > удовлетворения в итоге не получаешь. Испытано на собственной шкуре. > Сделал за 2 недели хорошую программу, которая полностью избавила от > необходимости "врукопашную" писать кучу кода, сэкономил не меньше 4х > человеко-месяцев и попутно решил кучу других проблем вроде > предоставления внешнего API. И что? Да ничего, даже похвалы не было. > В следующий раз геройствовать не буду. Зачем.
А за что хвалить. Толпа народа спокойно просиживала штаны, потиху
плодила код, а ты их такой халявы лишил.
А если начальников тех взять, то вот сидела толпа народа, все были при
деле, плодили горы кода УПОРНО, а ту ты взял и всех подставил.
Скажи спасибо, что тебя не уволили тут же.
Здравствуйте, Vzhyk, Вы писали:
V>SkyDance пишет: >> >> Одна лишь в этом проблема: кроме морального, никакого другого >> удовлетворения в итоге не получаешь. Испытано на собственной шкуре. >> Сделал за 2 недели хорошую программу, которая полностью избавила от >> необходимости "врукопашную" писать кучу кода, сэкономил не меньше 4х >> человеко-месяцев и попутно решил кучу других проблем вроде >> предоставления внешнего API. И что? Да ничего, даже похвалы не было. >> В следующий раз геройствовать не буду. Зачем. V>А за что хвалить. Толпа народа спокойно просиживала штаны, потиху V>плодила код, а ты их такой халявы лишил. V>А если начальников тех взять, то вот сидела толпа народа, все были при V>деле, плодили горы кода УПОРНО, а ту ты взял и всех подставил. V>Скажи спасибо, что тебя не уволили тут же.
Ага, точно, это называется "Сверхкомпетентность по Питеру". Она более опасна чем Сверхнекомпетентность поэтому увольнют за нее чаще .
Здравствуйте, x64, Вы писали:
aeg>>И самое главное, что чувак не видит что все плохо.
x64>Тут, я думаю, ты ошибаешься. Всё он скорее всего видит, ну просто в лом потому что... За рефакторинг-то не платят.
нет, для того чтобы иметь хороший вкус, надо иметь образцы для подражания
Здравствуйте, StandAlone, Вы писали:
SA>Как? Да очень просто. Свой код пиши как можно лучше, а если придется фиксить какие-то участки, то отделяй их от прочего кода через какой-либо интерфейс
не совсем так. свой код выделяй через ясные API, а чужой править отказывайся
lazyrun пишет: > > > Ага, точно, это называется "Сверхкомпетентность по Питеру". Она более > опасна чем Сверхнекомпетентность поэтому увольнют за нее чаще .
Ну вот я прикололся, а оказывается, что такова жисть.
Здравствуйте, aeg, Вы писали:
aeg>Рефакторинг не сделаешь потому что он д.б. такой глобальный, что проще заново переписать.
Синдром "русского программиста". Поверь, зарефакторить все же проще по всем аспектам, особенно если "оно таки работает".
aeg>И меня каждый день охватывает тоска. У кого нибудь было похожее? Как с этим справлялись?
2 года в такой ситуевине. Из хорошого в проекте только некоторое разделение на слои. Из плохого — всё остальное. И ничего, за два года причесали, не фонтан конечно, но зато уже достаточно стабильно всё работает. Планируй рефакториг, выискивай участки, которые приводят к проблемам чаще всего и находи время приводить код в порядок.
печально конечно, но посмотри на это с другой стороны — чувак наверно сам вешается от поддержки всего этого,
люди приходят и уходят, а он изза этой обфускации кода обеспечил себя работой надолго вперед
руководству пофик на рефакторинг — главное "чтобы работало".
как ктото уже тут писал, нафик этот героизм и "учить дураков" своей жизни не хватит...
работай без фанатизма и за деньги, а свой следущий проект будешь делать по уму
Здравствуйте, aeg, Вы писали:
aeg>Пришел на проект 2 мес. назад. До этого проект писал один человек несколько лет, ну и меня взяли к нему в
Здравствуйте, aeg, Вы писали:
aeg>Но мне ведь надо добавлять/менять функциональность. Рефакторинг не сделаешь потому что он д.б. такой глобальный, что проще заново переписать. И меня каждый день охватывает тоска.
А почему она Вас охватывает?
нет, я конечно понимаю почему, сам начинал разработчиком и тут кристально ясно, что подобный код не радует и все такое.
но я вот о чем: вдумайтесь — почему именно Вас должна охватывать тоска?
разве Вы отвечаете за планирование, сроки, общее качество и т.п.?
Вам спускают запрос на добавление\изменение ф-ти — с учетом ситуации можно выдать оценку и разве Ваша вина, что учитывая положение в коде добавление не делается "2-3 кликами мыши", как кто-то писал ниже по ветке?
Нет. Пипежить за долгое добавление и хронические проблемы с качеством (а они должны быть согласно описанию положения дел) по идее будут кого-то уровнем повыше. А если не пипежат — возможно, так надо и\или пока еще жареный петух не клюнул, потому и кажется, что тишь да благодать наверху. Это ж вообще нередко центральная проблема менеджмента, что снизу часто виднее что да как, ну да стоп оффтоп. В любом случае — уже не совсем Ваш уровень.
А если есть тенденция выставления Вас крайним в процедуре пипежинья-по-цепочке — любой не-джуниор уже знает методы борьбы с такими вещами: заблаговременная, грамотная оценка с фиксацией в письменно-электронной форме. После одобрения и согласия с такими оценками шефа — работа в рамках. Можете делать рефакторинг на своем участке, можете не делать — главное в согласованных до рамках и обеспечивая требуемый результат.
Это ключевой момент.
Ибо желание помочь и благие цели — как ни странно запросто приведут к чему-то нехорошему даже в данном случае с учетом такой некрасивой картины маслом. Когда начнете свой крестовый поход за рефакторинг, не согласовав его с рук-м и другими членами команды — быть беде.
aeg>У кого нибудь было похожее? Как с этим справлялись?
у всех кто реально программировал такое было.
как справляться дали немало советов ниже по ветке.
я же хотел только добавить что ответ по поводу оптимальной стратегии в данном вопросе, возможно, следует искать немного в другом топике: Правильный ПМ или кто более ценен?
пообщайтесь и аргументированно, с цифрами и оценками в руках (да, доп работа — но инициатива всегда наказуема), попробуйте просто объяснить почему Вас обуревают такие чувства и почему это будет выгодно шефу. Если он минимально правилен — возможно, узнаете почему такие вещи в данный момент нецелесообразно затевать и вняв-поняв, успокоитесь. Или Вам дадут если не зеленый свет, то хотя бы время на подготовку своих задумок и координацию с остальными, а потом окажут минимальную поддержку и прикрытие от адептов старого кода.
В противном же случае поддержка будет как раз на их стороне, а Вам будет по ряду причин весьма тяжко.
--
потому и предлагаю: во-первых избавиться от тоски и уныния. ибо надо тут действовать хоть и с горячим сердцем но холодной головой — вместо того, чтобы позволять охватить себя чувствам и эмоциям имеет смысл продумать что можно\нужно с этим сделать и каким образом. А во-вторых — почитать соседний топик и затем уже соотносить дао из этого со своей конкретной ситуацией.
... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Мой поинт в том, что каждая хорошая картина хороша по-своему, но большинство плохих картин плохи схожими вещами...
