Здравствуйте, Codealot, Вы писали:

C>Всегда рад помочь тем, кто в этом нуждается
Вот только непонятно, как так получается, что инженер умеет делать рефакторинг так, чтобы не было задержек; стоимость рефакторинга тоже пренебрежимо мала; и тем не менее, рефакторинг "не делается годами".
Как это так получается? Менеджер стоит над инженером и всякий раз, как тот нажимает Alt-Enter, бьёт его железной линейкой по пальцам?
Или это инженер саботирует рефакторинг, а потом обвиняет менеджера в том, что теперь всё тонет в говнокоде, "вы же сами не приказали мне сделать рефакторинг"?

Здравствуйте, Sinclair, Вы писали:

S>Во-вторых, есть традиционные ошибки менеджмента, которые возникают при вот таком вот "краткосрочном планировании". Я их называю "мат в два хода": когда принимаются два решения, каждое из которых выглядит вполне приемлемым, но результат получается недостаточно хорошим.

Это настолько стало нормой, что я и не знаю, считать ошибкой или еще чем. Постоянная гонка за сроками, постоянное давление это как то норма на слишком большом количестве проектов.
Похоже, что это болезнь быстрого роста индустрии.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Poopy Joe, Вы писали:
PJ>>Технический долг, например. Менеджер про него ничего не знает и не может оценить.
S>Оценка тех.долга — задача инженера. Принятие решения о его возврате — задача менеджера.
S>Точно так же, как исполнительный директор не обязан разбираться в финансовом анализе — это финдир ему объясняет, какие последствия будут у решения "вернуть часть кредита досрочно".
Как можно принять решение о чем-то, в чем ты не разбираешься? Я, наверно, в параллельной реальности живу. Какие форумы не читай, либо программистов держат за дебилов, либо менеджеров. Это не война между разработчиками и управлением. Это разные аспекты одной задачи — заработать денег. Если менеджер неадекват-самодур, то наверно надо просто уходить в другое место. Если менеджер считает, что у него команда дебилов, которые не понимают приоритеты компании, то надо их просто выгонять и набирать других, какие тут еще варианты?! В нормальное же ситуации это совместная работа. Люди друг-друга, обычно, слушают.

PJ>>Не обязательно, может и получиться. Никто не мешает добавлять фичи переписывая код.
S>Нет. По определению, рефакторинг не изменяет функциональность.
Детский сад. Если у тебя кривой модуль, где все на соплях и тебе надо добавить фичу, то ты не будешь его переписывать, а будешь туда лепить костыли, потому что в определении так написано?
PJ>>Это реально катастрофа для проекта. Технический долг накапливается медленно и рефакторинг, с точки зрение бизнеса, никогда не будет выглядеть полезным. В результате все превращается в болото говнокода.
S>Ну, во-первых, не факт, что это плохо. Если продукт продаётся, и прибыль покрывает затраты, то хрен с ним с говнокодом. Это неожиданный результат для инженера, но с т.з. стратегического планирования всё может быть Ок.
Факт. Если конечно задача не стоит впарить, а там трава не расти. Не надо быть гением, чтобы сообразить, что при плохом коде и ошибок больше, и фичи добавляются дольше, а в результате денег будет меньше.

S>Есть два способа выйти из этого порочного круга:
S>1. Самый простой — говорим "нет, мы не будем делать workaround".
Это вот сейчас смешно было.

S>Дождёмся эскалации от партнёра, и тогда глава департамента подпишет любые затраты, включая выпуск мейнтенанс-версии всего продукта вне графика.
S>И нам не придётся тратить месяц, уговаривая его выделить нам неделю ресурсов.
Это реально война внутри компании. Как в такой атмосфере-то работать можно?

S>2. Более сложный: убедить руководство, что так делать нельзя — к примеру, убрать правило про снижение приоритета багам с workaround-ами.
S>3. Практически невозможный: честно отслеживаем затраты на принятое решение — например, на перевыпуск патча с каждым апдейтом продукта. С этими цифрами в руках убеждаем менеджмент, что "экономия" тратит нам больше ресурсов, чем экономит.

У нас простое правило — все решения должны снижать известный технический долг. Если ххх требует изменение и имеется технический долг, то первым делом идет его рефакторинг. Технический долг повышать можно, только если это срочно и внепланово. Ну, тот же критический баг, в релизе. Я могу спросить менеджера любого уровня до топов как вам надо лучше или быстрее и ответ всегда будет "лучше". Где вы находите других, для меня загадка. С другой стороны, когда надо быстрее, лучше вчера, хоть и кривее я точно так же пойму сам. Потому что менеджеры в свою очередь так же расскажут причины и приоритеты. В конце-концов предложение можно быстро и криво может исходить только от инженеров, менеджмент про это ничего не знает.

Здравствуйте, Codealot, Вы писали:

C>Это не тот вопрос, который я задал, так что не уклоняйся.
Ты намерено задал его некорректно, но мне все эти приемы демагогии известны.

Тебе для начала надо доказать, что у тебя эта инвалидность есть и что тебе её дали честно, а не за деньги. Пока всё твоё поведение доказывает, что болезни, которые ты себе приписываешь, тебя не касались в принципе, однако ты опускаешь все эти вопросы и ставишь конечный, как-будто всё вышеперечисленное — доказанный факт. Я имею полное право сомневаться в твоих словах, т.к. они расходятся с твоим обычным поведением на форуме.

Докажешь первое и второе, мы можем переходить к вопросу, чьё мнение по диагнозам весомей — моё или добросовестных медицинских специалистов.

C>Память тебя подводит.
Не, не подводит. Ты пытался избавиться от вопросов, определяющих твою профессиональную квалификацию, прикрываясь инвалидностью, хотя закон прямо говорит, что такое не прокатит.

C>А еще бывают люди, которые ничего конкретно о ситуации не знают, но считают себя вправе разбрасываться очень серьезными обвинениями. Не буду указывать пальцем.
На зеркало-то? Можешь указывать, можешь не указывать. Дело твоё.

C>Я например не говорю что ты педофил и растлитель детей, хотя такие люди несомненно есть и нисколько не исключено, что ты один из них.

Еще один приём демагогии...

C>Хотя было бы очень интересно посмотреть, как ты доказываешь, что ты не верблюд.
Никак не буду.
Твоё обвинение — тебе и доказывать.

C>Докажи. Оба утверждения. А то пока я от тебя ничего кроме балабольства не видел.
Вообще-то, это от тебя ничего кроме балабольства никто не видел.
Смотрю я твой профиль и вижу фигу. Одно хоть как-то условно положительно оцененное профессиональное сообщение в этюдах о том, что ты тупишь и не можешь решить задачу достаточно эффективно.

Здравствуйте, Poopy Joe, Вы писали:
PJ>Как можно принять решение о чем-то, в чем ты не разбираешься?
Очень просто — по критериям. Вот, например, как программист принимает решение о том, в каком банке взять кредит?
Берёт и сравнивает графики платежей. А потом при помощи сравнения этих графиков со своими приоритетами выбирает наилучший — так, чтобы и ежемещщный платёж был подъёмным, и переплата жабу не пугала.
Для этого совершенно не надо быть финансовым экспертом или разбираться в тонкостях.

