Пришел на проект 2 мес. назад. До этого проект писал один человек несколько лет, ну и меня взяли к нему в помощь. Более менее разобравшись с кодом, начал удивляться как это ваще работает?! Мягко говоря код не очень. На попытки донести мысль как правильно, получаю ответ "это же работает". Из недостатков: очень высокая связность, совсем нет DAL (код вызова хранимок тонким слоем размазан по классам БЛ), невозможность юнит-тестирования (следствие связности), отсутствие MVC|MVP на вебморде, свои велосипеды ну и т.д. Короче все признаки плохого кода. Но мне ведь надо добавлять/менять функциональность. Рефакторинг не сделаешь потому что он д.б. такой глобальный, что проще заново переписать. И меня каждый день охватывает тоска. У кого нибудь было похожее? Как с этим справлялись?
Здравствуйте, aeg, Вы писали:
aeg> Как с этим справлялись?
я сейчас в положении первого товарища, который заварил эту кашу. Из-за специфики заказчика (которому надо все и сразу) и бесполезности любых доков (когда на следующий день после согласования спеки они просят совсем левое, а потом еще присылают через неделю левые мокапы) и жутких сроков пришлось пилить все очень быстро, а временами вносить изменения в aspx/cs файлы в блокноте (т.к. под рукой не было компа со студией). Итого — пациент, которого ты описал. Сейчас когда проект начал работать (+ я таки вбил в голову заказчику что спешка не есть гуд) и поток требований упала я неспеша переписываю кусочки один за одним, немного помогает.
If the message above is in English — means I'm wasting my work time and work computer to post here. No hard feelings
Здравствуйте, Niemand, Вы писали:
N>я сейчас в положении первого товарища, который заварил эту кашу. Из-за специфики заказчика (которому надо все и сразу) и бесполезности любых доков (когда на следующий день после согласования спеки они просят совсем левое, а потом еще присылают через неделю левые мокапы) и жутких сроков пришлось пилить все очень быстро, а временами вносить изменения в aspx/cs файлы в блокноте (т.к. под рукой не было компа со студией). Итого — пациент, которого ты описал. Сейчас когда проект начал работать (+ я таки вбил в голову заказчику что спешка не есть гуд) и поток требований упала я неспеша переписываю кусочки один за одним, немного помогает.
Ну это хорошо, когда можно кусочками переписывать. У меня что-то дернешь, сломается совсем в неожиданном месте. И самое главное, что чувак не видит что все плохо. Он считает что все что я предлагаю в лучшем случае баловство
Здравствуйте, aeg, Вы писали:
aeg>И меня каждый день охватывает тоска. У кого нибудь было похожее? Как с этим справлялись?
Каждый из нас бывал в такой ситуации.
Начну с общего совета:
Путь в тысячу миль начинается с первого шага.
Приписается Лао-Цзы. Перевод с китайкого через английский.
В подобном случае я делал следующее:
1. Начинал с простейших рефакторингов вроде переменования метода, выделения метода, выделения класса и т.д. Вероятность багов для этих рефакторингов невелика. Но все-же будьте предельно внимательны.
2. Для каждого затребованного изменения я требовал время на ознакомление и реализовал новую функциональнось. Важно, что я реализовал минимально необходимую ее часть.
3. Новую функциональность уже можно тестировать. Ну, вы поняли...
4. Всякое очередное изменение просто цеплялось к новой функциональности.
Как правило, такие небольшие изменения дают возможность удалить тысячи строк. Такие вещи производят неизгладимое впечатление на менеджеров.
Правила форума нарушены.
— оверквотинг
Правила можно найти в разделе FAQ данного форума и\или ресурса.
Нарушение правил может повлечь за собой санкции, описанные там же — модератор
SE>Удачи.
Спасибо.
Но тут еще момент. После моего добавления некоей функциональности, чувак потом правит мой код на свой лад, причем все это как-то аргументируя. И самое обидное, что не хочет понимать моих доводов. Т.е. ты пишешь пишешь, все стройно, а потом он всобачивает какую то ф-ю которая д.б. совсем в другом месте, и другой код на нее завязывает. Приехали блин.
aeg пишет: > > > Пришел на проект 2 мес. назад. До этого проект писал один человек > несколько лет, ну и меня взяли к нему в помощь.
<skip> > день охватывает тоска. У кого нибудь было похожее? Как с этим справлялись?
Советов тут красивых тебе могут надавать море, особенно в стиле чисто
академических методов (SE>Путь в тысячу миль начинается с первого шага. ).
А по сути или ты подружишься с оным челом и за бутылкой вы решите че
делать дальше и как, либо ты его подставишь и выпрешь, либо свалишь сам.
Здравствуйте, aeg, Вы писали:
aeg>Но тут еще момент. После моего добавления некоей функциональности, чувак потом правит мой код на свой лад, причем все это как-то аргументируя. И самое обидное, что не хочет понимать моих доводов. Т.е. ты пишешь пишешь, все стройно, а потом он всобачивает какую то ф-ю которая д.б. совсем в другом месте, и другой код на нее завязывает. Приехали блин.
Если ему удается аргументировать свои изменения, а вам не удается предложить решение более хорошее, то он прав, как бы это неприятно не звучало.
Поверьте, рядом со мной работает некоторое количество джуниоров, они часто творят такое, что просто плакать хочется. На самом деле это от того, что они не видят способа более лучшего.
Если Вашего авторитета не хватает, чтобы даже с хорошей аргументацией повлиять на решение, Вы должны эскалировать проблему, если потребуется до самого верхнего уровня.
Иногда удается провести свои предпочтения в жизнь, иногда все заканчивается переходом на другой проект. В моей практике были случаи, когда все заканчивалось моим увольнением, а иногда увольняли моего оппонента. Выыод который я сделал для себя из всего этого — моя жизнь слишком короткая, чтобы решать проблемы дураков. Ее едва хватит (или не хватит) на то, что бы сделать счастливым одного единственного дурака — меня самого.
Здравствуйте, SE, Вы писали:
SE>Иногда удается провести свои предпочтения в жизнь, иногда все заканчивается переходом на другой проект. В моей практике были случаи, когда все заканчивалось моим увольнением, а иногда увольняли моего оппонента.
ага, уволят разработчика этой системы и оставят новичка. моё мнение — товарищу не повезло по жизни, надо оттуда валить ибо учить его бесполезно
Здравствуйте, aeg, Вы писали:
aeg>Пришел на проект 2 мес. назад. До этого проект писал один человек несколько лет, ну и меня взяли к нему в помощь. Более менее разобравшись с кодом, начал удивляться как это ваще работает?! Мягко говоря код не очень. На попытки донести мысль как правильно, получаю ответ "это же работает". Из недостатков: очень высокая связность, совсем нет DAL (код вызова хранимок тонким слоем размазан по классам БЛ), невозможность юнит-тестирования (следствие связности), отсутствие MVC|MVP на вебморде, свои велосипеды ну и т.д. Короче все признаки плохого кода. Но мне ведь надо добавлять/менять функциональность. Рефакторинг не сделаешь потому что он д.б. такой глобальный, что проще заново переписать. И меня каждый день охватывает тоска. У кого нибудь было похожее? Как с этим справлялись?
Лучше валить побыстрее, имхо. Проект который писался несколько лет переписать невозможно, даже вдвоем.
P.S.: Недавно на работе досталось временно дописывать небольшой вспомогательный проект после того как его автор ушел. Автор был весьма неплохой специалист, но по каким то причинам написал такую фигню... Договорился с менеджером покрыть тестами и отрефакторить прежде чем вносить изменения. Работал по 10 часов в день в течении месяца, сделал конфетку. В 2-3 раз меньше кода, удачная декомпозиция, исправлено несколько серьезных дефектов, 90% покрыто тестами, куча проверок и осмысленных сообщений об ошибках. Теперь взяли нового чела работать над этим проектом дальше, за время "передачи знаний" возникло ощущение что скоро моему подвигу придет писец. Не судьба.
Похоже ваш напарник считает себя полным хозяином системы. Тяжелый психологический фактор при разработке.
Раз он отрицает любые ваши предложения с самого начала проекта, то будет их отрицать и дальше.
И более того, воспринимать их как личное оскорбление. Ведь вы посягнули на святое! На его СамоЁ творение.
К сожалению, убедить его вам не удасться.
Скорее всего начальство вообще не разбирается в вашей системе, но его за что-то (до поры) ценит.
Поэтому не заинтересовано в каких-либо рефакторингах.
В этой ситуации скорее всего придется мириться с "дуростью" напарника.
По прошествии некоторого времени попросить выделить вам отдельный кусок проекта.
Увольняться сразу не надо. Попробуйте все таки потихоньку "отвоевать" часть проекта под себя.
Не получится — ну тогда уходить или вас уйдут.
На прошлой работе была подобная ситуация. Когда я туда пришел, опыта ООD почти не было, поэтому сначала принимал как есть (никаких слоев нет, все на датасетах и т.д.) до тех пор, пока не набрался необходимых знаний, после чего периодически стал заводить разговоры с ведущим разработчиком о развитии системы. С третьего захода получилось Смог привести кучу аргументов за новшества, косяки текущего подхода и возможные последствия. Поэтому учись вести переговоры, ибо работа программера — это не только писать программы, но и общаться с другими участниками разработки, поэтому умение общаться и продвигать свои идеи — весьма актуальный навык.
Здравствуйте, aeg, Вы писали:
aeg>На попытки донести мысль как правильно, получаю ответ "это же работает".
Донеси до него мысль, что у программиста нет проблемы «работает/не работает». Делать чтоб работало учат в университете. Если человек не может сделать чтобы работало, он вообще не программист. Гордиться тем, что код работает — это смешно.
Если «он работает» — это все, что можно сказать про код, это значит, что он наихудшего возможного качества. И по-хорошему, оплачиваться должен стажерской зарплатой. Качество кода определяется наличием дополнительных положительных качеств, например
— легко читается
— хорошо структурирован (модули можно переносить в другие проекты без изменений, тестировать по отдельности и пр.)
— легко тестируется
— исправления багов не вносят новые, исправленные баги не возвращаются
— отсутствие таинственных и неуловимых багов (типа случающихся раз в месяц)
— максимально прост и чист, без забытых неиспользуемых кусков, методов, модулей
— хорошо переносит изменения
Здравствуйте, aeg, Вы писали:
aeg> У кого нибудь было похожее? Как с этим справлялись?
Было. Тот парень должно быть устал от этого проекта уже хуже горькой редьки и всю работу делает по принципу "работает и ладно, только отстаньте". Твои текущие задачи:
1) Смирить гордыню и самомнение. Принять и понять код таким какой он есть и полноценно освоить его.
2) Сделать возможным переключение твоего напарника на более интересные проекты
3) Оставшись одному вздохнуть, засучить рукава и навести порядок.
Всё просто Удачи.
Здравствуйте, aeg, Вы писали:
aeg>Пришел на проект 2 мес. назад. До этого проект писал один человек несколько лет, ну и меня взяли к нему в помощь. Более менее разобравшись с кодом, начал удивляться как это ваще работает?! Мягко говоря код не очень. На попытки донести мысль как правильно, получаю ответ "это же работает". Из недостатков: очень высокая связность, совсем нет DAL (код вызова хранимок тонким слоем размазан по классам БЛ), невозможность юнит-тестирования (следствие связности), отсутствие MVC|MVP на вебморде, свои велосипеды ну и т.д. Короче все признаки плохого кода. Но мне ведь надо добавлять/менять функциональность. Рефакторинг не сделаешь потому что он д.б. такой глобальный, что проще заново переписать. И меня каждый день охватывает тоска. У кого нибудь было похожее? Как с этим справлялись?
Нормальная рабочая ситуация. Есть много старого кода, не очень, мягко говоря, хорошего, и надо сделать из него конфетку.
Как? Да очень просто. Свой код пиши как можно лучше, а если придется фиксить какие-то участки, то отделяй их от прочего кода через какой-либо интерфейс и тоже пиши как можно лучше.. Вообще, всегда надо стараться писать как можно лучше. Это улучшает карму и прочищает чакры.
Подробнее здесь
P.S.А бежать, как насоветовали, не надо. Во-первых, только победив старого кода дракона, станет юный падаван джедаем настоящим!
И во-вторых, не факт, что на новом месте будет лучше
Здравствуйте, Кодёнок, Вы писали:
Кё> Кё>- легко читается Кё>- хорошо структурирован (модули можно переносить в другие проекты без изменений, тестировать по отдельности и пр.) Кё>- легко тестируется Кё>- исправления багов не вносят новые, исправленные баги не возвращаются Кё>- отсутствие таинственных и неуловимых багов (типа случающихся раз в месяц) Кё>- максимально прост и чист, без забытых неиспользуемых кусков, методов, модулей Кё>- хорошо переносит изменения
Большая часть вышеприведённых признаков весьма субъективна. А обсуждать "сферический код в вакууме бессмысленно"...
Здравствуйте, koandrew, Вы писали:
K>Большая часть вышеприведённых признаков весьма субъективна. А обсуждать "сферический код в вакууме бессмысленно"...
Само собой. Если бы они были объективны, не существовало бы такой вещи, как code review. Любой code monkey мог бы взять список признаков и объективно оценить качество. Не было бы плохих и хороших программистов.
Проблемы с субъективностью только у тех, кто не может отличить хорошее от плохого.
Здравствуйте, Кодёнок, Вы писали:
Кё>Само собой. Если бы они были объективны, не существовало бы такой вещи, как code review. Любой code monkey мог бы взять список признаков и объективно оценить качество. Не было бы плохих и хороших программистов.
По-моему, основная цель code review (помимо испольования "эффекта свежих глаз") — это сделать код понятным для всех членов конкретной команды, та самая метрика WTF/sec. Она не обязательно сделает код хорошим, ибо во-первых, из понятности кода для тима не следует понятность кода для любого девелопера вообще (и дело тут не в квалификации — очень часто специфика области сказывается), а во-вторых, понятность кода является необходимым, но не достаточным условием его "хорошести".
Если же отвлечься от теории и обратиться к практике, при написании кода я стараюсь придерживаться принципа наименьшего удивления (т.е. минимизация метрики WTF/sec). Это не делает код хорошим, но облегчает работу с ним — как чтение, так и модификацию.
Кё>Проблемы с субъективностью только у тех, кто не может отличить хорошее от плохого.
Это-то как раз и не проблема — проблема в том, что у каждого своё понятие "хорошего" и "плохого". Ну и небольшой тест-пример — есть два варианта кода:
if (File.Exists(fileName))
{
//do something
}
if (File.Exists(fileName) == true)
{
//do something
}
Здравствуйте, koandrew, Вы писали:
K>это сделать код понятным для всех членов конкретной команды K>что у каждого своё понятие "хорошего" и "плохого"
Метафора. Код — как картина, хороший художник без проблем распознает коллегу по почерку, и они безусловно сойдутся во мнении, что является бездарным (хотя могут заспорить о том, какая картина из двух лучше). Программист, который ограничивается работоспособностью, все равно что художник, заявляющий «ну я же нарисовал человека? нарисовал! что еще надо-то?!». Без сомнения, критерии «хорошести» субъективны. И твоя попытка разобрать качество на примерах обречена на провал.
Только такая разница, картина рисуется один раз и плохую картину достаточно сжечь, а «субъективно плохой» код после определенной критической массы начнет вызывать совершенно объективную головную боль и девелоперов, и у тестеров, и у саппорта, и у маркетинга.
Здравствуйте, Кодёнок, Вы писали:
Кё>Без сомнения, критерии «хорошести» субъективны. И твоя попытка разобрать качество на примерах обречена на провал.
Я знаю. Просто хотел проиллюстрировать это на примере. Так сказать, для наглядности.
Кё>Только такая разница, картина рисуется один раз и плохую картину достаточно сжечь, а «субъективно плохой» код после определенной критической массы начнет вызывать совершенно объективную головную боль и девелоперов, и у тестеров, и у саппорта, и у маркетинга.
Так-с, похоже предмет спора тут отсутствует Мой поинт в том, что каждая хорошая картина хороша по-своему, но большинство плохих картин плохи схожими вещами...
Здравствуйте, 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.
Здравствуйте, Valery A. Boronin, Вы писали:
VAB>Здравствуйте, aeg, Вы писали:
aeg>>Но мне ведь надо добавлять/менять функциональность. Рефакторинг не сделаешь потому что он д.б. такой глобальный, что проще заново переписать. И меня каждый день охватывает тоска. VAB>А почему она Вас охватывает?
VAB>нет, я конечно понимаю почему, сам начинал разработчиком и тут кристально ясно, что подобный код не радует и все такое.
VAB>но я вот о чем: вдумайтесь — почему именно Вас должна охватывать тоска? VAB>разве Вы отвечаете за планирование, сроки, общее качество и т.п.?
VAB>Вам спускают запрос на добавление\изменение ф-ти — с учетом ситуации можно выдать оценку и разве Ваша вина, что учитывая положение в коде добавление не делается "2-3 кликами мыши", как кто-то писал ниже по ветке?
VAB>Нет. Пипежить за долгое добавление и хронические проблемы с качеством (а они должны быть согласно описанию положения дел) по идее будут кого-то уровнем повыше. А если не пипежат — возможно, так надо и\или пока еще жареный петух не клюнул, потому и кажется, что тишь да благодать наверху. Это ж вообще нередко центральная проблема менеджмента, что снизу часто виднее что да как, ну да стоп оффтоп. В любом случае — уже не совсем Ваш уровень.
т.е. правильно ли я понимаю что такоя разность во взглядах на развитие проекта со стороны разработчика и ПМ, может быть в какой то степени объяснена с мужским началом программиста, к-й хочет развородить и переделать на свой лад, а этаким полуженским началам ПМ-а который сам боиться потому что его уже пипежили в прошлом. правильно ли в таком случае поощрять ПМ-кую пассивную позицию, в то время как именно программист в таком случае является катализатором прогресса и движения вперед?
Valery A. Boronin пишет: > > > наверху. Это ж вообще нередко центральная проблема менеджмента, что > снизу часто виднее что да как, ну да стоп оффтоп. В любом случае — уже > не совсем Ваш уровень.
Вы все правильно написали. И так чаще всего и есть.
Но, проблема в том, что такая ситуация не может длиться достаточно долго
или проект свернется или контора (во многих случаях между этими двумя
вещами есть жесткая зависимость). Т.е. фактически видя такое, мы,
приходя, сразу видим, что отсюда надо будет уходить максимум через год,
а это так надоедает...
Ну и работодатель тоже не в плюсе: ну попилил он бабла здесь и сейчас, а
завтра... на бобах (потому как работодатель оный отнюдь не губернатор
Чукотки).
А в итоге, по всему местному IT единственная мотивация у работников
остается — деньги, здесь и сейчас, потому как завтра уже не будет.
> > я же хотел только добавить что ответ по поводу оптимальной стратегии в > данном вопросе, возможно, следует искать немного в другом топике: > Правильный ПМ или кто более ценен?
ИМХО, правильный ответ на вопрос выше: "Что мне надо в этой конторе?".
Вот после ответа на данный вопрос уже можно думать, что и как делать.
Здравствуйте, Vzhyk, Вы писали:
>> наверху. Это ж вообще нередко центральная проблема менеджмента, что >> снизу часто виднее что да как, ну да стоп оффтоп. В любом случае — уже >> не совсем Ваш уровень. V>Вы все правильно написали. И так чаще всего и есть.
если правильно — отчего минус?
тем более что из текста ниже вижу что у нас очень и очень схожее понимание ситуации и не вижу в чем разногласие, с чем несогласие? нет, воля Ваша, просто любопытно
V>Но, проблема в том, что такая ситуация не может длиться достаточно долго V>или проект свернется или контора (во многих случаях между этими двумя V>вещами есть жесткая зависимость). Т.е. фактически видя такое, мы, V>приходя, сразу видим, что отсюда надо будет уходить максимум через год, V>а это так надоедает...
на самом деле это уже каждый решает для себя сам. Обстоятельства — они у всех разные.
Хотя реальные специалисты действительно частенько "голосуют ногами", коли есть такая возможность.
Но, как правило, только если не умеют\не могут достучаться (подчеркну, что стучать пытаются, думается, все) до принимающих решения. Отсюда и совет разобраться (для себя) с адекватностью-правильностью шефа. Способен ли воспринять? Способен ли объяснять свои решения?
Это причем относится и к самим ПМ по отношению к своим руководителям — на каждом уровне в многоуровневых корпорациях метода работает.
V>Ну и работодатель тоже не в плюсе: ну попилил он бабла здесь и сейчас, а V>завтра... на бобах (потому как работодатель оный отнюдь не губернатор V>Чукотки).
с этим никто и не спорит.
по делам надо судить. именно поэтому не надо разработчику упреждающе устраивать снизу свой самосуд на основании неполной\недостоверной информации и некоей своей "картины мира". Не надо также и слишком беспокоиться о нерадивом хозяине, горбатого сами знаете что исправит. Жизнь — она все покажет и всем раздаст по заслугам, просто иной раз требуется время.
Уверен, что знаешь\понимаешь\умеешь все\что-то лучше — сумей донести\убедить.
А не можешь, неважно по чьей вине — лучше отойди от греха сам, не мучай ни себя, ни других.
V>А в итоге, по всему местному IT единственная мотивация у работников V>остается — деньги, здесь и сейчас, потому как завтра уже не будет.
да, такая точка зрения тоже имеет право на жизнь.
однако здесь я скажу так: мотивация у всех своя и каждый выбирает для себя сам.
и да, нам всем иногда приходится принимать достаточно жесткие решения в этой жизни.
>> >> я же хотел только добавить что ответ по поводу оптимальной стратегии в >> данном вопросе, возможно, следует искать немного в другом топике: >> Правильный ПМ или кто более ценен? V>ИМХО, правильный ответ на вопрос выше: "Что мне надо в этой конторе?". V>Вот после ответа на данный вопрос уже можно думать, что и как делать.
тоже верно. см выше. Уважаемый Вжик, а у нас точно есть разногласие?
... << 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.
Здравствуйте, Igor Sukhov, Вы писали:
VAB>>Нет. Пипежить за долгое добавление и хронические проблемы с качеством (а они должны быть согласно описанию положения дел) по идее будут кого-то уровнем повыше. А если не пипежат — возможно, так надо и\или пока еще жареный петух не клюнул, потому и кажется, что тишь да благодать наверху. Это ж вообще нередко центральная проблема менеджмента, что снизу часто виднее что да как, ну да стоп оффтоп. В любом случае — уже не совсем Ваш уровень.
IS>т.е. правильно ли я понимаю что такоя разность во взглядах на развитие проекта со стороны разработчика и ПМ, может быть в какой то степени объяснена с мужским началом программиста, к-й хочет развородить и переделать на свой лад, а этаким полуженским началам ПМ-а который сам боиться потому что его уже пипежили в прошлом. правильно ли в таком случае поощрять ПМ-кую пассивную позицию, в то время как именно программист в таком случае является катализатором прогресса и движения вперед?
господа, это что — весна пришла в наши края?
нет, это конечно тоже оченно интересная тема — определить пол профессии и т.п. моменты из серии "а поговорить?"
Но она нехило отклоняет нас от темы топика, это раз.
два — это то что в этом случае нужно говорить о наказаниях
и о дедовщине, которые имеют место много где и уже не привязаны к конкретной ПМ-или-еще-какой специфике. Для этого тоже уже есть своя ветка, замечу.
А если вернуться к оставшейся части текста: нет, я совсем не против если программист будет гордо носить лычку "катализатор прогресса", "двигатель вперед" или еще какую. Но отчего такой ярлык о пассивной позиции ПМ, откуда появился вывод о боязни и отчего программист стал знать всю стратегическую и прочую ситуацию лучше тех, кто ее иной раз даже определяет?
при том что "боится" тут на мой взгляд не совсем правильное слово. Просто уровнем выше могут лучше знать ситуацию и соотв. точнее просчитывать риски от неких рацпредложений-инициатив, иметь некий опыт (за который отпипежили, что ожидаемо повышает осторожность в будущем. \И это правильно — при. авт.\) опять же. Иногда просто бывает неподходящий момент. Разве это означает боязнь? Возможно, это вполне трезвый рачет и не надо тут искать черных кошек там где их нет. Еще раз, прошу прочесть мой посл параграф из пред сообщения: не надо скатываться на эмоции. Боязнь — из той же серии.
Отсюда вывод: правильно или нет ПМу "занимать пассивную позицию" — не ко мне вопрос и вообще кажется некорректной такая постановка, безотносительно разборок на тему что есть "пассивность". ведь ситуации и люди все разные поэтому и ответ может быть любым. Надо смотреть по обстоятельствам.
еще раз, у меня не было цели устроить флейм вида ПМ\руководство против пролетариев\разрабов или встать на чью-либо сторону возникни такой флейм. Все делаем одно дело в конечном счете, не надо тут раскачивать лодку.
Просто с точки зрения здравого смысла нужно адекватно представлять себе ситуацию с обеих сторон и желательно понимать к чему приведут хотя бы свои действия. Это ведь не так сложно, если об этом задумываться. И уже тут все начинает упираться в человеческий вопрос — тогда как у пролетариев видна концентрация на технических аспектах, что редко является действительно определяющим фактором в успехе того или иного начинания в более-менее больших командах. Об этом написаны тонны литературы, но почему-то часто нужны годы собственных мегаусилий, чтобы осознать эту простую действительность. Вот и все.
PS можно конечно попытаться быть Стахановым, но нужно иметь ввиду что за Стахановым стояла партия, со всей ее поддержкой на всех возможных уровнях и громаднейшим админресурсом.
PPS Хотя "победителей — не судят" тоже верно. Дерзайте. Но реально оценивайте риски
... << 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.
Valery A. Boronin пишет: > > V>Вы все правильно написали. И так чаще всего и есть. > если правильно — отчего минус?
Фактически с тем, что вы принимаете данность и даже довольны оным, по
крайней мере это я понял из вашего поста.
Меня же нонешняя данность (назову так "покодить и бежать") сильно
достала уже.
Мне кажется наши взгляды совпадают в понимании ситуации, но не в
отношении к ней.
> > V>Но, проблема в том, что такая ситуация не может длиться достаточно долго > V>или проект свернется или контора (во многих случаях между этими двумя > V>вещами есть жесткая зависимость). Т.е. фактически видя такое, мы, > V>приходя, сразу видим, что отсюда надо будет уходить максимум через год, > V>а это так надоедает... > на самом деле это уже каждый решает для себя сам. Обстоятельства — они у > всех разные.
Нет, я о другом. Я о том, что приходя на работу, ты уже видишь, что она
временная и заниматься тебе надо просто деятельностью. Да, это неплохо,
если цель меньше делать больше получать, но не все и не все в жизни
подчиняется этому правилу.
> > Но, как правило, только если не умеют\не могут достучаться (подчеркну, > что стучать пытаются, думается, все) до принимающих решения. Отсюда и > совет разобраться (для себя) с адекватностью-правильностью шефа.
Ох.
> > Жизнь — она все покажет и всем раздаст по заслугам, просто иной раз > требуется время.
Ага, только мы не вечны. Вспомните Воланда и его слова.
> > V>А в итоге, по всему местному IT единственная мотивация у работников > V>остается — деньги, здесь и сейчас, потому как завтра уже не будет. > да, такая точка зрения тоже имеет право на жизнь.
Ага, только почитайте, что тут пишут о мотивации программисты.
> V>ИМХО, правильный ответ на вопрос выше: "Что мне надо в этой конторе?". > V>Вот после ответа на данный вопрос уже можно думать, что и как делать. > тоже верно. см выше. Уважаемый Вжик, а у нас точно есть разногласие?
Есть в отношении к данной реальности.
Например, несмотря на то, что я понимаю ситуацию с тем же качеством, сам
не могу делать плохо (или очень недолго), а это в итоге бьет же по мне —
классический вариант принципа Питера отрабатывает. Т.е. в вышеописанной
ситуации я бы выбрал из вот этого: "А по сути или ты подружишься с оным
челом и за бутылкой вы решите че делать дальше и как, либо ты его
подставишь и выпрешь, либо свалишь сам." сначала вариант 1, а потом,
если он не проходит вариант 3, причем, учитывая написанное автором темы
дальше мой выбор был бы вариант 3.
И это при условии, что все, чего хочется, это качественно делать свою
работу и получать приемлемую зарплату за это.
>> V>Вы все правильно написали. И так чаще всего и есть. >> если правильно — отчего минус? V>Фактически с тем, что вы принимаете данность и даже довольны оным, по V>крайней мере это я понял из вашего поста.
только прошу занести в протокол я приписываемого мне выше не говорил, Вы поняли что-то свое и вполне может быть с минусом поторопились
Более того, как раз старался не распространяться о своем отношении, дабы не сбивать никого с панталыку — ведь каждый должен думать своей головой. Всего лишь обратил внимание на неупомянутые в ветке аспекты и рекомендовал их учитывать.
Люди склонны видеть одно и то же по-разному.
посему насчет "принимаю данность" лучше сказать "не имею иллюзий",
а вместо "доволен оным" — "имею опыт оного", так точнее
V>И это при условии, что все, чего хочется, это качественно делать свою V>работу и получать приемлемую зарплату за это.
понимаю и ценю подобный расклад
но в раскладе из 3х альтернатив выше исключены варианты с админресурсом и\или арбитром, как минимум.
т.е. годится для ситуации где уже никто ничего не решает\самоустранился и фактически у инженеров ситуация типа deadlock. вот и приплываем к поискам того, кто должен\способен такие вещи разруливать. Если же такового не видно — да, вот тогда стоит задуматься о своем месте на этой карте и своих способностях aquire\hold\release lock если угодно.
потому и потратил время на дополнение набора альтернатив по теме — до применения вариантов 2-3 вполне можно попробовать еще и их. Может кому пригодится.
PS Более того, не открою Америки, если скажу, что с попутным ветром в спину плыть несравненно проще, чем лавировать против ветра. И еще скажу, что это не всегда требует отказа от, например, желания честно трудиться и достойно зарабатывать. Другой вопрос что и не везде это возможно, это да.
... << 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.
Valery A. Boronin пишет: > > поняли что-то свое и вполне может быть с минусом поторопились
Минус, насколько я понимаю — это всего-лишь не согласие. Уж не
воспринимаете вы его слишком серьезно.
> > но в раскладе из 3х альтернатив выше исключены варианты с админресурсом > и\или арбитром, как минимум.
Что одно, что второе выльется или в 2 или 3 моих вариантов.
> > потому и потратил время на дополнение набора альтернатив по теме — до > применения вариантов 2-3 вполне можно попробовать еще и их. Может кому > пригодится.
Можно, но выше типичная ситуация конфликта. А как известно решение
конфликта только 3: договорились, ты победил, ты проиграл. Для
договорились, вариант с "бутылкой" наиболее быстрый и эффективный (по
затратам). Для варианта победил необходимо большое желание к
"политическим играм" и затраты. Для варианта проиграл, если нет шансов
политически переиграть или договориться (в случае начала "войны"
договориться уже будет очень сложно), выгоднее не воевать вообще.
Есть еще 4-й вариант у автора: забить на код, но он , похоже, не
приемлем по личным предпочтениям.
Заставьте художника красить заборы... чем это закончиться для художника.
> > PS Более того, не открою Америки, если скажу, что с попутным ветром в > спину плыть несравненно проще, чем лавировать против ветра. И еще скажу, > что это не всегда требует отказа от, например, желания честно трудиться > и достойно зарабатывать. Другой вопрос что и не везде это возможно, это да.
Но, в таком бы варианте никакой Америки никто бы не открыл.
Мой поинт в том, что каждая хорошая картина хороша по-своему, но большинство плохих картин плохи схожими вещами...
* thriving in a production environment *
