IT-теодицея
Jan. 23rd, 2010 05:28 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
darth_vasya![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
dragon_ru: Рассмотрим программиста, работающего над сложной программой. В процессе отладки он может посмотреть значение любой переменной (=всеведение), может поменять код, как захочет (=всемогущество). Но почему-то при всем этом он руководствуется принципом: "Работает? Ничего не меняй."В этой парадигме и грехопадение можно непротиворечиво объяснить, и всю историю с Иисусом. Создать, что ли, новую религию...
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-01-23 02:43 pm (UTC)no subject
Date: 2010-01-23 02:53 pm (UTC)no subject
Date: 2010-01-23 06:10 pm (UTC)no subject
Date: 2010-01-23 03:04 pm (UTC)устарел этот принцип :) нормальные программеры так уже не работают. Кошерно писать юнит-тесты на весь функционал, а потом менять все, что глаз режет со спокойной душой.
no subject
Date: 2010-01-23 03:41 pm (UTC)no subject
Date: 2010-01-23 04:52 pm (UTC)no subject
Date: 2010-01-25 11:00 am (UTC)А если покроешь, то потом поддерживать заколебёшься и инклуд-лист тогда разрастается со страшной силой.
Хотя, может я ненормальный программер просто :)
no subject
Date: 2010-01-26 10:12 pm (UTC)no subject
Date: 2010-01-27 06:02 am (UTC)no subject
Date: 2010-01-30 09:19 am (UTC)Фигня. У Фаулера, например, есть специальный раздел "Когда проводить рефакторинг". И он явно этому противоречит. Т.е., один из вариантов, это действительно, когда код требует изменений, которые пройдут легче после проведения рефакторинга. Но это только один из вариантов.
> Просто так делать рефакторинг себе во вред
Полная фигня. Рефакторинг - это инвестиции в будущее. Если есть код, который нуждается в рефакторинге, вреда от рефакторинга точно не будет. Другое дело, что рефакторинг надо проводить с умом, а не абы как.
> особенно если функциями (или не дай бог интерфейсами) пользуются многие
это у Фаулера называется "опубликованный интерфейс" и рецепты их рефакторинга тоже описаны. Ничего страшного в этом нет.
> и изменение-таки фунциональности
Рефакторинг - это НЕ изменение функциональности.
> и имена функций переименовывать заколебёшься (это хорошо что ИДЕ помогает, но система контроля версий затрудняет положение, а если ещё рефакторить какую-то библиотеку динамически используемую во многих проектах - уух)
Можно поподробней про систему контроля версий, которая затрудняет переименование функций? Последние года 3 работаю с Tortoise SVN, и никаких сложностей с этим не имел. Наоборот - когда кто-то меняет интерфейс, а я в данный момент времени должен иметь сборку со старым интерфейсом, я просто беру нужную мне версию.
По поводу остального - как ранее и писал, см. рецепты борьбы с опубликованными интерфейсами (читай - которые затруднительно менять) у Фаулера.
Ну и все-таки, рефакторинг, требующий изменения опубликованного интерфейса, это отдельный проблемный случай.
no subject
Date: 2010-01-30 09:22 am (UTC)Думаю, Дима под словами "просто так" как раз подразумевал код, который в рефакторинге не нуждается :)
no subject
Date: 2010-01-30 09:57 am (UTC)Мне показалось все-таки, что 2-ое предложение было логическим развитием 1-ого. Т.е., рефакторинг кода, в который очень нужно внести изменения (вследствие обнаружения ошибки или поступления новых требований) - это рефакторинг не просто так. А рефакторинг кода, в который в данный момент времени в изменениях не нуждается (т.к. багов там нет и менять функционал никто не требует), то это рефакторинг просто так, и он вреден. Вот с этим я и не согласен.
Хотя, конечно, если смысл фразы был "не надо рефакторить код, который не надо рефакторить" - ну, с Кэпом не поспоришь :)
no subject
Date: 2010-01-30 09:57 am (UTC)Однако практика показала, что несмотря на то что вроде бы функциональных изменений нет, вё равно появляются ошибки совместимости => функциональные изменения всё же есть. И новые баги. И да, пришлось объяснять на что я убил две недели работы над рефакторингом всего своего кода.
Говоришь вклад в будущее? Знаешь что стало с тем кодом? Ничего. Он так и работает. Сейчас начался новый проект и процент переиспользования того отрефакторенного кода будет порядка 5%. То есть код хороший, но в условиях повышения того же самого реюза мы решили, что мы перейдём на общие интерфейсы (написанные не нами) и вместо джаваскриптового UI будем использовать флекс.
Насчёт затруднения переименования функций с системой контроля версий - IBM Rational Clear Case Remote Client тебе в помощь. Очень плохая система.
У Фаулера в рецептах рефакотринга опубликованных интерфейсов ничего не сказано по поводу коллег возмущённых тем, что ты подкинул им дополнительной работки во имя инвестиций в будущее.
Лично я на своём (возможно невсеобъемлющем) опыте сам написал главу "когда проводить рефакторинг" и она состоит из двух предложений: "Рефактори только тогда когда ты не можешь обойтись без рефакторинга. Рефактори только то, что 100% тебе понадобится"
no subject
Date: 2010-01-30 10:43 am (UTC)Ну, видимо, в этом и была проблема. Лично я пришел к рефакторингу задолго до знакомства с творчеством Фаулера, просто потому, что мне достался чужой проект, написанный трудолюбивым идиотом, который кодил в лучших традициях китайского и индусского кода (единственное, что он ленился писать - это комментарии), и без рефакторинга там жить было нельзя. Т.е., одно время работа велась по принципу "не влезай - не убьет". Пытались править баги и дорабатывать функционал методом хирургически точного метания костылей. Нифига этот метод не работает. Костыль, кинутый предельно точно, слегка задевал костыль рядом, в итоге отваливался шлакоблок совсем в другом месте. Зеленый свет на то, чтоб переписать софт заново, нам никто не давал (т.к. лишних ресурсов не было, а доработки всегда были срочные). И тогда я понял, что, если я не научусь малой кровью улучшать код, выдерживая сроки, то проект будет жить как белорусский народ по словам Лукашенко: "плохо, но недолго".
Ну и стал рефакторить. Во всем коде, который мне попадался на глаза и вызывал раздражение, я делал (и делю поныне) маленькие изменения. Мне ни разу не приходилось объяснять начальству, что у меня полетели сроки из-за того, что я занимался рефакторингом. Потому что рефакторинг - это процесс, который осуществляется маленькими шагами. И на каждом шаге этого процесса проект должен работать. 2 недели - это неправильный рефакторинг.
В итоге, постепенно, код становился понятней, новые доработки выполнялись проще, баги правились легче. Не скажу, что код сейчас конфетка. Но работать с ним гораздо легче.
> Говоришь вклад в будущее? Знаешь что стало с тем кодом? Ничего. Он так и работает.
Ну и что? Моему проекту уже 2 года грозят скорой и неизбежной смертью. Т.е., да, все знают, что он скоро предположительно умрет, но в каждый отдельный момент времени он жив, и в него надо вносить доработки. Если б я не начал заниматься улучшением кода с самого начала, то сейчас, спустя 2 года, я бы работал все с той же непонятной кучей говна. А может набралась бы критическая масса говна, и проект уже умер бы не в силу внешних причин, а в силу собственной убогости. Более того, сейчас у моей команды достаточно ресурсов, чтобы параллельно потихоньку переписывать этот софт на новых технологиях (старый, увы, собирается только под 6-ой студией), чем мы и занимаемся. Старый код пропадет? Да и хрен с ним. Но если его придется модифицировать, пусть это будет как можно легче.
Про будущее можно твердо сказать только одно: что если ты не будешь сейчас улучшать код, который нуждается в улучшении, то в будущем у тебя будет все тот же год, нуждающийся в улучшениях (но как правило уже более нуждающийся). Обратного тебе никто не гарантирует :)
> Насчёт затруднения переименования функций с системой контроля версий - IBM Rational Clear Case Remote Client тебе в помощь.
Ну рефакторинг тут ни при чем. Это примерно как прицепить к машине якорь и говорить о бесполезности 4-ой передачи. А почему не перейдете на другую систему, если эта мешает?
> У Фаулера в рецептах рефакотринга опубликованных интерфейсов ничего не сказано по поводу коллег возмущённых тем, что ты подкинул им дополнительной работки во имя инвестиций в будущее.
Ну, во-первых, сказано. Старый интерфейс оставляется (с пометкой deprecated, например), новый добавляется. Коллеги сами решают, когда переходить на новый интерфейс.
Во-вторых, не знаю как в джаве, в C++ можно оспользоваться макросами для управления тем, какой фрагмент кода компилить. Т.о. можно поддерживать 2 интерфейса, не выпуская лишний код в релиз. Подозреваю, в джаве тоже что-то такое есть. Опять же, коллеги сами решают, какой интерфейс им использовать.
Ну и если резюмировать, мне ситуация, описанная тобой, напоминает поговорку "обжегшись на молоке на воду дует".
no subject
Date: 2010-02-01 09:24 am (UTC)При этом я не делаю приговор рефакторингу - это замечательная техника и у меня есть и хорошие примеры её использования, просто во всём нужно знать меру и не лезть с рефакторингом туда, где ты можешь без этого обойтись. По поводу целесообразности рефакторинга думаю, нам не стоит спорить, потому что я считаю что рефакторинг целесообразен и даже очень. Из твоих комментариев я понял то же. То есть мы тут согласны.
Фраза "не надо рефакторить код, который не надо рефакторить" в общем-то действительно является тем, что я хотел сказать, просто я разъяснял какой код не надо рефакторить. И это тоже согласуется с принципом: "Работает? Ничего не меняй."
no subject
Date: 2010-01-23 03:37 pm (UTC)no subject
Date: 2010-01-23 04:21 pm (UTC)no subject
Date: 2010-01-23 04:57 pm (UTC)no subject
Date: 2010-01-26 04:43 pm (UTC)Это, если работает приемлемо. Но до этого уровня нужно ещё дойти - путём множества тестовых циклов "прогон - исправление". При этом каждый следующий прогон ничего не помнит о предыдущих.
Вопрос в том, содержит ли текущая реализация достаточно мало глюков (НЛО? Чудеса?), чтобы сойти за работоспособную :).