Менеджер разбирается в том, в чём разбирается.

PJ>Я, наверно, в параллельной реальности живу. Какие форумы не читай, либо программистов держат за дебилов, либо менеджеров. Это не война между разработчиками и управлением. Это разные аспекты одной задачи — заработать денег.
Конечно. Именно так и есть. Поэтому документацию пишет техрайтер, на звонки пользователей отвечает саппорт. Код пишет разработчик.

PJ>Если менеджер неадекват-самодур, то наверно надо просто уходить в другое место. Если менеджер считает, что у него команда дебилов, которые не понимают приоритеты компании, то надо их просто выгонять и набирать других, какие тут еще варианты?!
Эмм, в нормальной ситуации у рядовых сотрудников должно быть очень хорошее понимание своей задачи, и приблизительное — соседей. Ну, то есть всегда полезно рассказать о приоритетах компании кодеру. Но рассчитывать на то, что он прямо сам готов в любой момент наизусть отбарабанить планы на квартал, год, и пятилетку — глупо.
То же самое — про менеджера. Менеджер должен хорошо знать свою работу — для того, чтобы её не приходилось делать программистам. И немножко, очень поверхностно знать работу программистов. Опять же, рассчитывать на то, что он в уме держит все объёмы технического долга или готов наизусть перечислить то, что придётся переписать при переезде с .Net FW на .Net Core — глупо.

Нормальный менеджер в случае споров всегда должен быть готов объяснить, что "да, ребята, я всё это понимаю, но у нас дата релиза сейчас важнее даже качества, поэтому делать мы будем вот это и вот это". А не говорить "ты что, дебил? Не слушал выступление генерального в феврале? Как я сказал, так и делайте".
И разработчик тоже обязан быть готов объяснить менеджеру, зачем и почему нужен рефакторинг. А не говорить "ты что, дебил? Чо ты тогда лезешь управлять в айти, если сам не способен понять, что делать?".

PJ>В нормальное же ситуации это совместная работа. Люди друг-друга, обычно, слушают.
Совершенно верно. Как раз меня и удивляет то, что коллега Codealot прямо постоянно сталкивался с ситуациями тупых менеджеров, которые не давали ему делать рефакторинг.

PJ>Детский сад. Если у тебя кривой модуль, где все на соплях и тебе надо добавить фичу, то ты не будешь его переписывать, а будешь туда лепить костыли, потому что в определении так написано?
В определении чего? Вы ставите телегу впереди лошади. Вот этот кривой модуль переписывается в два коммита:
1. Рефакторинг. Без изменения функциональности.
2. Фича. Без рефакторинга.
Попытки склеить оба действия в одно чреваты ростом интеграционных фейлов и откатом коммита со словами "ой, в этом спринте мы не успели — переделаем в следующем".
В таком подходе становится очевидно, что фичи не являются результатом рефакторинга, хоть и зависят от него.
PJ>Факт. Если конечно задача не стоит впарить, а там трава не расти. Не надо быть гением, чтобы сообразить, что при плохом коде и ошибок больше, и фичи добавляются дольше, а в результате денег будет меньше.

PJ> Это реально война внутри компании. Как в такой атмосфере-то работать можно?
Добро пожаловать в тёплый корпоративный мир. Я вас, наверное, расстрою, но в любой компании с размером больше 100 человек такие вещи бывают. Не обязательно всё время. Но регулярно случаются.
Ну, либо люди годами сидят в порочном круге, который я описал, а потом их покупают конкуренты.

PJ>У нас простое правило — все решения должны снижать известный технический долг.
Очень круто. Где работаете?
Вообще звучит фантастически. В нашей реальности невозможно знать будущее сколь-нибудь надёжно. Вот, появляется какая-нибудь "фича". Ну там, микрософт выпустили очередную какую-нибудь шнягу, с которой нужно интегрироваться.
Мы можем сесть, зарефакторить 40% кода, чтобы новая шняга органично вписывалась в общую архитектуру. (Мы даже так раньше делали). А через год окажется, что это вообще никому не надо, и вся шняга была ошибкой менеджмента в Микрософт.
Или переделается так, что архитектуру придётся пересматривать ещё раз. Или, наоборот, окажется столбовой дорогой.
Поэтому мы балансируем между разными вариантами — всегда стараемся сделать как можно дешевле. Возможно, через релиз мы этот код вообще выпилим.
Только если штука оказывается достаточно востребованной, мы продолжаем вкладывать в неё деньги — и это обычно хорошо видно даже без стратегического анализа: если к фиче появляются дополнительные требования, то как раз "грязь" в коде начинает мешать их воплощать. Вот и повод делать рефакторинг вместе с разработкой нового.
Таким образом, у нас выполняется очень мало задач, которые "рефакторинг сам по себе". Код, который мало востребован, так и висит себе в низком качестве — это ни на что не влияет.
Иногда, раз в несколько релизов, производится "уборка" — выкидывание того кода, который перестал быть нужен больше двух-трёх лет назад. И то, это стараются привязывать к какой-то осязаемой пользе. Например, выкидываем старинный код на PowerShell, который был нужен для обхода ограничений ранних версий CREST API. Уже и CREST давно нет, а код всё ещё болтается — потому что надо было запуститься в Китае, а их версия PC API тоже урезанная, и PowerShell как раз был нужен. Теперь мы убедились, что запуск в Китае — мёртвая идея. Зато мы готовимся переезжать в Linux, а для этого надо выкидывать всю эту легаси — и вот в рамках подготовки к будущей фиче мы и списываем усилия на обрезку.
Не было бы этого — ну и болтался бы этот код в проекте. Зачем на него тратиться — у нас всегда есть, чем занять разрабочиков.

PJ>Если ххх требует изменение и имеется технический долг, то первым делом идет его рефакторинг. Технический долг повышать можно, только если это срочно и внепланово. Ну, тот же критический баг, в релизе. Я могу спросить менеджера любого уровня до топов как вам надо лучше или быстрее и ответ всегда будет "лучше". Где вы находите других, для меня загадка.
Ну, когда я был кодером, мы регулярно нарывались на приоритет сроков перед качеством. Когда я вырос до должностей постарше, оказалось, что это, как правило, мискоммуникация — просто при передаче по цепочке теряются важные детали.

PJ>С другой стороны, когда надо быстрее, лучше вчера, хоть и кривее я точно так же пойму сам. Потому что менеджеры в свою очередь так же расскажут причины и приоритеты. В конце-концов предложение можно быстро и криво может исходить только от инженеров, менеджмент про это ничего не знает.
Вот именно. Поэтому мне и странно слышать от коллеги Codealot о том, что его утомили менеджеры, навязывавшие ему говнокод. Ну, то есть говнокод кто-то писал, так? И это явно был не менеджер. То есть инженер ухудшал код, а менеджер был виноват в том, что не заставил его это исправить.

Здравствуйте, Sinclair, Вы писали:

