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

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

PJ>>Еще один... Да всё, всё есть наблюдаемое состояние, если я решу за этим наблюдать. Добавил параметр в метод это изменяет расположение в памяти и, соответственно, размер, и это можно наблюдать. Заменил пузырьковую сортировку быстрой и это можно наблюдать. И даже тест сделать, который это отслеживает. Либо программа не делает ничего, либо результаты рефакторинга можно наблюдать.
S>Я ждал этого вопроса, хотя надеялся, что вы сможете сами себе на него ответить.
Я поражаюсь твоему особенному чтению. Сделай одолжение, пальцем там покажи или еще как выдели — где ты тут нашел вопрос?

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

S>Замена способа сортировки рефакторингом не является.
Ну разве что в вашем уютном мирке.

S>Вынос метода сравнения элементов при сортировке в параметр — является рефакторингом.
S>Почитайте Фаулера, посмотрите на Решарпер, студию, идею. Со временем набьёте руку, сможете сходу понимать, где рефакторнг, где нет.
И когда решарпер добавит фичу в рефакторинг, вот это будет срыв шаблона.

PJ>>Ну да, ты один кто пробовал тесты и понял весь дзен добавления параметра.
S>Нет, нас таких много. Это у вас своё, уникальное для индустрии понимание термина "рефакторинг".
У вас-то да, и куда это вас завело? Покупка это подписка, только бесконечная... А потолок это пол, только наоборот.
Нет, спасибо.

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

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

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

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

S>>>Пока что вы ничего нового не рассказали. Ровно то же самое, чего я ожидал. Единственное — что решения, которые я себе представлял, опираются на упорядоченность записи. Если бывает так, что произведённая позже запись проходит, а произведённая раньше — нет, то придётся покумекать над решением подольше. Сходу ничего придумать не могу — все известные мне технологии восстановления построены на упорядочивании. Если диск ухитряется записать хвост журнала, но теряет его середину, то это сломает каждую из известных мне СУБД.
PJ>>Да ладно, сообщение назад это же была задача для джуниора?!

S>Это я сходу затупил. Конечно же, за полчаса можно решить и эту задачу — хоть с версиями, хоть без них.
ну да "Берём последнюю версию, если она консистентна — всё хорошо. Если хотя бы в одном файле плохо — откатываемся на предыдущую версию." вот так вы можете. Уровень джуниора и есть. Взять предположение и зафигачить решение. На какую предыдущую версию модуль будет откатываться, если он знает только про свои версии?

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

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

Пытливый ум мог бы ещё провести некоторые аналогии с оптимизацией — там же тоже компилятор вносит изменения в код, и их можно обнаружить.
Например, вот вы там собирались написать тест, который проверяет расположение аргументов вызова в памяти — прекрасный пример. Приличный компилятор инлайнит вызов, и ваш тест в результате измерения выдаёт "борщ".
Безо всякого, кстати, рефакторинга. И вообще раз от раза этот тест будет выдавать то одно, то другое — потому что современный комплятор языков высокого уровня достаточно вольно обращается с техническими деталями уровня расположения аргументов в памяти.

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

Ок, рефакторинг introduce parameter может катастрофически повлиять на быстродействие — потому что раньше оптимизатор видел константу, выбрасывал целый блок кода, и менял всю арифметику. А теперь он вынужден честно выполнять сравнения, прибавлять нули и умножать на единицы. А может и не повлиять — потому что оптимизатор заинлайнил вызов, увидел ту же константу, убедился, что a+=0 можно заменит на nop, и выкинул весь цикл по массиву.

О чём нам намекают все эти сходства? И оптимизирующий компилятор, и решарпер, и программист при ручном рефакторинге занимаются примерно одним: преобразованием программы с сохранением эквивалентности.
Компилятор делает из понятного неэффективного кода непонятный эффективный; программист (или решарпер) делает из эффективного непонятного кода более понятный, иногда — ценой эффективности.

Вопросы эквивалентности программ — не самые простые, и в деталях подходы к ним могут отличаться. Тем не менее, есть определённый консенсус в плане того, что считается рефакторингом.
Дедушка Фаулер считал, что рефакторинг — это изменение структуры того же самого кода. Отсюда и название — рефакторинг, т.е. "пере-разложение на множители". То есть типа 4*3 и 3*4 — одно и то же, как и 6*2, и 2*2*3, а вот 5*7 — это уже что-то другое.

