Я думаю все помнят этот анекдот с длинной бородой:
Сидит программист глубоко в отладке.
Подходит сынишка:
— Папа, почему солнышко каждый день встает на востоке, а садится на западе?
— Ты это проверял?
— Проверял.
— Хорошо проверял?
— Хорошо.
— Работает?
— Работает.
— Каждый день работает?
— Да, каждый день.
— Тогда ради бога, сынок, ничего не трогай, ничего не меняй!!!
Так вот. Я не раз бывал на месте этого программиста, когда-то что-то блин изменил и все упало и три часа возишься, чтобы оно заработало. В это время QA и менеджеры прибегают и рвут на себя волосы, крича, то, что ты зараза весь проект своими фиксами завалил.
На самом деле, эта одна из самых моих нелюбимых фраз (от программистов) что-нибудь типа «Не трогай это, оно очень ненадежное/сложное».
Собственно говоря, как только есть такая фраза, то это значит, что в engineering есть серьезные проблемы. И вероятнее всего на проекте нету достаточно хорошего программиста.
Пожалуй сразу оговорюсь, если это legacy система, которая доживает свои последние дни, то фиг с ним, действительно трогать наверное не стоит. Однако, чаще всего такое произносят о какой-то части кода для проекта в самом расцвете сил.
Итак, почему мне это не нравиться?
— Во первых, если какая часть ненадежная, то чаще всего ее боятся серьезно менять и все изменения в ней делают не архитектурные, а заплаточные. И самом собой от этого надежность и понятность этого места только продолжает падать.
— Во вторых, почему-то этими самым ненадежными местами оказываются критические части функциональности. И это не самая хорошая идея иметь ненадежную критическую функциональность.
— В третьих. В один прекрасный день за три дня до релиза оказывается, что таки что-то надо менять, и все в испуге и испарине пытаются слепить очередной фикс.
Так вот, я считаю, что такие вот ненадежные и непонятные куски нужно как раз атаковать в первую очередь. Да, чаще всего первые несколько недель это очень болезненно, так как при изменениях оно падает то с одной стороны, то с другой стороны и набиваются множество шишек.
Зато, по окончанию этого времени, чаще всего уже становится понятно как оно работает, слегка перепланирования архитектура, счищается толстый слой заплаток и т.п.
А для тех, кому таки не по себе эти изменения, не забывайте что есть система контроля версий и идеально если еще есть и unitTest’ы (их кстати, можно и написать если их нет). После чего изменения даже в самой запустанной системе не так страшны, как их рисуют.
рефакторинг процесс необходимый на любом этапе жизненного цикла ПО. разве что жизненный цикл завершился, хотя даже в этом случае иногда можно отрефакторить систему, если есть свободные ресурсы. кстати, такие «умершие» проекты являются прекрасным подспорьем для задействования простаивающих людей или тренинга ньюблов. другое дело, что рефакторинг большой legacy системы без предварительного ее исследования на предмет выявления точек рефакторинга, оценки трудоемкости и планирования обречен на неудачу.
Не знаю, не люблю я тренировку на кошечках…. Все таки одно дело в реальных условиях решать реальные задачи, а другое дело что-то делать с умершими проектами.
Людям все равно что там случиться с умершим проектом. А значит. если все равно, то особо и стараться не будут. И так мотивация сложная штука… а мотивировать работать над ненужным куском кода — будет сложно.
Как по мне, уж лучше если излишки ресурсов образуются — то их вкладывать в написании библиотек, которые могут потом быть применены.
Хотя, конечно речь шла не столь о методах решения проблемы (рефакторинг), сколько о самой проблеме — боязне сложно и плохого кода.
Как на меня — рефакторинг решает такие вопросы. Это очень важный этап (лично для меня) в разработке веб-проекта. Когда функционал уже есть нужный, но не нравится код или участки кода. Тогда я просто разворачиваю копию проекта рядом и начинаю переделывать в свое удовольствие.
Маленькое замечание — речь идет о своих проектах. Врядли в проектах под заказ такое возможно. Ибо когда я переписываю — я не спешу, меня никто не подгоняет — я знаю, что делаю для себя и «на века» 🙂
Да, на чужих проектах в свое удовольствие редко удается работать. Для большинства заказчиков рефакторинг фактически ассоциируется с фразой бесполезная трата денег.
Кстати, меня достаточно сильно удивляет, что профилактику машины люди вполне проводят и если трубы дома начали подтекать то их меняют, а вот с кодом — тоже самое заказчики не слишком хотят делать. Я бы сказал, что это происходит из-за того, что им визуально не видно проблем и что считается, что код в отличии от авто или труб в доме — не гниет.
Потому что проблемы с архитектурой работающего код не так заметны, как протекающие трубы, или стучащий двигатель…
И чтобы сделать эти проблемы заметными, необходима… архитектура 🙂 Дающая возможность снимать показатели производительности, сложности и отказоустойчивости. Замкнутый круг? Для дешовых проектов — да. Для дорогих, с высокими требования к отказоустойчивости и производительности — нет.
И заказчик правильно делает, что не платит за НЕНУЖНОЕ ему качество. В свою очередь, вы, Виктор, НЕПРАВИЛЬНО делаете, что чешете все проекты под одну гребенку — и дешовые, и дорогие 🙂
Да, я собственно говоря особо и не гребу по дребенку.
Согласен, что для дорогих продуктов гораздо чаще заказчики решают серьезно контролировать качество.
Насчет, того, что для дешевых продуктов оно и не нужно. Это вопрос достаточно спорный. С чем я не буду спорить, это с тем, что для каждого продукта есть приемлемый уровень качаства. Естественно для заказчика бесполезно платить за ненужное качество, но вот за нужное — платить стоит.
Вы очень точно описали проблему — заказчики толком не могут измерять качества, поэтому чисто субъективно все оценивают.
А может проще копии рабочих программ в архив забивать, а с тем что есть (копия) тогда и возиться, а?
Система контроля версий = умный архив 🙂
Об этом я и говорю, что если есть архив, то чего бояться то.
А как добавить Вас в закладки, чтобы читать в програме fast reader?
Погляжу — отпишу. Не обещаю, что на этой недели, она горячаю, но на следующей постараюсь.
Кстати, просьба, оставьте какой-то ответный комментарий на этот.
Так просто, проверка на спамность.
Это точно спам. Прошло по нескольким блогам 🙂
[…]Потом идём на Блог об IT бизнесе, а нам там сразу: «Итак, почему мне это не нравиться?»… Желая отвлечься от технических подробностей, идём к[…]
Да, а анекдот как нельзя долее в тему к данному посту!
Потому что проблемы с архитектурой работающего код не так заметны, как протекающие трубы, или стучащий двигатель…
И чтобы сделать эти проблемы заметными, необходима… архитектура Дающая возможность снимать показатели производительности, сложности и отказоустойчивости. Замкнутый круг? Для дешовых проектов — да. Для дорогих, с высокими требования к отказоустойчивости и производительности — нет.