S>Очень просто — по критериям. Вот, например, как программист принимает решение о том, в каком банке взять кредит?
S>Берёт и сравнивает графики платежей. А потом при помощи сравнения этих графиков со своими приоритетами выбирает наилучший — так, чтобы и ежемещщный платёж был подъёмным, и переплата жабу не пугала.
S>Для этого совершенно не надо быть финансовым экспертом или разбираться в тонкостях.
В этой аналогии рефакторинг это что-то из внутренних процессов банка, которые могут поднять операционную прибыль, а могут и не поднять. Зачем программисту вообще про это знать, а не то, чтобы еще и учитывать в решении?

S>Менеджер разбирается в том, в чём разбирается.
Именно. Заказчики, требования, сроки. Код его не должен волновать от слова совсем, если это не становится проблемой первых трех пунктов. Но и в этом случае его проблема это девочки, а не мебель. команда, а не код.

PJ>>Если менеджер неадекват-самодур, то наверно надо просто уходить в другое место. Если менеджер считает, что у него команда дебилов, которые не понимают приоритеты компании, то надо их просто выгонять и набирать других, какие тут еще варианты?!
S>Эмм, в нормальной ситуации у рядовых сотрудников должно быть очень хорошее понимание своей задачи, и приблизительное — соседей. Ну, то есть всегда полезно рассказать о приоритетах компании кодеру. Но рассчитывать на то, что он прямо сам готов в любой момент наизусть отбарабанить планы на квартал, год, и пятилетку — глупо.
Конечно глупо. Он всегда может открыть последнюю презентацию и ознакомится с ними. Нафига их наизусть учить? А вот учитывать их надо. Менеджмент ставить приоритеты исходя из требований рынка, общения с клиентами и продажниками. Они ничего не знают о том, сколько времени это займет и какое там качество внутри. И это задача ответственного разработчика сказать, что хотя фича Х запланирована на конец года, делать надо уже сейчас, потому что там все переписывать надо.

PJ>>Детский сад. Если у тебя кривой модуль, где все на соплях и тебе надо добавить фичу, то ты не будешь его переписывать, а будешь туда лепить костыли, потому что в определении так написано?
S>В определении чего? Вы ставите телегу впереди лошади. Вот этот кривой модуль переписывается в два коммита:
Ну это ты же сослался на определение, я, полагаю, должен знать.

S>1. Рефакторинг. Без изменения функциональности.
S>2. Фича. Без рефакторинга.
S>Попытки склеить оба действия в одно чреваты ростом интеграционных фейлов и откатом коммита со словами "ой, в этом спринте мы не успели — переделаем в следующем".
S>В таком подходе становится очевидно, что фичи не являются результатом рефакторинга, хоть и зависят от него.
В таком походе очевиден только религиозный догматизм. Если модуль не удовлетворяет новым требованиям, то можно начать с пруф-оф-концепт новой фичи, потом вокруг этого уже переписать все остальное. Если при этом существующее поведение не изменится, то это рефакторинг. В каком там порядке шли коммиты монопенесуально.

PJ>>У нас простое правило — все решения должны снижать известный технический долг.
S>Очень круто. Где работаете?
В корпоративном мире, внезапно.

S>Вообще звучит фантастически. В нашей реальности невозможно знать будущее сколь-нибудь надёжно. Вот, появляется какая-нибудь "фича". Ну там, микрософт выпустили очередную какую-нибудь шнягу, с которой нужно интегрироваться.
Не понял в каком контексте тут возникло будущее? Технический долг это настоящее и прошлое. Наличие новой шняги это не технический долг. И с архитектурой у вас явно беда, если ради этого надо переписывать 40% кода. Если бы вы следовали ddd такие вещи бы жили на границе системы и никаких проблем не доставляли. В таком виде это действительно долг, но никак не зависящий от шняг майкрософта.

S>Ну, когда я был кодером, мы регулярно нарывались на приоритет сроков перед качеством. Когда я вырос до должностей постарше, оказалось, что это, как правило, мискоммуникация — просто при передаче по цепочке теряются важные детали.
Ну это разве что с позиции "кодера", специализация, по-моему, существующая только на форумах. Потому что вопрос о качестве никогда не стоит, ну кроме как в очень широком смысле. Фича либо работает, либо не работает. Вопрос был о том какой ценой и ограничений это достигать вот прямо сейчас, пусть и криво внутри, но работает-то как надо. Понятно, что иногда получается "ну, не шмогла я" и тогда приходится как-то выкручиваться. Но это не приоритет сроков над качеством, это просто фейл.

Здравствуйте, Poopy Joe, Вы писали:
S>>Для этого совершенно не надо быть финансовым экспертом или разбираться в тонкостях.
PJ>В этой аналогии рефакторинг это что-то из внутренних процессов банка, которые могут поднять операционную прибыль, а могут и не поднять. Зачем программисту вообще про это знать, а не то, чтобы еще и учитывать в решении?
Ну, так-то незачем. Но вот то, как внутренние процессы банка влияют на его тарифы, определяет в том числе и выбор программиста.
Тем более, что мы же всё-таки говорим про одну компанию. Нет, я знаю, что бывают компании, в которых внутренняя разработка делается посредством "заказов" — и там таки разработчики выставляют департаментам своей же компании прямо цены в рублях. И есть ли там какая-то "операционная прибыль" — дело тёмное.
Но в обычном случае программист не может получить никакую операционную прибыль (т.е. зарепортить 600 часов, потратить 400, а остальные 200 продать налево).
Поэтому у нас "внутренние процессы" влияют на "тариф" напрямую.
Так что программист честно говорит: либо тратим 400 часов сейчас, либо 200 сейчас на хотфикс, и потом ещё 300 на техдолг.
При этом точно так же, как банк даёт выбор программисту, здесь выбор всё же делает менеджер.
PJ>Именно. Заказчики, требования, сроки. Код его не должен волновать от слова совсем, если это не становится проблемой первых трех пунктов. Но и в этом случае его проблема это девочки, а не мебель. команда, а не код.
Я полностью согласен.
PJ>Конечно глупо. Он всегда может открыть последнюю презентацию и ознакомится с ними. Нафига их наизусть учить? А вот учитывать их надо. Менеджмент ставить приоритеты исходя из требований рынка, общения с клиентами и продажниками. Они ничего не знают о том, сколько времени это займет и какое там качество внутри. И это задача ответственного разработчика сказать, что хотя фича Х запланирована на конец года, делать надо уже сейчас, потому что там все переписывать надо.
Ну, прямо такие рассуждения — это всё же уровень не отдельного разработчика, имхо, будь он хоть сениором.

PJ>Ну это ты же сослался на определение, я, полагаю, должен знать.
В определении рефакторинга ничего про костыли нет. Вот я и не понимаю, как вы вывели необходимость костылей из определения рефакторинга.

PJ>В таком походе очевиден только религиозный догматизм.


PJ>Если модуль не удовлетворяет новым требованиям, то можно начать с пруф-оф-концепт новой фичи, потом вокруг этого уже переписать все остальное. Если при этом существующее поведение не изменится, то это рефакторинг. В каком там порядке шли коммиты монопенесуально.
Непонятно, каким образом возникает новая фича, если при этом не меняется существующее поведение. В чём фича-то состоит?

