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

PJ>Может конечно. Вот прям на вики и написано.
PJ>

PJ>If done poorly it may fail the requirement that external functionality not be changed, introduce new bugs, or both.

PJ>Т.е. рефакторинг это не набор заклинаний гарантирующих тебе некую "эквивалентность". Это просто переписывание кода, с чем чтобы он делал то же самое, но по другому.
то есть часть про "if done poorly" вы пропустили. Ну, ок. С такой оговоркой я согласен.

PJ>Я-то как раз ни на чем не настаиваю. Если вы хотите понимать его по своему, то флаг вам в руки. А вот вы, с какого-то перепугу, настаиваете на том, что ваши трактовки единственно верные.


S>>При этом по вашему же варианта определения утечка памяти для рефакторинга — норм, ведь она не затрагивает функциональные требования.
PJ>Она как раз затрагивает. Вряд ли в них есть возможность программе вылетать с ошибкой памяти. Чем проще определение, тем оно лучше работает. Не надо никаких исключений и соглашений.
Я согласен с преимуществом простых определений. Но вы начинаете строить какие-то непонятные мне предположения:
1. Программа с утечкой будет вылетать с ошибкой памяти.
Нет, современное железо даёт программе с утечкой работать месяцами, всё ещё не падая. Да, будет помедленнее работать, требовать побольше памяти, активнее давить на своп.
2. Если в функциональных требованиях не написано "можно вылетать с ошибкой памяти", то нельзя вылетать с ошибкой памяти.
Нет, так не работает. В функциональных требованиях никто не упоминает вообще ничего про память. В 99% в требованиях к софту вообще нет ничего про память; в оставшемся проценте это часть нефункциональных требований, и формулируется она в стиле "должно запускаться на машине с 16GB RAM, 1GB места на диске".
Ни разу в жизни я не видел (и не надеюсь увидеть) оговорок в требованиях к софту насчёт граничных условий: типа "а вот тут, если кончилось место на диске, то приложение должно выдать вот такое-то сообщение".
Такие вещи остаются за рамками требований, кроме очень специальных классов приложений. И ни разу отсутствие таких оговорок не служило поводом разбираться, типа "если вы не заложиди в согласованных с нами требованиях умение падать, когда не хватает памяти, адресного пространства, или места на диске, то вы обязаны не падать".
Если у вас это реально есть в требованиях — покажите скриншот.

PJ>Нет, это не тот же самый код. Можешь декомпилятором разобрать.
Да, код структурирован по другому. Вместо прямого вызова a == 3 происходит вызов делегата, внутри которого лежит ссылка на предикат "a => a==3".
PJ>Более того, емнип, если функция возвращает IEnumerable, то она внезапно может стать ленивой, в то время как c for нет.
Все три приведённые варианта — ленивые. Внезапности никакой не будет.

PJ>Если строго следовать вашей трактовке, то это не рефакторинг, если не начать вытаскивать из кустов "дополнительные соглашения", которые Фаулер явно имел ввиду, но забыл описать.
Надо просто внимательно смотреть, что именно делает этот рефакторинг.

PJ>Не, в этот момент технический долг дал о себе знать. Существовал он с момента, когда вы начали что-то делать на предположениях и выставлять наружу модель, даже не имея представления зачем и кому она нужна.
Все делают всё делают на предположениях. Вы, когда объявляете ссылку not null, делаете предположение, что это соответствует реальным потребностям.
Оно даже может быть справедливо — до определённого момента. А может быть неверным сразу, просто ваше исследование домена оказалось неполным. C'est la vie.

PJ>Я потратил много времени пытаясь сказать, что вы могли бы сделать.
Я пока не вижу ничего такого, что мы могли бы сделать.
PJ>Есть множество практик как подобного избегать, то же DDD например. Если множество компаний которые выставляют наружу публичные API и не страдают. Но, поскольку вы официально лучшие, что вам до этих пейзан?!
В тот момент, когда кто-то выставляет наружу публичный API, становится совершенно неважно, что там у него внутри — DDD, анемик, рич обжект модел, или лапша из скриптов на VBA.
Трудности с публичными API возникают ровно у всех, кто их имеет. Если вы — монстр типа Microsoft, то можно просто макать свою целевую аудиторию головой в сортир каждые 6-24 месяца.
Объявляем старый API deprecated, выпускаем новый, и все остальные должны перейти на него за полгода или уйти в пень.

И даже монстры типа Microsoft регулярно бывают вынуждены откатывать назад апдейты своих публичных API — это что касается "не страдают".
А уж мы тем более не можем себе позволить резких движений — у нас нет такой денежной массы, чтобы легко поглотить 1-2 миллионов долларов ущерба от неудачного обновления.

Поэтому я скорее поверю в то, что это вы не понимаете, как устроена жизнь, чем в то, что я тут один такой дебил, а парни из Редмонда, Пало-Альто и Купертино просто забыли мне рассказать про книжки по DDD.

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