PJ>Ну разве что в вашем уютном мирке.
И в уютных мирках миллионов других программистов.
S>>Вынос метода сравнения элементов при сортировке в параметр — является рефакторингом.
PJ>И когда решарпер добавит фичу в рефакторинг, вот это будет срыв шаблона.
Какую фичу? Замену способа сортировки? Ну-ну.

PJ>Нет, спасибо.
Зато у нас не ломаются файлы конфигурации. Каждому своё.

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

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


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

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

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

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

"Никто — ни конечный пользователь, ни программист — не сможет сказать по внешнему виду, что что-то изменилось"

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

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

S>О чём нам намекают все эти сходства?
На то, что твоя трактовка трудов дедушки Фаулера нелепая. Не благодари.

S>Компилятор делает из понятного неэффективного кода непонятный эффективный; программист (или решарпер) делает из эффективного непонятного кода более понятный, иногда — ценой эффективности.

S>Вопросы эквивалентности программ — не самые простые, и в деталях подходы к ним могут отличаться. Тем не менее, есть определённый консенсус в плане того, что считается рефакторингом.
S>Дедушка Фаулер считал, что рефакторинг — это изменение структуры того же самого кода. Отсюда и название — рефакторинг, т.е. "пере-разложение на множители". То есть типа 4*3 и 3*4 — одно и то же, как и 6*2, и 2*2*3, а вот 5*7 — это уже что-то другое.

Еще один голос дедушки. Да он вообще даже не изобретал его
Берем вики.

Although refactoring code has been done informally for decades, William Griswold's 1991 Ph.D. dissertation[22] is one of the first major academic works on refactoring functional and procedural programs, followed by William Opdyke's 1992 dissertation[23] on the refactoring of object-oriented programs

Оттуда же.

Typically, refactoring applies a series of standardised basic micro-refactorings, each of which is (usually) a tiny change in a computer program's source code that either preserves the behaviour of the software, or at least does not modify its conformance to functional requirements.

Есть трудности с пониманием?

PJ>>Ну разве что в вашем уютном мирке.
S>И в уютных мирках миллионов других программистов.
Что у вас за мания величия? Ну вот кто тебя давал право говорить за миллионы?

S>>>Вынос метода сравнения элементов при сортировке в параметр — является рефакторингом.
PJ>>И когда решарпер добавит фичу в рефакторинг, вот это будет срыв шаблона.
S>Какую фичу? Замену способа сортировки? Ну-ну.
На например замена for на linq. В твоем определении это ну никак не может быть рефакторингом.

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

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

S>Наверное есть какой-то общий код, который каждый из модулей вызывает для сохранения конфигурации, не так ли?
Есть конечно. Библиотечный.

S>У вас этот общий код уже умел определять, что побит один (или несколько) файлов, и заставлять всех откатываться к дефолтной настройке. Значит, теперь он будет уметь вместо "отката к дефолту" делать "открыть предыдушую версию".
Я себе скоро лицо отобью с твоим пытливым умом. Как ты думаешь, почему видна откатывает на контрольную точку все файлы, а не просто каждый файл на предыдущую версию, которые она тоже умеет? Все еще не понял? Ну читай дальше.
Откат к дефолтной настройке тривиальный. Модулю не надо ничего знать о соседях. У всех они свои. Достаточно вернуть ошибку и сбросится. Получив ошибку все остальные получат команду на сброс тоже. Тут нельзя промахнуться. Есть либо согласованные файлы на диске, либо согласованное начальное состояние. В случае когда у всех есть история нужен еще один уровень абстракции, потому что размер истории может быть разным. Надо знать куда откатываться, чтобы не нарушить согласованность. Соотвественно, каждый модуль дожен не просто записать и вернуть результат, а вернуть еще и верисии и хеш файлов, для снапшота, а так же уметь загружать запрошенную версию, а не что попало. И это рефакторинг, потому что функционально в модулях ничего не изменилось. Вызывают другую функцию и все, ну и сигнатура другая.

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

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