PJ>В корпоративном мире, внезапно.
PJ>Не понял в каком контексте тут возникло будущее?
В очень простом — у технического долга есть перспективы возврата, они расположены в будущем. В зависимости от этого будущего долг можно отдавать, а можно не отдавать. И отдавать разными способами.
PJ>Технический долг это настоящее и прошлое. Наличие новой шняги это не технический долг. И с архитектурой у вас явно беда, если ради этого надо переписывать 40% кода. Если бы вы следовали ddd такие вещи бы жили на границе системы и никаких проблем не доставляли. В таком виде это действительно долг, но никак не зависящий от шняг майкрософта.
Просто вы пытаетесь рассуждать о вещах, о которых ничего не знаете. DDD тут не поможет никоим боком. Вот у вас была архитектура системы, спроектированная в предположении о том, что всё, что продаётся и покупается — это "подписка". Подписка — это такая штука с жизненным циклом, у которой есть повторяющиеся события типа "возобновление".
А потом ррраз! И в вашем домене появляется понятие "однократная продажа", которое никакой подписки не порождает.
Конечно, можно всё бросить и переписать нахрен всю доменную модель. Заодно сломав совместимость с десятком модулей, написанных соседями, которые уже завязались на эту модель.
А можно подпереть это дело костылём — пускай у нас пока что эти однократные продажи будут такими особенными "подписками", которые типа с очень долгим периодом возобновления, и возобновление забесплатно.
Стоить это будет, естественно, в десять раз дешевле. Да, это увеличит нам технический долг. Но! Совершенно непонятно,
а) сколько прибыли нам принесут эти "однократные продажи"
б) не передумает ли Microsoft их вообще поддерживать через годик-другой
в) не окажется ли так, что вся доменная модель ещё раз изменится по результатам практической эксплуатации.
Запросто может оказаться, что прибыль за этой новой фичей равна нулю. В этом случае любые инвестиции в неё — чистый убыток. И списать 1х нам будет в десять раз выгоднее, чем 10х.
Если наступит вариант в), то перфекционистский подход приведёт к тому, что мы потраченные 10х на первый рефакторинг выкинем в помойку, и потратим ещё 10х на новый рефакторинг. Вот уже 20х, а прибыль всё ещё непонятно, есть или нет.

PJ>Ну это разве что с позиции "кодера", специализация, по-моему, существующая только на форумах. Потому что вопрос о качестве никогда не стоит, ну кроме как в очень широком смысле. Фича либо работает, либо не работает. Вопрос был о том какой ценой и ограничений это достигать вот прямо сейчас, пусть и криво внутри, но работает-то как надо. Понятно, что иногда получается "ну, не шмогла я" и тогда приходится как-то выкручиваться. Но это не приоритет сроков над качеством, это просто фейл.
Ну, как известно, безошибочного софта небывает — бывает недотестированный.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Poopy Joe, Вы писали:
S>>>Для этого совершенно не надо быть финансовым экспертом или разбираться в тонкостях.
PJ>>В этой аналогии рефакторинг это что-то из внутренних процессов банка, которые могут поднять операционную прибыль, а могут и не поднять. Зачем программисту вообще про это знать, а не то, чтобы еще и учитывать в решении?
S>Ну, так-то незачем. Но вот то, как внутренние процессы банка влияют на его тарифы, определяет в том числе и выбор программиста.
Это растянуто во времени и делают аналогию уж совсем некорректной.

S>Тем более, что мы же всё-таки говорим про одну компанию.
Программист и банк это не одна компания.

PJ>>Именно. Заказчики, требования, сроки. Код его не должен волновать от слова совсем, если это не становится проблемой первых трех пунктов. Но и в этом случае его проблема это девочки, а не мебель. команда, а не код.
S>Я полностью согласен.
Ну тогда ты согласен и с тем его не волнует делают ли они там рефакториг или в потолок плюют, если к нужному сроку все готово.

PJ>>Конечно глупо. Он всегда может открыть последнюю презентацию и ознакомится с ними. Нафига их наизусть учить? А вот учитывать их надо. Менеджмент ставить приоритеты исходя из требований рынка, общения с клиентами и продажниками. Они ничего не знают о том, сколько времени это займет и какое там качество внутри. И это задача ответственного разработчика сказать, что хотя фича Х запланирована на конец года, делать надо уже сейчас, потому что там все переписывать надо.
S>Ну, прямо такие рассуждения — это всё же уровень не отдельного разработчика, имхо, будь он хоть сениором.
Даже если в случае, если этот разработчик единственный кто недавно этот код смотрел и лучше отстальных понимает проблему? По-моему, у вас там проблемы с иерархией вида я начальник ты дурак, не смей тут рассуждать.

PJ>>Ну это ты же сослался на определение, я, полагаю, должен знать.
S>В определении рефакторинга ничего про костыли нет. Вот я и не понимаю, как вы вывели необходимость костылей из определения рефакторинга.
Я вывел его из описанной тобой необходимости разделять рефакторинг и фичи.

PJ>>Если модуль не удовлетворяет новым требованиям, то можно начать с пруф-оф-концепт новой фичи, потом вокруг этого уже переписать все остальное. Если при этом существующее поведение не изменится, то это рефакторинг. В каком там порядке шли коммиты монопенесуально.
S>Непонятно, каким образом возникает новая фича, если при этом не меняется существующее поведение. В чём фича-то состоит?
Ну, конкретный пример из практики. Была у нас проблема с конфигурационными файлами. Если машину внезапно выключить, то не смотря на все отключенные фильтры итд итп, файлы все равно портились. Решили допилить версионность, т.е. файлы не меняются, просто создаются новые версии. Появляется новое требование снапшота (файл-ты должны быть согласованы) + персистенс модуль и так имеет технический долг (а мы его не повышаем). Можно конечно было трахаться там с рефакторингом, а потом чего-то допиливать разделяя их. Но мы просто переписали с нуля написал сначала новую фичу и от нее уже все остальное. С точки зрения бизнеса старое поведение не изменилось + добавилось новая фича — система всегда в валидном состоянии. И это рефакторининг.

S>Просто вы пытаетесь рассуждать о вещах, о которых ничего не знаете. DDD тут не поможет никоим боком. Вот у вас была архитектура системы, спроектированная в предположении о том, что всё, что продаётся и покупается — это "подписка". Подписка — это такая штука с жизненным циклом, у которой есть повторяющиеся события типа "возобновление".
Понимание некоторых принципов избавляет от необходимости знания многих деталей.

S>А потом ррраз! И в вашем домене появляется понятие "однократная продажа", которое никакой подписки не порождает.
Я прям паузу взял и обдумал в каком случае (если это бы это был мой код) это стало бы проблемой. Так и не понял почему это подано как проблема. Пояснишь?

S>Конечно, можно всё бросить и переписать нахрен всю доменную модель. Заодно сломав совместимость с десятком модулей, написанных соседями, которые уже завязались на эту модель.

DDD тут не поможет никоим боком.

Здравствуйте, Poopy Joe, Вы писали:

PJ>С точки зрения бизнеса старое поведение не изменилось + добавилось новая фича — система всегда в валидном состоянии. И это рефакторининг.

Рефакторинг это не "поведение с тз бизнеса", а вообще наблюдаемое поведение, т.е. гарантируем это автоматическими тестами всех уровней, ручными, проверкой пред-, пост-условий, инвариантов, можно даже хоть логи притянуть сюда.
Раз добавилась фича — значит наблюдаемое поведение изменилась.
Поскольку старое не поломали, значит это инкрементное изменение. Т.е. новая фича не модифицирует старые.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Poopy Joe, Вы писали:

PJ>>С точки зрения бизнеса старое поведение не изменилось + добавилось новая фича — система всегда в валидном состоянии. И это рефакторининг.

I>Рефакторинг это не "поведение с тз бизнеса", а вообще наблюдаемое поведение, т.е. гарантируем это автоматическими тестами всех уровней, ручными, проверкой пред-, пост-условий, инвариантов, можно даже хоть логи притянуть сюда.
I>Раз добавилась фича — значит наблюдаемое поведение изменилась.
I>Поскольку старое не поломали, значит это инкрементное изменение. Т.е. новая фича не модифицирует старые.

Правильное слово тут внешнее. Т.е. с точки зрение внешнего наблюдателя, т.е. бизнеса, обычно. Какие там логи внутри вообще никого не волнует. Твое определение бесполезно чуть менее чем полностью. Добавил параметр в функцию, все тест поменял — не рефакторинг.

Здравствуйте, Poopy Joe, Вы писали:

PJ>Это растянуто во времени и делают аналогию уж совсем некорректной.
Ну, идеальных аналогий не бывает.
PJ>Программист и банк это не одна компания.
А программист и менеджер — одна.
PJ>Ну тогда ты согласен и с тем его не волнует делают ли они там рефакториг или в потолок плюют, если к нужному сроку все готово.
Да, я в целом согласен. Есть нюансы — но, да, всё именно так. Поэтому мне и странно слышать о том, как программисту тупой менеджер мешает рефакторинг делать.

PJ>Даже если в случае, если этот разработчик единственный кто недавно этот код смотрел и лучше отстальных понимает проблему? По-моему, у вас там проблемы с иерархией вида я начальник ты дурак, не смей тут рассуждать.
При чём тут "не смей"? Просто я не готов полагаться на разработчика в предсказании долговременных эффектов.
Когда мы узнаем, что фичу надо сделать к концу года (к концу пятилетки, века, тысячелетия), то это обязанность менеджера определить зависимости и выяснить, надо ли что-то делать прямо сейчас.
Если разработчик смотрел в код недавно, и может сходу сказать "да, надо начинать сейчас" — отлично, молодец. Если не смотрел — пусть посмотрит и скажет.
Если вдруг менеджер это проморгал (ну, потому что априори считает, что мелкую фичу за год планировать не стоит), а разработчик не только заметил, но ещё и выступил с инициативой — молодец разработчик, такие вещи надо поощрять.
Но, повторюсь ещё раз: полагаться на это нельзя. То есть если вдруг так оказалось, что в третьем квартале при начале планирования этапа мы выясняем, что теперь к концу года не успеть никак — виноват будет менеджер.
Он не сможет сказать "ну как же так! Я ведь в курилке говорил, что мы в январе хотим выпустить фичу Х. Я думал, что мне программисты сразу скажут, если её вдруг надо заранее начинать пилить. Несмотря на то, что я ставил им задачу детально планировать второй и грубо — третий кварталы".

PJ>Я вывел его из описанной тобой необходимости разделять рефакторинг и фичи.
Не вижу логической цепочки.

PJ>Ну, конкретный пример из практики. Была у нас проблема с конфигурационными файлами. Если машину внезапно выключить, то не смотря на все отключенные фильтры итд итп, файлы все равно портились. Решили допилить версионность, т.е. файлы не меняются, просто создаются новые версии. Появляется новое требование снапшота (файл-ты должны быть согласованы) + персистенс модуль и так имеет технический долг (а мы его не повышаем). Можно конечно было трахаться там с рефакторингом, а потом чего-то допиливать разделяя их. Но мы просто переписали с нуля написал сначала новую фичу и от нее уже все остальное. С точки зрения бизнеса старое поведение не изменилось + добавилось новая фича — система всегда в валидном состоянии. И это рефакторининг.
Не вижу никакого рефакторинга в примере. Рефакторинг — это изменение кода без изменения функциональности. Самый простой пример — хотим добавить класс Y, который очень похож на уже существующий класс X, но не во всём с ним совместим.
Вот если бы у класса X был предок, в котором реализована общая для классов X и Y функциональность, то можно было б от него отнаследоваться и дописать только нужное...
Introduce base class — это и есть один из видов рефакторинга: класс X делится на B и X. При этом поведение класса X не изменилось, как и поведение всей системы. Если у нас есть какие-то юнит тесты — то они пройдут.
Теперь у нас есть класс B, и можно от него наследовать Y, опять же не ломая всю систему. Это — совсем другое изменение, отдельное от первого, оно — НЕ рефакторинг.
В хорошем случае в рефакторинг класса X входит ещё и просмотр всех мест использования и замена X на B во всех местах, которые могли обойтись B.
Тогда объекты нашего нового класса Y можно будет использовать не только в новом коде, но и кое-где в старом коде.
Вот как раз с этим и возникает засада при смешанном подходе: площадь коммита рефакторинга увеличивается. Теперь в нашей ветке лежат изменения не только в X, B, и никому неинтересный Y, но и изменения в 100500 местах, которые ссылались на X. Конечно же, их прямо сейчас пилят остальные 16 команд. Если мы отложим коммит до момента, когда готова вся фича, то неизбежно нарвёмся на конфликтующие изменения.
Поэтому такие вещи лучше делать отдельным коммитом, и как можно быстрее.

Если у вас персистенс-модуль организован в виде изолированной подсистемы, и никаким другим частям системы не важно, пишет он новые версии или изменяет старые — то откуда тут возьмётся рефакторинг? Просто садимся и пишем новую реализацию модуля. Закончили — проверили — выкинули старый. Всё. Никакого рефакторинга.

Рефакторинг нужен тогда, когда подлежащая замене функциональность размазана неудобным для замены способом по нашему коду. Вот тогда и потребуется рефакторинг — перемещение существующей функциональности таким образом, чтобы границы системы выделялись достаточно чётко.

PJ>Я прям паузу взял и обдумал в каком случае (если это бы это был мой код) это стало бы проблемой. Так и не понял почему это подано как проблема. Пояснишь?
Я вот не представляю себе, в каком случае это _не_ стало бы проблемой.
У нас в любом случае, хоть DDD, хоть не DDD, а бизнес-логика построена в рамках каких-то предположений.
Например, раньше у нас было предположение (и оно контролировалось набором жёстких правил), что каждый ордер связан с подпиской. То есть продаём — подписку, отменяем — подписку, изменяем — подписку, возобновляем — подписку.
Есть куча кода, который на это предположение завязан. Реально куча — причём заранее даже неизвестно какая, т.к. есть большое количество стороннего кода, который интегрирован с нашей платформой.
И вот мы берём и отменяем это требование — теперь ордер есть, а никакой подписки нету. Точнее, есть два вида ордеров — одни с подписками, а другие — без.
Реальная картина, конечно же, гораздо сложнее — там же не только ордера и подписки, но для иллюстрации сойдёт. Естественно, на незыблемых предположениях построено считай всё — ну там, к примеру, письмо клиенту отправляется не по событию "ордер обработался", а по событию "подписка создана", потому что в постоплатных вариантах order flow мы не собираемся откладывать сообщение об активации сервиса до момента внесения денег.
Это означает, что отпиливание подписки от ордера приведёт, в частности, к тому, что письмо "ваш подарочный сертификат с кодом XXX-YYY-ZZZ готов к использованию" отправлено не будет, т.к. ожидаемого события не произойдёт.