PJ>На то, что твоя трактовка трудов дедушки Фаулера нелепая. Не благодари.
Не буду

PJ>Оттуда же.
PJ>

PJ>Typically, refactoring applies a series of standardised basic micro-refactorings, each of which is (usually) a tiny change in a computer program's source code that either preserves the behaviour of the software, or at least does not modify its conformance to functional requirements.

PJ>Есть трудности с пониманием?
Нету. Вижу, что мы с Ikemfula больше упираем на preserves the behaviour of the software, а вы настаиваете на более слабых требованиях.
При этом по вашему же варианта определения утечка памяти для рефакторинга — норм, ведь она не затрагивает функциональные требования.

PJ>Что у вас за мания величия? Ну вот кто тебя давал право говорить за миллионы?


S>>Какую фичу? Замену способа сортировки? Ну-ну.
PJ>На например замена for на linq. В твоем определении это ну никак не может быть рефакторингом.
Почему? Может. Технически, замена for на linq — это серия Extract method. Тот же самый код, структурированный по-другому.
Вот такая замена является рефакторингом:

foreach(var name in names) if (name=="Joe") yield return name

return names.Where((name)=>name=="Joe")

Точно так же, как и такая:

return from name in names where name=="Joe" select name

А вот такая — нет:

return namesIndex.Contains("Joe") ? namesIndex["Joe"]: Enumerable.Empty<string>()

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

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

PJ>Есть конечно. Библиотечный.
Ну вот и отлично.

PJ> Я себе скоро лицо отобью с твоим пытливым умом. Как ты думаешь, почему видна откатывает на контрольную точку все файлы, а не просто каждый файл на предыдущую версию, которые она тоже умеет? Все еще не понял? Ну читай дальше.
Очевидно — по той же причине.

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

Ну ок, теперь в целом понятно.

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

S>Переполнение буфера.

Скорее, просто шизофазия.

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

Рефакторинг бывает разным — коротким и длинным, а также средним. Но независимо от длины любого конкретного этапа, рефакторинг требует времени. Как правило, в сумме потраченное на рефакторинг время — не меньше времени, потраченного на говнокодинг, плюс проценты и пеня за просрочку технического долга. И если манагер склонен к микроменеджменту, как практически все плохие манагеры — он неминуемо начнет "оптимизировать затраты".

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

I>Как интересно, сначала ты выдал "Любые плохие пиэмы". Теперь не любые а только многие. Эдак ты дойдешь до конкретных вместо многих

Любые из тех, с кем сталкивался я лично. С кем сталкивался кто-то другой, или говорит что сталкивался — про это мне ничего не известно, по очевидным причинам.
Но, по правде говоря, тихий алкаш, который просто бухает и не мешает работе — это далеко не самый худший вариант по сравнению с теми, с кем я сталкивался.

I>Вот смотри, мой вариант, в единицах business value

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

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

_AB>Остальное читать не буду, ибо ты пока поднадоел, а тут есть дискуссия поинтереснее.

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

_AB>Если она затухнет, а ты не успокоишься, продолжу в тебя палочкой тыкать.

Что-то выдавало Штирлица нарцисса...

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

I> Любые внешние провеки, в любом количестве.

Идеальный рефакторинг — он как сфероконь в вакууме. Сушествует только в трудах теоретиков.

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

I>>Вот смотри, мой вариант, в единицах business value

C>В твоем варианте, программист делает работу и за себя, и за менеджера.

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

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

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

I>> Любые внешние провеки, в любом количестве.

C>Идеальный рефакторинг — он как сфероконь в вакууме. Сушествует только в трудах теоретиков.

Это говорит только о тебе и твоем опыте.

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

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

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

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

S>Нету. Вижу, что мы с Ikemfula больше упираем на preserves the behaviour of the software, а вы настаиваете на более слабых требованиях.
Я-то как раз ни на чем не настаиваю. Если вы хотите понимать его по своему, то флаг вам в руки. А вот вы, с какого-то перепугу, настаиваете на том, что ваши трактовки единственно верные.

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

S>Почему? Может. Технически, замена for на linq — это серия Extract method. Тот же самый код, структурированный по-другому.
Нет, это не тот же самый код. Можешь декомпилятором разобрать. Более того, емнип, если функция возвращает IEnumerable, то она внезапно может стать ленивой, в то время как c for нет. Если строго следовать вашей трактовке, то это не рефакторинг, если не начать вытаскивать из кустов "дополнительные соглашения", которые Фаулер явно имел ввиду, но забыл описать.

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

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

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

S>>Т.к. рефакторинг производит эквивалентные преобразования, то добавить утечку он никак не может. За это его и ценят.
PJ>Может конечно. Вот прям на вики и написано.
PJ>

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

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

Разумеется, переписывание. Любое изменение кода есть переписывание — и оптимизации, и фичи, и что угодно. Рефакторинг это переписывание при готором соблюдаются определенные правила, а следовательно предоставляются гарантии.

Без этих правил получаешь просто какое то переписывание, а что на выходе —

Аналогично и с оптимизациями — если замерять кое как, то и выходе будет абы что.

S>>Нету. Вижу, что мы с Ikemfula больше упираем на preserves the behaviour of the software, а вы настаиваете на более слабых требованиях.
PJ>Я-то как раз ни на чем не настаиваю. Если вы хотите понимать его по своему, то флаг вам в руки. А вот вы, с какого-то перепугу, настаиваете на том, что ваши трактовки единственно верные.

Не наши, а Фаулера Я, например, прочёл и его книги, и его сайт, и кучу других смежных вещей, например Физерс, Бек, Кериевски и тд. Они все пишут об одном и том же.

Здравствуйте, 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>Ну, нет, разумеется. Куда писать они не решают. Откуда такой странный вопрос?
Ну, вы же написали, что у вас все модули независимые, и вы не хотели ограничивать фантазию авторов в плане записи конфигурации. Может вы и место не хотели ограничивать — .
А если место выбирает не модуль, а некий общий код, то мы можем в этом общем коде сделать и перенаправление чтения конфигурации куда нам удобно — например, на последнюю консистентную версию.
А модуль вообще ничего про версии знать не будет. Ну, например.

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

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

S> то есть часть про "if done poorly" вы пропустили. Ну, ок. С такой оговоркой я согласен.
Как же я пропустил, если специально цитату привел? Весь смысл в том, что даже плохо выполненный рефакторинг, все равно рефакторинг. В твоей вселенной это нечто невозможное, по определению.

S>Я согласен с преимуществом простых определений. Но вы начинаете строить какие-то непонятные мне предположения:
То, что они тебе непонятные не говорит ровным счетом ни о чем, кроме того, что тебе они непонятные.

S>Нет, так не работает. В функциональных требованиях никто не упоминает вообще ничего про память. В 99% в требованиях к софту вообще нет ничего про память; в оставшемся проценте это часть нефункциональных требований, и формулируется она в стиле "должно запускаться на машине с 16GB RAM, 1GB места на диске".
Ну вот ты сейчас опять натягиваешь сову на глобус. Функциональные требования могут быть любые. Вообще. Не спрашивая твоего одобрения или твоей оценки их полезности.

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

S>Такие вещи остаются за рамками требований, кроме очень специальных классов приложений. И ни разу отсутствие таких оговорок не служило поводом разбираться, типа "если вы не заложиди в согласованных с нами требованиях умение падать, когда не хватает памяти, адресного пространства, или места на диске, то вы обязаны не падать".
У нас есть требование работать без перезагрузки. Это просто невозможно выполнить, если память течет. И есть специальный duration test, где проверяется и это требование. Тестеры в жизни не пропустят версию, если увидят рост потребления памяти.

S>Да, код структурирован по другому. Вместо прямого вызова a == 3 происходит вызов делегата, внутри которого лежит ссылка на предикат "a => a==3".
Это другой код. Более того, в зависимости от реализации IEnumerable оно параллельным может стать.

S>Все три приведённые варианта — ленивые. Внезапности никакой не будет.
Все которые ты привел, но это не все которые решарпер поддерживает.

S>Надо просто внимательно смотреть, что именно делает этот рефакторинг.
Ну да, либо имеет целью изменить функциональные требования, либо нет. Больше ничего выдумывать не надо.

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