Я вот пока никак не могу себе представить код, в котором внесение подобных изменений происходит легко и непринуждённо.

Здравствуйте, Sinclair, Вы писали:

PJ>>Программист и банк это не одна компания.
S>А программист и менеджер — одна.
Ну так они и не общаются как программист и банк, где каждый ищет как заработать на другом.

PJ>>Даже если в случае, если этот разработчик единственный кто недавно этот код смотрел и лучше отстальных понимает проблему? По-моему, у вас там проблемы с иерархией вида я начальник ты дурак, не смей тут рассуждать.
S>При чём тут "не смей"? Просто я не готов полагаться на разработчика в предсказании долговременных эффектов.
А почему ты не готов на него полагаться? Ты такой умный или он такой тупой? Вот это желание всем лично руками контролировать, потому что могу, выглядит для меня нездоровой практикой. Если ты не доверяешь мнению специалиста, то его надо увольнять. Зачем надо платить инженеру деньги и не слушать?

S>Когда мы узнаем, что фичу надо сделать к концу года (к концу пятилетки, века, тысячелетия), то это обязанность менеджера определить зависимости и выяснить, надо ли что-то делать прямо сейчас.
Пример начался с того, что представлены планы компании. Как можно их представить и не знать, что там надо делать?

S>Не вижу никакого рефакторинга в примере. Рефакторинг — это изменение кода без изменения функциональности. Самый простой пример — хотим добавить класс Y, который очень похож на уже существующий класс X, но не во всём с ним совместим.
S>Вот если бы у класса X был предок, в котором реализована общая для классов X и Y функциональность, то можно было б от него отнаследоваться и дописать только нужное...
Это твое личное понимание рефакторинга. Я не могу сказать, что оно неправильное, поскольку правильного, отлитого в граните не существует. На практике я никогда такого узкого понимания не встречал, и ни в одном определении нет ничего про классы, но и спорить тут тоже смысла нет, так как нет истины.

S>Если у вас персистенс-модуль организован в виде изолированной подсистемы, и никаким другим частям системы не важно, пишет он новые версии или изменяет старые — то откуда тут возьмётся рефакторинг? Просто садимся и пишем новую реализацию модуля. Закончили — проверили — выкинули старый. Всё. Никакого рефакторинга.
Рефакторинг это изменение кода, без изменения поведения. Важно ли это другим модулям тут вообще не существенно. Но, так-то, все было переписано. Вся логика взаимодействия с этим модулем стала другая, обработка ошибок по другому. Ну не видишь и ладно.

PJ>>Я прям паузу взял и обдумал в каком случае (если это бы это был мой код) это стало бы проблемой. Так и не понял почему это подано как проблема. Пояснишь?
S>Я вот не представляю себе, в каком случае это _не_ стало бы проблемой.
S>У нас в любом случае, хоть DDD, хоть не DDD, а бизнес-логика построена в рамках каких-то предположений.
Вот первое о чем говорит DDD, что так делать нельзя. Нельзя строить бизнес-логику на предположениях, да еще и другого домена. Вы изначально раскидали грабли где только можно, а потом это стало проблемой. Вот же странно-то...

S>Например, раньше у нас было предположение (и оно контролировалось набором жёстких правил), что каждый ордер связан с подпиской. То есть продаём — подписку, отменяем — подписку, изменяем — подписку, возобновляем — подписку.
S>Есть куча кода, который на это предположение завязан. Реально куча — причём заранее даже неизвестно какая, т.к. есть большое количество стороннего кода, который интегрирован с нашей платформой.
S>И вот мы берём и отменяем это требование — теперь ордер есть, а никакой подписки нету. Точнее, есть два вида ордеров — одни с подписками, а другие — без.
S>Реальная картина, конечно же, гораздо сложнее — там же не только ордера и подписки, но для иллюстрации сойдёт.
Т.е. если реальная картина еще и сложнее, то я даже не знаю что тут сказать. Не в том смысле, что задача сложная, задача-то как раз тривиальная. А вот подходы к решению замысловатые.
Если разработчикам не доверять, то, наверно, так и получится.

S>Я вот пока никак не могу себе представить код, в котором внесение подобных изменений происходит легко и непринуждённо.
В такой, прости господи, архитектуре, добавления комментария в код может не пройти легко и непринужденно. Ну так не делайте так. Мы уже как-то обсуждали, и выяснилось, что ты не признаешь инвариантов в системе. Ну вот, это результат.

Здравствуйте, Poopy Joe, Вы писали:

PJ>Ну так они и не общаются как программист и банк, где каждый ищет как заработать на другом.
Эмм, очень странно. Хороший менеджер всегда ищет, как заработать. См. выше по ветке: его задача — увеличивать stakeholder value.
PJ>А почему ты не готов на него полагаться? Ты такой умный или он такой тупой? Вот это желание всем лично руками контролировать, потому что могу, выглядит для меня нездоровой практикой. Если ты не доверяешь мнению специалиста, то его надо увольнять. Зачем надо платить инженеру деньги и не слушать?
Потому, что в обязанности разработчика не входит детальное знание приоритетов. Точно так же, как программист не должен полагаться на то, что менеджер разбирается в деталях кода.
В вопросах кода — конечно менеджер должен слушать разработчика. Если тот сказал, что через SSE не ускорить — значит, не ускорить. Если сказал, что потребуется три недели — значит, три недели.
А в вопросах того, какую фичу делать сейчас, а какую потом — решает менеджер. Иначе нахрен он вообще нужен? Зачем мы нанимаем менеджера, и не даём ему принимать решения?

PJ>Пример начался с того, что представлены планы компании. Как можно их представить и не знать, что там надо делать?
Нуу... например, потому, что есть большой разрыв между планом "запускаемся в китае" и детальным планированием релиза.

PJ>Это твое личное понимание рефакторинга. Я не могу сказать, что оно неправильное, поскольку правильного, отлитого в граните не существует.
Это не только моё понимание рефакторинга. Сходите хотя бы в википедию. Если не верите википедии — посмотрите, что называется рефакторингом в инструментальных средствах — студия, решарпер.
Цитирую:

Рефа́кторинг (англ. refactoring), или перепроектирование кода, переработка кода, равносильное преобразование алгоритмов — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы. В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований.

PJ>На практике я никогда такого узкого понимания не встречал, и ни в одном определении нет ничего про классы, но и спорить тут тоже смысла нет, так как нет истины.
Я привёл не определение, а пример.

PJ>Рефакторинг это изменение кода, без изменения поведения. Важно ли это другим модулям тут вообще не существенно. Но, так-то, все было переписано. Вся логика взаимодействия с этим модулем стала другая, обработка ошибок по другому. Ну не видишь и ладно.
Вот именно. Без изменения поведения. А у вас — "Вся логика взаимодействия с этим модулем стала другая, обработка ошибок по другому."

PJ>Вот первое о чем говорит DDD, что так делать нельзя. Нельзя строить бизнес-логику на предположениях, да еще и другого домена. Вы изначально раскидали грабли где только можно, а потом это стало проблемой. Вот же странно-то...
Непонятно, как можно строить бизнес логику без предположений.

PJ> Т.е. если реальная картина еще и сложнее, то я даже не знаю что тут сказать. Не в том смысле, что задача сложная, задача-то как раз тривиальная. А вот подходы к решению замысловатые.
PJ>Если разработчикам не доверять, то, наверно, так и получится.
Да нет, всю эту кунсткамеру пилили как раз разработчики. И я не понимаю, что такое "из другого домена"? Домен тут ровно один — управление cloud-сервисами.
Что вы называете "доменом"?

PJ>В такой, прости господи, архитектуре, добавления комментария в код может не пройти легко и непринужденно. Ну так не делайте так. Мы уже как-то обсуждали, и выяснилось, что ты не признаешь инвариантов в системе. Ну вот, это результат.
Продолжаю непонимать. Вот у нас в системе был инвариант "у ордера всегда есть подписка". Он десятилетиями оставался незыблемым. Теперь он изменился. Каким образом DDD (или вообще какой-то подход к коду) может тут помочь?

Здравствуйте, Sinclair, Вы писали:

S>Вот только непонятно, как так получается, что инженер умеет делать рефакторинг так, чтобы не было задержек; стоимость рефакторинга тоже пренебрежимо мала; и тем не менее, рефакторинг "не делается годами".

Похоже, что у тебя там не хватает частицы "не".

S>Как это так получается? Менеджер стоит над инженером и всякий раз, как тот нажимает Alt-Enter, бьёт его железной линейкой по пальцам?

Объясняю: рефакторинг, который делается при помощи кнопок Alt-Enter — это самая примитивная и наименее полезная форма рефакторинга из возможных. И если программист думает, что других видов рефакторинга не бывает, то этот программист — тот самый джун, которого тут очень часто упоминают.

Здравствуйте, _ABC_, Вы писали:

_AB>Ты намерено задал его некорректно

Врешь, я задал его абсолютно корректно.

_AB>но мне все эти приемы демагогии известны.

Да уж я вижу. Тебе они известны чертовски хорошо

_AB>Тебе для начала надо доказать, что у тебя эта инвалидность есть

А с фига ли, собственно, я должен доказывать не пойми кому, что я не верблюд? Это дело между мной и кадровиками, если я вообще решу им про это рассказать. Потому что похоже, что пользы от этого будет ноль, а проблем может быть очень много. Именно из-за таких людей, как ты.

_AB>1. и что тебе её дали честно, а не за деньги.
_AB>2. Твоё обвинение — тебе и доказывать.

Похоже, ты так увлекся демагогией, что буквально противоречишь сам себе. Очень типично.

_AB>Пока всё твоё поведение доказывает, что болезни, которые ты себе приписываешь, тебя не касались в принципе

Это каким таким образом?

_AB>Не, не подводит. Ты пытался избавиться от вопросов, определяющих твою профессиональную квалификацию, прикрываясь инвалидностью, хотя закон прямо говорит, что такое не прокатит.

Опять врешь, причем сразу по двум пунктам.
1) Я пытался избавиться от глупых задач, которые мою профессиональную квалификацию не определяют, но очень любимы кадровиками.
2) Закон говорит, что от таких вопросов действительно можно избавиться — но это только в теории, из-за косяков в формулировке закона. На практике же, лучше держать язык за зубами.

_AB>Смотрю я твой профиль и вижу фигу. Одно хоть как-то условно положительно оцененное профессиональное сообщение в этюдах о том, что ты тупишь и не можешь решить задачу достаточно эффективно.

А ты можешь решить ее намного лучше? Ну так докажи делом, хватит пустозвонить


А теперь подобьем итоги.
Во первых, приписывать себе тяжелые болезни, чтобы получить с этого какой-то профит — в большинстве стран это вполне реальное преступление, которое вполне реально наказуемо, и было бы крайне глупо подделывать то, что легко разоблачить.
Во вторых — впрочем, по этому поводу я не беспокоюсь, потому что мне достаточно пойти в любую больницу сделать энцефалограмму и невролог подвердит, что я болен. Никаких там психотерапевтов с кушетками, на которых они сношают мозги пациентам, а пациенты — им, как это любят показывать в фильмах
В третьих — обвиняя меня в преступлении, которого я не совершал, ты сам совершаешь преступление — клевету. И если бы мы с тобой жили в стране типа США и ты сделал это публично, то я оставил бы тебя без последних штанов. Но поскольку ты здесь анонимен, то чувствуешь себя в полной безнаказанности, а вещи типа угрызений совести тебя явно не волнуют.

Здравствуйте, Ikemefula, Вы писали:

I>Так делают
I>1 плохие пиэмы из бывших разработчиков

Любые плохие пиэмы.

I>Разумеется. И я подробно расписал, кто за что отвечает.

То есть сделал то, о чем я тебя не просил, к тому же плохо См также предыдущий пункт.

I>Девелопер обязан уметь изъясняться в единицах business value, а не словами из кода, иначе он просто джун.

Интересно у тебя получается. Девелопер обязан знать и свою область, и менеджерскую. А заодно и предметную область, очевидно. А манагер, похоже, обязан знать только волшебные заклинания "сделать!!!" и "быстро!!!111"

Здравствуйте, Poopy Joe, Вы писали:

PJ>Если менеджер считает, что у него команда дебилов, которые не понимают приоритеты компании, то надо их просто выгонять и набирать других, какие тут еще варианты?!

С одной стороны — менеджера жаба душит, потому что тогда и платить придется больше. С другой стороны, плохой менеджер боится, что на фоне слишком хороших программистов он сам будет смотреться невыгодно, а тогда можно и кресла лишиться.

Здравствуйте, Poopy Joe, Вы писали:

PJ>Как можно принять решение о чем-то, в чем ты не разбираешься? Я, наверно, в параллельной реальности живу.
Наверное. Потому, что в реальном мире очень много решений принимается ответственными лицами на основе мнения специалистов.
Начиная от того, какую сантехнику поставить дома, вплоть до того, какие правки вносить в контракт с ключевым контрагентом.
В первом случае это будут сантехники, профессиональные писатели обзоров. Во втором юристы, финансисты, технологи и прочие специалисты.

PJ>Какие форумы не читай, либо программистов держат за дебилов, либо менеджеров.
Ну, конкретно Sinclair уж точно не считает дебилами ни первых, ни вторых.

PJ>Если менеджер неадекват-самодур, то наверно надо просто уходить в другое место.
Наверное.