S>Оно даже может быть справедливо — до определённого момента. А может быть неверным сразу, просто ваше исследование домена оказалось неполным. C'est la vie.
В этом случае его надо переделывать. И это тоже нормально. Вопрос в том насколько это сложно. Если делать не по феншую, то будет боль. Ты считаешь это нормальным, а я нет.

S>И даже монстры типа Microsoft регулярно бывают вынуждены откатывать назад апдейты своих публичных API — это что касается "не страдают".
Ну вряд ли они это считают нормальным.

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

S>Ну, вы же написали, что у вас все модули независимые, и вы не хотели ограничивать фантазию авторов в плане записи конфигурации. Может вы и место не хотели ограничивать — .
оопшники...
Разумеется их никто не ограничивает в выборе формата, и даже места внутри их песочницы. но кто же им даст писать-то? Это ж сайд-эффект. Во-первых, они должны быть на границе системы, а во-вторых, кто ж доверит модулю, читай хрен с горы, изменять состояние системы?
Модуль определяет, грубо говоря, две функции save :: Data -> Path -> Result<> и load :: Version optional -> Path -> Result<>, делая частичное применение для остальных своих потребностей. Кто как и зачем их вызовет вне контроля модуля. Но, про версию он знать все равно должен, это в сигнатуре библиотечной функции, которая делает фактическую загрузку.

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

I>Это говорит только о тебе и твоем опыте.

И о твоем.
В теории, разницы между теорией и практикой нет. А на практике, она есть.

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

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

Вот ты сейчас на что вообще отвечал? Голосам в своей голове?

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

S>>Нет, так не работает. В функциональных требованиях никто не упоминает вообще ничего про память. В 99% в требованиях к софту вообще нет ничего про память; в оставшемся проценте это часть нефункциональных требований, и формулируется она в стиле "должно запускаться на машине с 16GB RAM, 1GB места на диске".
PJ>Ну вот ты сейчас опять натягиваешь сову на глобус. Функциональные требования могут быть любые. Вообще. Не спрашивая твоего одобрения или твоей оценки их полезности.
Неа. Требования делятся на функциональные (что программа должна делать) и нефункциональные (как она должна это делать). См. например https://analytics.infozone.pro/formation-requirements-and-classification-requirements/
Вы, конечно же, можете называть "рефакторингом" процесс внесения или исправления багов или реализацию фич.
Можете называть требования к потреблению памяти функциональными.

S>>Ни разу в жизни я не видел (и не надеюсь увидеть) оговорок в требованиях к софту насчёт граничных условий: типа "а вот тут, если кончилось место на диске, то приложение должно выдать вот такое-то сообщение".
PJ>Т.е. ты зная как "устроена жизнь" держишь голову в песке? У нас такое сообщение есть и пользователи его регулярно видят. А почему оно тебя так пугает?
Меня совершенно не пугает сообщение. Мне интересно, есть ли у вас документ, в котором оно затребовано — и был ли он до начала разработки, или его написали задним числом, когда пользователи столкнулись с таким поведением.

На всякий случай поясню: я совершенно не против таких документов, совсем наоборот. Просто в большинстве реальных задач есть более-менее обозримое количество "положительных" сценариев, которые нужны пользователям.
И есть на порядок большее количество сценариев, в которых что-то пошло не так. Если выписывать все возможные сценарии падения, то стоимость фазы "подготовка требований" взлетает в небеса, и есть риск так и не взяться за собственно написание кода. Поэтому либо (95%) на это вообще забивается, и софт пишется только для оптимистичного сценария, либо (5%) пишется какая-то общая клауза, типа "в случае неожиданной проблемы, софт должен записать в лог максимум подробностей, показать сообщение об ошибке, и постараться вернуться к стабильному состоянию либо закрыться. Недопустимо портить файлы пользователя, недопустимо продолжение работы в некорректном состоянии".
Всё. В результате мы имеем вполне себе популярные программы от передовиков производства, котрые ухитряются падать, вообще ничего не сообщая пользователю. Винда за них выдаёт окошечко "Приложение не смогло прочитать свой файл данных, и его пришлось пристрелить".