PJ>Если менеджер считает, что у него команда дебилов, которые не понимают приоритеты компании
Понимать-то они могут. В целом и общем. Однако могут не знать каких-то деталей, последних изменений ситуации и прочее-прочее.
Их задача — кодить по поставленным задачам и давать мнение специалиста по поставленным вопросам.

PJ>В нормальное же ситуации это совместная работа. Люди друг-друга, обычно, слушают.
Да. И до людей должна доводиться информация в объеме, достаточном и необходимом для их работы. Если же доводить до них всю информацию, то кодить будет некогда и некому — все будут информацию получать/доводить.

PJ>Детский сад. Если у тебя кривой модуль, где все на соплях и тебе надо добавить фичу, то ты не будешь его переписывать, а будешь туда лепить костыли, потому что в определении так написано?
Ты сначала его отрефакторишь, а потом добавишь фичу.
Либо, как вариант, просто перепишешь всё с учетом новой фичи, но это будет не рефакторинг тупо по определению.

PJ>Не надо быть гением, чтобы сообразить, что при плохом коде и ошибок больше, и фичи добавляются дольше, а в результате денег будет меньше.
Ты строишь бизнес-модель на ошибочном предположении.

На практике часто "кто первым встал, того и тапки". Выпустил версию, захватил долю рынка, получил финансирование и получил возможность развиваться дальше, работая над техническим долгом. А те, кто вылизывают код в рассчете на "в будущем фичи добавлять будем быстрее" имеют продукт с меньшим количеством фич здесь и сейчас, меньшей долей рынка и меньшим количеством денег в результате. В результате новые фичи не добавляются, т.к. тупо нет денег на это, несмотря на отсутствие тех. долга. А у первых деньги есть и они их добавляют, пусть с большим трудом и тратя доп. ресурсы на снижение тех. долга.

PJ>У нас простое правило — все решения должны снижать известный технический долг. Если ххх требует изменение и имеется технический долг, то первым делом идет его рефакторинг. Технический долг повышать можно, только если это срочно и внепланово.
Этих "срочно и внепланово" бывает очень много.
Клиент требует новую фичу здесь и сейчас. Здесь и сейчас можно только с увеличением технического долга.
Конкурент выпустил новую версию с киллер-фичей. Быстро выпустить ответ можно только с увеличением технического долга.
Обнаружили, что первоначальный дизайн был ошибочным. Чтобы уложиться в сроки и бюджет, требуется работать с тем, что есть.

PJ>Я могу спросить менеджера любого уровня до топов как вам надо лучше или быстрее и ответ всегда будет "лучше".
Видимо, ты работаешь не в рыночных условиях. Сидишь в какой-то корпорации, разрабатывая что-то, что не влияет на прибыль организации. Ресурсы условно неограниченные.

PJ>Где вы находите других, для меня загадка.
Я работаю над продуктом, которому надо захватывать рынок, находить клиентов, обходить конкурентов.

Здравствуйте, _ABC_, Вы писали:

_AB>Выпустил версию, захватил долю рынка, получил финансирование и получил возможность развиваться дальше, работая над техническим долгом.

Или не работая.

Здравствуйте, Codealot, Вы писали:

_AB>>но мне все эти приемы демагогии известны.
C>Да уж я вижу. Тебе они известны чертовски хорошо
Да. Я с вашим братом часто общаюсь.

C>А с фига ли, собственно, я должен доказывать не пойми кому, что я не верблюд?
Да вообще не должен. Я никогда и не говорил, что ты должен.
Я могу тебе верить, либо не верить. Если хочешь, чтобы поверил — докажи собственное высказывание.
Не хочешь — дело твоё, мне абсолютно пофиг.

C>Именно из-за таких людей, как ты.
Не надо своих тараканов перекладывать на других. Тебе это не поможет.

C>Похоже, ты так увлекся демагогией, что буквально противоречишь сам себе. Очень типично.
Просто у тебя с логикой проблемы. Поэтому и видишь противоречия там, где их нет. Согласен, что это очень типично для тебя.
Ты говоришь, что ты инвалид — тебе доказывать собственное высказывание.
Ты говоришь (хочешь сказать), что я педофил — тебе доказывать собственное высказывание, если ты такое будешь утверждать.

Бремя доказывания лежит на утверждающем (высказывающем). Не слышал? Это же основы логического (рационального) мышления, вообще-то.

_AB>>Не, не подводит. Ты пытался избавиться от вопросов, определяющих твою профессиональную квалификацию, прикрываясь инвалидностью, хотя закон прямо говорит, что такое не прокатит.
C>Опять врешь, причем сразу по двум пунктам.
C>1) Я пытался избавиться от глупых задач, которые мою профессиональную квалификацию не определяют, но очень любимы кадровиками.
Кадровики используют эти задачи для определения твоей профессиональной квалификации. Это повсеместная практика и один из стандартов де-факто. То, что ты (и я, кстати, тоже) считаешь, что задачи неэффективны, это твои проблемы и мои проблемы.

C>2) Закон говорит, что от таких вопросов действительно можно избавиться — но это только в теории, из-за косяков в формулировке закона.
А вот здесь реальное противоречие. Либо закон говорит, что можно, либо формулировка закона этого не позволяет, т.е. закон говорит, что нельзя. То, что ты называешь не нравящиеся тебе лично формулировки "косяком закона" — это твоя сугубо личная проблема.

C>А ты можешь решить ее намного лучше?
У меня другая специализация. И если ты откроешь мой профиль, то увидишь гораздо больше профессиональных сообщений, положительно оцененных другими. Т.е., я на этом форуме проявил себя куда большим специалистом в своей области, чем ты. Следовательно, ты выглядишь как полный балабол, а не я.

C>Во первых, приписывать себе тяжелые болезни, чтобы получить с этого какой-то профит — в большинстве стран это вполне реальное преступление, которое вполне реально наказуемо, и было бы крайне глупо подделывать то, что легко разоблачить.
Так ты, извини, пока что далеко не гением себя проявляешь на форуме.

C>В третьих — обвиняя меня в преступлении, которого я не совершал
Я тебя пока что ни в чем не обвиняю, кроме наличия глупых высказываний и алогичности. Ни первое, ни второе — не преступления, хотя, несомненно, ты совершал и то, и другое.

C>ты сам совершаешь преступление — клевету.
Ты бы не лез в области, в которых нифига не соображаешь...

C>И если бы мы с тобой жили в стране типа США и ты сделал это публично, то я оставил бы тебя без последних штанов.
Вах, боюсь-боюсь...
Ты бы нарвался на ответный иск, т.к. я тебя ни в чем не обвинял, а только высказывал сомнения и недопустимость пустых слов и неявных предположений как средств аргументации. В то время как ты прямо обвиняешь меня в совершении правонарушения, которое я не совершал, и, тем самым, порочишь мою честь и достоинство.

C>Но поскольку ты здесь анонимен, то чувствуешь себя в полной безнаказанности, а вещи типа угрызений совести тебя явно не волнуют.
Угрызения совести по поводу чего? Раненных чувств самовлюбленного анонимного нарцисса? А с чего им вообще возникать по такому поводу?