Как бы мы ни относились к этому, де-факто это стандарт качества современного прикладного софта. Прыгать сильно выше него должно быть чем-то оправдано — ну там, спецификой прикладной области (АЭС?), или выбором стратегии "конкуренция по качеству", желательно с внятным пояснением причин, по которым такая стратегия нас не разорит.

PJ>У нас есть требование работать без перезагрузки. Это просто невозможно выполнить, если память течет. И есть специальный duration test, где проверяется и это требование. Тестеры в жизни не пропустят версию, если увидят рост потребления памяти.
Это замечательно, реально, вы одни из очень и очень немногих, кто так делает.
Ну, тогда мы возвращаемся на шаг назад — рефакторинг, который приводит к утечке, изменяет соответствие системы функциональным требованиям и, стало быть, даже самому расслабленному определению рефакторинга не удовлетворяет.
Верно?

PJ>Это другой код. Более того, в зависимости от реализации IEnumerable оно параллельным может стать.
Ну, ок, ладно. Вопрос об эквивалентности параллельного исполнения кода и последовательного для меня слишком сложен Не готов обсуждать, есть ли способ поменять семантику при таком рефакторинге.

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

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

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

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

PJ>Ну я вот тебе пытался рассказывать, а ты просто не слушаешь. Может и они пытались. С другой стороны чсв тебе явно жмет, если думаешь, что у всех голова болит как бы не забыть тебе все рассказать, чего ты не знаешь.
Отож. Именно так всё и обстоит — стараются, рассказывают, зазывают на семинары, лабы и воркшопы. Иногда просят написать и научить их, как правильно делать публичные API. Потому что у них этим занимались люди, гораздо менее способные к этому, чем я. Постепенно мы их обучили; и у них был пик способностей года до 2019 примерно, а сейчас снова к архитектуре допустили недоумков.
(Ну вот из недавнего — их modern commerce api в некоторых случаях приводит к потере корзинки: сервер думает, что заказ оформлен, а клиент думает, что произошёл сбой. Т.е. даже безо всяких изменений API является неустойчивым к пропаданию связи.)
В Autodesk ситуация хуже: мало того, что у них сама система, выставленная наружу — ужос-ужос, SAP интегрированый с salesforce, и оба ещё с каким-то siebel, так и API тоже проектировали люди средних способностей.
Но хорошие новости в том, что они с нами разговаривают, и есть шанс их выучить тоже.

PJ>Модуль определяет, грубо говоря, две функции save :: Data -> Path -> Result<> и load :: Version optional -> Path -> Result<>, делая частичное применение для остальных своих потребностей. Кто как и зачем их вызовет вне контроля модуля. Но, про версию он знать все равно должен, это в сигнатуре библиотечной функции, которая делает фактическую загрузку.
О, это круто, без дураков. Надо всё же выбрать время, прочитать Влашина. Я всю жизнь нутром чуял, что ФП способно на большее, чем вычислять факториалы через tail recursion.

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

S>Неа. Требования делятся на функциональные (что программа должна делать) и нефункциональные (как она должна это делать). См. например https://analytics.infozone.pro/formation-requirements-and-classification-requirements/
Я вообще не понял причем тут этот ответ? От факта существования не-функциональных требований не меняется факт, что функциональные требования могут быть любые. Это ортогональные вещи.

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

S>Можете называть требования к потреблению памяти функциональными.
Они вполне могут быть функциональными.

S>Меня совершенно не пугает сообщение. Мне интересно, есть ли у вас документ, в котором оно затребовано — и был ли он до начала разработки, или его написали задним числом, когда пользователи столкнулись с таким поведением.
Без понятия. Продукту более 20 лет, меня там не стояло. Думаю, если в первой версии и не было, то в следующей уже было.

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

S>И есть на порядок большее количество сценариев, в которых что-то пошло не так. Если выписывать все возможные сценарии падения, то стоимость фазы "подготовка требований" взлетает в небеса, и есть риск так и не взяться за собственно написание кода. Поэтому либо (95%) на это вообще забивается, и софт пишется только для оптимистичного сценария, либо (5%) пишется какая-то общая клауза, типа "в случае неожиданной проблемы, софт должен записать в лог максимум подробностей, показать сообщение об ошибке, и постараться вернуться к стабильному состоянию либо закрыться. Недопустимо портить файлы пользователя, недопустимо продолжение работы в некорректном состоянии".
Это какой-то метод 80х годов, типа водопад. В 2020 если ситуация не описана, а проблема есть, то ее просто обсуждают и добавляют в требования формальное описание. Взять тот же место на диске. У тебя есть функция записи она что-то возвращает и, возможно, ошибку, то эту ошибку (ну, если писать нормально, а не просто кидать исключения в надежде, что кто-то их где-то поймает) мне надо обработать, хотя бы просто окошко пользователю показать, потому что операция провалилась. А если пользователю что-то показывается, то это неплохо бы перевести. Итд итп. И вот она уже в требованиях.

S>Как бы мы ни относились к этому, де-факто это стандарт качества современного прикладного софта. Прыгать сильно выше него должно быть чем-то оправдано — ну там, спецификой прикладной области (АЭС?), или выбором стратегии "конкуренция по качеству", желательно с внятным пояснением причин, по которым такая стратегия нас не разорит.
Откуда в разговоре взялся прикладной софт? И почему это должно являться оправданием кривого дизайна и игнорирования ошибок? И я не понимаю почему ты решил, что это дорого? Поддерживать некачественную программу дорого. Практически ты никогда не знаешь когда она выпуститься, всегда уши вылезут — хвост увязнет. Конечно если в современных условиях не использовать современные технологии, тот же DDD или FP, который дает сильно больше, чем факториалы через рекурсию, то писать придется больше, а качество будет низким. И иногда придется продажу выдавать за подписку. Ну так это просто "стратегия" стрельбы по своим ногам, ССЗБ.

PJ>>У нас есть требование работать без перезагрузки. Это просто невозможно выполнить, если память течет. И есть специальный duration test, где проверяется и это требование. Тестеры в жизни не пропустят версию, если увидят рост потребления памяти.
S>Это замечательно, реально, вы одни из очень и очень немногих, кто так делает.
Так делают многие, уж точно все (ну или большинство) кто пишет софт для промышленности. Да и у вас неужели нормально, если память будет течь?

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

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

PJ>>Нет, я выставляю контракт, что вот это поле никогда не будет null, и что все внутри будет валидным и уж точно это никак не связано с моделью.
S>
А что забавного? Если бы парадом командовал я, то я бы не выставлял факт подписки, чтобы кто-то что-то с этим делал. Я бы выставил конкретный api для конкретного use case. И возможно там нужна была не подписка, а какое-то производное от нее. Типа оплачено. Или еще как. Чем меньше потребитель api знает о потрохах, то лучше спит.

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

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

S>Отож. Именно так всё и обстоит — стараются, рассказывают, зазывают на семинары, лабы и воркшопы. Иногда просят написать и научить их, как правильно делать публичные API. Потому что у них этим занимались люди, гораздо менее способные к этому, чем я. Постепенно мы их обучили; и у них был пик способностей года до 2019 примерно, а сейчас снова к архитектуре допустили недоумков.
Ты хочешь сказать, что все байки про интервью в МС, где они отбирают лучших это все вранье и потом эти высокооплачиваемые "неодоумки" просят со стороны обучить их API делать?

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

C>И о твоем.

Разумеется. Я удосужился прочитать не только Фаулера, но и его товарищей. А после этого каждого из них попробовать.

C>В теории, разницы между теорией и практикой нет. А на практике, она есть.

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

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

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

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

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

C>Вот ты сейчас на что вообще отвечал? Голосам в своей голове?

Смотрим вместе

I>Вот смотри, мой вариант, в единицах business value

В твоем варианте, программист делает работу и за себя, и за менеджера.

Я привел тебе конкретный пример, который был создан разработчиком, т.к. мной после анализа 'SOS' в чате.
Аналогично поступает и тестировщик, если самостоятельно найдет баг.
Тим-лид поступает аналогично.
ПиЭм так не поступает. он такие тикеты никогда вручную не создаёт. Он даже создание тикетов верхнего уровня, типа эпиков, фич и тд делегирует тимлиду.