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

S>Можно менять структуру кода, без изменения семантики.
И что такой рефакторинг даст? Результат басни "квартет"?

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

S>Возьмите любой браузер или веб-приложение. Вон, докерс при попытке заказать товар с доставкой на адрес почтового агрегатора выдаёт "card authorization failure", хотя деньги успешно встают на hold.
Ну т.е. фронтенд в вебе?! Надо натянуть сову на глобус по самые уши, чтобы назвать это все.

PJ>>А типа берем 100к умножаем на 30, потому что 30 можем, выглядит менее абсурдно что ли?
S>30 — это минимальное количество компаний, которые потребляют API, о котором я говорю.
Ага, у и каждой ущерб по 100к. Абсурд и есть.

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

S>Сколько стоит установка обновления на каждом из них — уже не вам, а им?
Так про то и речь. И нам деньги и им деньги. И это не веб, а реальное производство, которое надо останавливать, если это не плановое, а реально проблема. И то никто не считает 100к помножим на 30.

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

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

PJ>>Разумеется оно так и сделано. Даже странно тут предполагать обратное. Была команда File.Save возвращающая void, стала команда MyFile.Save, возвращающая версию и хеш. Нахрена бы это в модуле считать?!
S>Ну вы же сами написали, что модули теперь должны передавать куда-то хеш для снапшота.
Ну вернула MyFile.Save хеш и что с ним дальше должно случиться?

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

S>ER — это не про базу данных. Это формализация описания модели; очень часто используется для моделирования благодаря своей простоте.
Модель, база данных, а причем тут API?

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

PJ>>Ну если все доводить до идиотизма, то можно и так. А можно сделать один метод GetAvailableProperies где все вернуть в виде списка.
S>И получаем те же яйца, вид сбоку. Вы всего лишь отложили проблему до вызова GetAvailableProperties, и по-прежнему оставили N+1 вызов API вместо 1.
Нет, не те же. В первом случае подписка обещана, во втором нет. Возможно, конечно, что у вас совсем странные разработчки у клиентов (ну или ты их таковыми считаешь), но, обычно, есть большая разница между обещанными данными и возможными.

S>Мы — нет. Но нам не всегда доступна роскошь переписать огромную систему целиком только потому, что в 2005 году у архитекторов не было того опыта, который есть у нас в 2020.
Но сейчас-то вы рандомизируете? В новых API?

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

S>А откуда я знаю, что из совпадения этого числа с какой-то формулой от нескольких результатов GetOrdersBatch(x) что-то следует? Откуда я знаю эту формулу?
Из названия типа, разумеется. Не, ну api для прочитать придется конечно. Странно, что ты не ожидаешь этого, но ожидаешь завязывания на контент вывовов.

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

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

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

_AB>Интересно, когда до тебя дойдет, что всегда софт разрабатывается на основе предположений той или иной степени детализированности и подтвержденности...
Интересно до тебя дойдет, что таким тоном ты будешь общаться сам с собой, в основном? Можешь просто не тратить усилий на набивание текста.

_AB>Вот, например, клиент заказал разработку системы, которая должна перевернуть его индустрию. Клиент очень много усилий и денег посвятил разработке модели, дизайна, общался со своими клиентами, опираясь на свой огромный опыт в индустрии писал ТЗ. Делал презентации, собирал фидбек. Собирал группы клиентов и проводил практические сессии. Он потратил несколько месяцев на это. Мы сделали всё, как просили. Оказалось, что предположения, которые делали и клиент и клиенты клиентов по поводу того, как им хотелось бы работать с системой, оказались несколько неверными. Причем в некоторых вещах кардинально неверными. К счастью, т.к. и наш клиент и мы сами имеем опыт работы, мы с самого начала ориентировались на выпуск MVP с последующей переоценкой, поэтому "много денег и усилий" не оказалось "чрезмерно много денег и усилий" и большую часть разработанного можно использовать или переделать с минимальными потерями.

Спасибо кэп, кто бы мог подумать, что требования могут меняться?!
Модель может строится на предположениях, API должно строится на сценариях использования.
Сценарий ты можешь предполагать, и предположение может отказаться неверным, но внутри него никаких предположений нет. Если там есть subscription-id, то есть и ответ зачем, иначе это не сценарий.

PJ>>Есть множество практик как подобного избегать, то же DDD например.
_AB>Ну и как эта практика помогает полностью избежать неопределенности, сложности и изменчивости окружающего мира?
Четко разделяя приложение на ограниченные контексты, изолируя модель от внешнего мира, разделяя логику и окружение внешнего мира и там еще много чего есть.

Здравствуйте, Poopy Joe, Вы писали:
S>>Можно менять структуру кода, без изменения семантики.
PJ>И что такой рефакторинг даст? Результат басни "квартет"?
Нет. Начинаем сначала: по Фаулеру, рефакторинг даёт улучшение понятности кода.
Более понятная интерпретация — после рефакторинга меняется нефункциональная характеристика "стоимость внесения изменения".
То есть можно пытаться починить баг в лапшекоде без изменения структуры — это будет стоить X.
А можно сначала сделать рефакторинг за Y, и починка бага станет стоить X/K, где K >> 1.
То же самое про фичи.

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

PJ>Ну т.е. фронтенд в вебе?! Надо натянуть сову на глобус по самые уши, чтобы назвать это все.
Да в любое приложение ткни — именно так и будет. Консоль управления от Parallels Baremetal, когда я ей пользовался, тупо глотала ошибки, прилетающие из протокола управления.
Акронис труимаж: не получается заресториться из бэкапа — показываем окошко "что-то пошло не так", завершаемся.
(С ним мне повезло — благодаря личным связям, удалось отправить лог разработчикам, которые нашли в чём дело, и вылепили хотфикс. Был бы я обычным клиентом модели "один из миллионов", я бы неделю бодался с фронт-лайн саппортом, который бы кормил меня вопросами типа "а вы точно вставили диск перед тем, как начинать рестор?").

Вы хотите чего — чтобы я вам полный список такого софта привёл? Да их тут тыщи. Скорее, придётся поискать такой софт, который делает хоть как-то по другому.

PJ>Ага, у и каждой ущерб по 100к. Абсурд и есть.
В СУММЕ ущерб 100к. Арифметика, я погляжу, вам так и не даётся.

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

PJ>Началось мерянее копеечкой. А как же ваша изоляция инженеров от денег?
Вы не на тот вопрос отвечаете. Я нигде не предлагал изолировать инженеров от денег.

PJ>Ну вернула MyFile.Save хеш и что с ним дальше должно случиться?
Вот и мне непонятно — модулю-то он зачем? Просто вернуть выше по стеку?

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

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

S>>И получаем те же яйца, вид сбоку. Вы всего лишь отложили проблему до вызова GetAvailableProperties, и по-прежнему оставили N+1 вызов API вместо 1.
PJ>Нет, не те же. В первом случае подписка обещана, во втором нет.
Потрясающее упорство в непонимании. Я вам пытаюсь объяснить, что и в первом случае у нас может быть nullable SubscriptionID — семантически это ровно то же самое, что и отдельный GetAllProperties. Всё, что вы делаете — это усложняете корректное использование API. Да, и такие системы я тоже видел — где вообще ничего не обещано. Разработчик вызывает GetAllProperties на интересующих его объектах, выясняет, что свойство с ID=7 это как раз номер подписки, и для всех интересующих его объектов оно непусто. И пишет тот самый код, где // TODO: handle the case where SubscriptionID is empty.

PJ>Возможно, конечно, что у вас совсем странные разработчки у клиентов (ну или ты их таковыми считаешь), но, обычно, есть большая разница между обещанными данными и возможными.
Да все разработчики плюс-минус одинаковы.

PJ>Но сейчас-то вы рандомизируете? В новых API?
Сейчас во всех новых API идут GUIDы в качестве идентификаторов.

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

PJ>Из названия типа, разумеется. Не, ну api для прочитать придется конечно. Странно, что ты не ожидаешь этого, но ожидаешь завязывания на контент вывовов.
Вот мы и вернулись к тому, что можно хоть заприседаться с сигнатурами, а в конце всё упирается в банальное текстовое описание "вот так вы можете получить все ордера в системе".
Всё, приплызд идее "да мы просто выставим наружу ещё один GetAllOrdersEx, а старый останется для обратной совместимости и будет возвращать только старые ордера".
А как всё начиналось здорово — grpc, протоколы, тупой синклер не знает, как расширять API...

PJ>Рояль из куста всегда вызывает фейспалм. Есть такой рефлекс. Но никакого описания не будет достаточно если разработчика выставлять идиотом. А у меня ощущение, что ты своих клиентов тамими и выставляешь. И поменять-то они ничего не могут, не раззорив компанию и закладываются на странные вещи, и говорить отказываются, и даже API посмотреть не могут, перед использованием.
Да могут, могут. Просто всё, буквально всё, стоит денег. И их надо экономить, а не рассчитывать на то, что "ну я просто сделаю консервативную сигнатуру и пусть все плачут, кто сделал всё не по фен-шую".
Я же вам привожу конкретные, не воображаемые примеры. Тот же редмонд — вот они решили, что не будут документировать коды ошибок и структуру error response. Типа всё, раз не зафиксировано в спеке, то свобода — пей, воруй, губи гусей.

Но нам-то надо разбираться! Мы должны понять, что вот этот вот 2004 — это "ошибка валидации адреса", и что внутри лежат ErrorDetail с кодами полей, по которым мы можем понять, что именно их не устроило — то ли номер телефона не подходит под формат, то ли зип-код штату не соответствует.
Несмотря на то, что формат errorDetail никак не специфицирован — ни сигнатурой, ни текстовым документом.
Никакое DDD тут не поможет. Ну, не доверяем мы тому, что пришло из этого API. Попробовали распарсить; получилось — отлично, показываем пользователю подробности причин сбоя, предлагаем GUI для исправления параметров и повторной отправки запроса. Не получилось распарсить — пишем в лог, идём по ветке "неизвестно что пошло не так".
Мы идиоты, да? Что должен делать неидиот в такой ситуации?

PJ>Ты обиделся что ли? Прости, не хотел.
Не, просто устаю бисер метать. Особенно когда в ответ банальное "не верю".
Я так тоже могу — наверняка у вас нет там никаких особенно чистой архитектуры, такая же лапша как и у всех. Решения принимаются на основе "метода максимального правдоподобия". Рефакторинг перемешан с фиче девелопментом и багфиксингом; поверх него же идут оптимизации безо всякого плана и метрик. Вы просто врёте — да и всё. И про улучшения в разы при переписывании кода с C# на F# тоже врёте. Делов-то.

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

I>>Любой баг.
PJ>Невозможно гарантировать изменение кода без вероятности внесения бага. Точка.

C этим никто не спорит, вопрос только в шансах получить баг. Они разнятся в зависимости от подхода.

Практика показывает, что рефакторинг именно по-Фаулеру крайне редко чего либо ломает, т.к. максимальный контроль внешнего поведения.

А вот метод "тестируем бизнесом" дает слишком высокие шансы создать новую проблем, т.е. внешнее поведение ты предлагаешь тестировать выборочно.
Что вобщем то очевидно — "изменение только структуры" против "изменение структуры и поведения одновременно"

Наихудшие шансы у переписывания, когда выбросили старое, пилим новое заново вместе с тестами.

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

S>Нет. Начинаем сначала: по Фаулеру, рефакторинг даёт улучшение понятности кода.
Я не знаю, может мы о разных книгах говорим? У Фаулера книга называется "Refactoring: Improving the Design of Existing Code", а вовсе не readability.
Улучшение понятности это хорошо, конечно, но это не дизайн.

S>На колу мочало. Вы описываете изменение функциональных характеристик, и одной рукой пишете, что рефакторинг — это изменения кода без намерения изменить характеристики, а другой — что рефакторинг намеренно делается для их изменения.
S>Двоемыслие детектед.
Это у тебя двоемыслие. Выше ты доказывал, что память это нефункциональное требование, а сейчас, внезапно, их изменении.
У нас, да и никто в здравом уме, не считает лик или еще какие баги функциональными требованиями. Если в результате рефакторинга они просто пропадут, то это хороший, годный, рефакторинг, если добавятся, то poorly done. Вот и все хитрости.

S>Да в любое приложение ткни — именно так и будет. Консоль управления от Parallels Baremetal, когда я ей пользовался, тупо глотала ошибки, прилетающие из протокола управления.
Ну не знаю, винда когда падает всегда есть код ошибки. Ну ладно будем считать, что есть кривые приложения. Не очень понятно, что тут обсуждать. Я думаю мы оба согласны, что так делать не стоит.

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

S>Вы не на тот вопрос отвечаете. Я нигде не предлагал изолировать инженеров от денег.

А вам вообще рассказывают хоть что-то про деньги, или всё же есть изоляция между модулями инженеров и продавцов?

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

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

S>Потрясающее упорство в непонимании. Я вам пытаюсь объяснить, что и в первом случае у нас может быть nullable SubscriptionID — семантически это ровно то же самое
А я тебе пытаюсь объяснить, что это принципиально не то же самое. В первом случае ты говоришь это подписка. Если приходит подписка с пустым ид, не неподписка, это невалидный тип. Ты нарушил инвариант. Уж лучше в этом случае изобретать бесконечную подписку.
Во втором случае это просто данные об ордере. Туда всегда можно добавить тип ордера. Это просто динамические данные, ты ничего никому не обещал — инвариант не нарушен. Я понял твою боль, что ваши клиента на таки мелочи забивают и смотрят на данные. Но тут уж ничего не сделать, это ошибка на их стороне.

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

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

S>Но нам-то надо разбираться! Мы должны понять, что вот этот вот 2004 — это "ошибка валидации адреса", и что внутри лежат ErrorDetail с кодами полей, по которым мы можем понять, что именно их не устроило — то ли номер телефона не подходит под формат, то ли зип-код штату не соответствует.
S>Несмотря на то, что формат errorDetail никак не специфицирован — ни сигнатурой, ни текстовым документом.
S>Никакое DDD тут не поможет. Ну, не доверяем мы тому, что пришло из этого API. Попробовали распарсить; получилось — отлично, показываем пользователю подробности причин сбоя, предлагаем GUI для исправления параметров и повторной отправки запроса. Не получилось распарсить — пишем в лог, идём по ветке "неизвестно что пошло не так".
S>Мы идиоты, да? Что должен делать неидиот в такой ситуации?
Я, возможно, не очень, прости, понял ситуацию. Но я понял так: вы являетесь посредником между МС и вашими клиентами. Иначе бы клиенты разбирались напрямую с МС. У вас и сделано по феншую, по крайней мере как его понимаю я. Этот код только между МС и вами. Вы не просто ему не доверяете, для вас это просто входной параметр, который вы мапите уже на свой error code, в своей модели. И вот уже производную своей модели вы отдаете клиенту. В результате три раза за два года клиент получает ошибку "unknown error code from MS", до момента пока вы не исправите маппинг в своей модели, но и все. Никаких изменений клиенту не требуется, как и никаких затрат. Где проблема?

S>Не, просто устаю бисер метать. Особенно когда в ответ банальное "не верю".
Это работает гораздо лучше, если не считать свои слова бисером, а собеседников свиньями.
Можно просто поговорить за работу, без попыток высокомерного менторства.

S>Я так тоже могу — наверняка у вас нет там никаких особенно чистой архитектуры, такая же лапша как и у всех. Решения принимаются на основе "метода максимального правдоподобия". Рефакторинг перемешан с фиче девелопментом и багфиксингом; поверх него же идут оптимизации безо всякого плана и метрик. Вы просто врёте — да и всё. И про улучшения в разы при переписывании кода с C# на F# тоже врёте. Делов-то.
Я не имел ввиду уж такое вранье. Я говорил о преувеличениях. Вроде все программисты со мной согласны, или все так делают, это стоит кучу денег, без реального анализа. У тебя я такое вижу, наверняка есть и у меня. Немного иронии или самоиронии не помешает в разговоре, не надо из этого делать трагедию.

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

PJ>У нас, да и никто в здравом уме, не считает лик или еще какие баги функциональными требованиями.
Да ладно? Пять постов выше вы мне доказывали, что отсутствие лика — это самое что ни на есть функциональное требование.
Надоедают мне ваши ёрзания.

PJ>Если в результате рефакторинга они просто пропадут, то это хороший, годный, рефакторинг, если добавятся, то poorly done. Вот и все хитрости.


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

PJ>У нас не веб и вот прямой аналогии не получится. У нас производство и если в результате обновления, или ошибки, или фазы луны, у клиента это встанет, то они могут выставить требование на компенсацию ущерба нам. У нашего подразделения прям вот такого не было, но у соседей, я слышал выставляли требование на 400+к, не знаю чем там там кончилось. И это один клиент только.
Ну вот видите. Это примерно то, чего и следовало ожидать. А вы продолжаете строить из себя девочку и говорить "ой, я не понимаю, как это из-за breaking change может кто-то пострадать финансово", и "вывсёврёти, никаких сотен тысяч не будет". При этом у вас же у самих один клиент может встрять на полмиллиона. Специфика веба — только в том, что одним обновлением можно положить не одного клиента, а сразу десятки и сотни.
Даже если клиент не выставил требования вашей компании — это не повод гадить ему в profit and loss report. И любой сотрудник с правом принятия решений должен это понимать.
А не говорить "да откуда там у них 400к — что они, не могут копеечное изменение на своей стороне внести?". "Они что, идиоты — не могли прочитать инструкцию от API?". "Я же ясно написал в сигнатуре — Option<float>, ну и что, что предылущие 15 лет оно никогда Nothing не возвращало".

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

PJ>А я тебе пытаюсь объяснить, что это принципиально не то же самое. В первом случае ты говоришь это подписка. Если приходит подписка с пустым ид, не неподписка, это невалидный тип. Ты нарушил инвариант. Уж лучше в этом случае изобретать бесконечную подписку.
PJ>Во втором случае это просто данные об ордере. Туда всегда можно добавить тип ордера. Это просто динамические данные, ты ничего никому не обещал — инвариант не нарушен.
Омг. Тот же самый инвариант можно получить, просто сделав атрибут "подписка" nullable. Ровно тот же — никто никому ничего не обещает. И оба варианта имеют в длинной перспективе примерно отрицательную полезность.
Отрицательность берётся из того, что имея в API non-nullable SubscriptionID мы хотя бы понимаем, что замена его на nullable — это breaking change, и что надо соблюдать осторожность. Это наш "нулевой" уровень ценности.
А когда у нас есть nullable subscriptionID, или мета-апи типа GetAllProperties, или ещё какая порнография с целью помешать клиенту увидеть наличие связи между ордером и подпиской в модели, то у нас может возникнуть иллюзия о том, что изменение будет non-breaking. Понимаете?
Это как бумажный забор вдоль пропасти: если его нету, мы хотя бы будем идти там аккуратно. А когда есть бумажная стена, изображающая бетон, то мы рискуем смело опереться на неё и спикировать вниз. Ваше понимание проблемы — на уровне "да ну, откуда там пропасть, в худшем случае — неудобная обочина".

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

PJ>Бывает конечно. Когда проще написать заново, чем изменять то, что есть. Вот хоть бразузеры возьми, теме тебе должна быть близкой.
Да-да. Пример Netscape отлично показывает, что бывает с теми, кто решил "написать заново".
Пример Edge — тоже. Что у нас там ещё на плаву осталось? Ткните пальцем в браузер, который выиграл от идеи "написать заново".

PJ>Я не говорил про текстовое описание, я говорил про тип. У тебя опять заготовленный ответ из будущего?
Тогда я не понимаю, что именно вы предлагаете "прочитать" в предыдущей фразе. Давайте так: вы приведёте сигнатуры API в каком-то понятном виде. Можно в виде интерфейса C# — имена, параметры, типы.
Его относительно легко вытащить наружу хоть как SOAP, хоть как JSON/REST, хоть как XML-RPC, поэтому деталями сериализации можно пренебречь.

И мы поймём, достаточно ли сигнатуры для того, чтобы делать глобальные выводы вроде того, что один ордер не может быть вёрнут и GetOrderBatch(1) и GetOrderBatch(2), или что цепочка вызовов таких методов вернёт нам полную коллекцию.

PJ>Я, возможно, не очень, прости, понял ситуацию. Но я понял так: вы являетесь посредником между МС и вашими клиентами. Иначе бы клиенты разбирались напрямую с МС. У вас и сделано по феншую, по крайней мере как его понимаю я. Этот код только между МС и вами. Вы не просто ему не доверяете, для вас это просто входной параметр, который вы мапите уже на свой error code, в своей модели. И вот уже производную своей модели вы отдаете клиенту. В результате три раза за два года клиент получает ошибку "unknown error code from MS", до момента пока вы не исправите маппинг в своей модели, но и все. Никаких изменений клиенту не требуется, как и никаких затрат. Где проблема?
Клиент получает ошибку не три раза за два года, а три раза за два года происходит факап.
Выглядит он примерно так: в полусотне мест в мире заказы начинают падать с ошибкой "происходит непонятная фигня". По статистике мы знаем, что от 2% до 5% заказов валятся именно из-за того, что микрософту не нравится адрес.
Пока наш код отрабатывает успешно, пользователь видит понятное сообщение, исправляет ошибку, и переотправляет заказ.
Когда наш код перестаёт понимать, что происходит, это выглядит так, что "что-то пошло не так". Часть пользователей просто разворачивается и идёт делать заказ в другое место. Часть пользователей обращается в саппорт.
Саппорт долго и мучительно выясняет, что же там сломалось. Напомню: падает не один заказ! Падает каждый 20й заказ, а поток идёт плотный.
Допустим, саппорт конкретного партнёра достаточно быстр, чтобы раскопать причины проблемы и сообщить нам за сутки (это утопия, но чоб не пофантазировать).
Мы, в свою очередь, берём руки в ноги, воспроизводим проблему, убеждаемся, что всё понято верно. Пишем тикет в Микрософт, дескать, "что за фигня происходит". С их саппортом быстрее, чем через неделю, ничего не добьёшься.
Поэтому мы, естественно, параллельно правим наш код. Теперь он умеет парсить и старый и новый форматы — потому что мало ли что, они могут и откатить такое изменение.
Занимает это, оптимистично, ещё сутки. Вот у нас готов хотфикс. Самый-самый отважный партнёр готов накатить хотфикс "вот прямо сейчас", то есть сегодня в стейджинг, и завтра — в продакшн.
Менее отважные сначала проведут тестирование регрессии, а на прод поставят только в выходные.
То есть в течение минимум трёх дней у полусотни партнёров каждый 20й заказ фейлится. Каждый из этих фейлов потребует вмешательства саппорта — а это стоит денег.
Нашими затратами на выпуск хотфикса для такой проблемы можно и пренебречь — они однократны. А вот стоимость ручной обработки всех этих фейлов и развёртывания апдейтов заставляет денюжку капать.
Теперь надо вспомнить о том, что помимо наших партнёров есть ещё и другие — смельчаки, которые работают с этим АПИ напрямую. Вот эта вот работа по выяснению подробностей, экспериментам, переписке с MS, внесению правок в код и тесты для него — у них она не делится на всех, как у наших партнёров, а проводится каждым из них независимо. Поэтому кумулятивный ущерб быстро растёт.

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

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

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

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

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

S>Это я пытаюсь использовать ваши же определения, чтобы вас понять.
Угу, я вижу...

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

S>Ну вот видите. Это примерно то, чего и следовало ожидать. А вы продолжаете строить из себя девочку и говорить "ой, я не понимаю, как это из-за breaking change может кто-то пострадать финансово", и "вывсёврёти, никаких сотен тысяч не будет". При этом у вас же у самих один клиент может встрять на полмиллиона. Специфика веба — только в том, что одним обновлением можно положить не одного клиента, а сразу десятки и сотни.
Это очень серьезное исключение, а не результат любой ошибки.

S>Даже если клиент не выставил требования вашей компании — это не повод гадить ему в profit and loss report. И любой сотрудник с правом принятия решений должен это понимать.
S>А не говорить "да откуда там у них 400к — что они, не могут копеечное изменение на своей стороне внести?". "Они что, идиоты — не могли прочитать инструкцию от API?". "Я же ясно написал в сигнатуре — Option<float>, ну и что, что предылущие 15 лет оно никогда Nothing не возвращало".
Давай вот не будет передергивать. Никто не говорил, что клиентам надо просто ломать все внезапно. С ними можно и пообщаться, и дать время, и постоянно контакт поддерживать. Блин у вас апи поменять, а у нас технологически линии иногда перестраивают, и ничего.

S>Омг. Тот же самый инвариант можно получить, просто сделав атрибут "подписка" nullable. Ровно тот же — никто никому ничего не обещает. И оба варианта имеют в длинной перспективе примерно отрицательную полезность.
Нет, нельзя! Возможно ты не понимаешь значение термина инвариант. Он всегда валиден, всегда. По определению. В твоем случае можно, технически, получить подписку (реальную подписку) с нулевым ид. И ты даже не сможет понять, что он сломан. Это не инваринт.

S> Отож. Пусть попадают на 400к. Главное, что мы молодцы — успешно провели рефакторинг, инварианты сохранены. Пусть найдут того, чья эта ошибка, и лишат его премии. На сто лет вперёд.
Ты будешь смеятся, но попали именно потому что НЕ делали рефаторинг. Ну или делали меняя местами переменные. В результате довели свои проект до состоянии, когда уже просто не могли выдерживать сроки с хоть как-то приемлимым качеством и сорвали дедлайн. А у нас дедлайны, по объективным причинам, жесткие.

S>Да-да. Пример Netscape отлично показывает, что бывает с теми, кто решил "написать заново".
S>Пример Edge — тоже. Что у нас там ещё на плаву осталось? Ткните пальцем в браузер, который выиграл от идеи "написать заново".
Т.е. не начни МС edge, так бы все и пользовались IE? Никто не гарантирует усхпеха, гарантия только на то, что старье сдохло и править его бесполезно.
Я могу ткнуть пальцем в себя, как раз в такой ситауации. Частично благодаря ситуации выше, новый продукт перезапустили с нуля, спросив что вам мешает делать быстро и чего не хватает и дав на все зеленый свет и волю инженерам, а не "параноидальным" менеджерам. Так и F# там появился. И спустя несколько лет всем (причастным внутри) очевидно, что у нас самый легко развиваемый продукт, на точность сроков и качество в котором можно положиться. И сейчас те же топы, которые тогда ссали на ляжки, очень радуются своему решению.

PJ>>Я не говорил про текстовое описание, я говорил про тип. У тебя опять заготовленный ответ из будущего?
S>Тогда я не понимаю, что именно вы предлагаете "прочитать" в предыдущей фразе. Давайте так: вы приведёте сигнатуры API в каком-то понятном виде. Можно в виде интерфейса C# — имена, параметры, типы.
S>Его относительно легко вытащить наружу хоть как SOAP, хоть как JSON/REST, хоть как XML-RPC, поэтому деталями сериализации можно пренебречь.

class BatchOrderResponse 
{
 List<Order> orders;
 BatchOrdersSignature batchSignature;
 ExpectedAllBatchesSignature totalSignature;
 Counter counter; // если надо. итд...
}

class API
{
 GetOrderBatch(...)
 GetAllOrders()
 ValidateSignature(List<BatchSignature>, totalSignature)
}

S>что один ордер не может быть вёрнут и GetOrderBatch(1) и GetOrderBatch(2),
Гарантировать это сервер должен. Ответом это только проверить можно.

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

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

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

PJ>>Невозможно гарантировать изменение кода без вероятности внесения бага. Точка.
I>C этим никто не спорит

I>>"Никто — ни конечный пользователь, ни программист — не сможет сказать по внешнему виду, что что-то изменилось"
I>>(Рефакторинг, 2003, изд Символ, Спб, стра 62 последний абзац)

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

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

C>Как ни странно, тут ты прав. Вся публика как на подбор, хоть колья на головах теши.
Ага, ты один д`Артаньян — мы же уже выяснили это.

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

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

C>2. Как мы уже выяснили, ты считаешь себя крупным специалистом по неврологии, логике и лингвистике (добавь, если я что-то пропустил).
Врешь. Мы такого не выясняли.

C>Правда, решить несложную задачку по программированию почему-то не в состоянии.
Э-э-э... Как неврология, логика и лингвистика связаны с задачей по программированию?

C>Итого, неадекватное самомнение — оно у тебя есть.
Не доказано.

C>Еще одно качество нарциссов — патологическая лживость — тоже есть.
А вот это прямая ложь от тебя. Что там насчет патологической лживости говоришь? Нарциссам свойственна? Верю.

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

C>Сделать это в открытую ты не в состоянии, потому что слишком труслив.

Труслив тот аноним, что мне прислал сообщение в личку в твою поддержку. Вот уж кто труслив. Кстати, это не ты был?

C>Даже с учетом того, что ты вряд ли живешь в стране, где за это может реально прилететь.
Ни в одной вменяемой стране за это никому прилететь не может.

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

C>Никаких особых прав — было бы достаточно убрать дискриминацию. (мечты, мечты)
Убрать отсутствующую дискриминацию.

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

C>Ну и так далее. Ты врёшь буквально на каждом шагу.
Ага, конечно.

C>Или, возможно, у тебя всё же СДВГ и ты просто не в состоянии запоминать дальше чем на пару предложений назад.
Опровергается тем, что неоднократно в дискуссиях здесь, на кывте, я, в отличие от оппонентов, придерживался контекста беседы, а не скакал с одного на другое и не подменял тему разговора. Увы для тебя, твоё предположение не выдержало критики.

C>Остальные симптомы — неадекватное самомнение, графомания, отсутствие способности к эмпатии — всё сходится.
Графомания — это твоя патологическая лживость не удержалась, чтобы откровенный бред не вставить?

C>На хабре, кстати, была статья от чувака с СДВГ. Только он куда адекватнее тебя
C>Почитай, вдруг поможет. В отличие от нарциссизма, это всё же лечится, хотя и в ограниченных пределах.
Напомни-ка мне, что ты там говорил о постановке диагнозов по фотографиям? Двойные стандарты в действии? Не, мне лично пофиг, что ты там мне припишешь. Чем бы дитя не тешилось, лишь бы не размножалось, как говорится. Просто как у тебя в мозгу умещается недовольство тем, что кто-то поставил твой диагноз под сомнение без спец. образования и личного обследования и твоя склонность раздавать диагнозы другим при том самом отсутствии спец. образования и личного обследования?

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

PJ>>>Невозможно гарантировать изменение кода без вероятности внесения бага. Точка.
I>>C этим никто не спорит

C>

I>>>"Никто — ни конечный пользователь, ни программист — не сможет сказать по внешнему виду, что что-то изменилось"
I>>>(Рефакторинг, 2003, изд Символ, Спб, стра 62 последний абзац)

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

Небольшой ликбез по контролю качества — качество, как степень соответствия требованиям, есть вероятностная величина которая никогда не бывает 100%. 0 — да. 100 — никогда.

Никакое количество тестов не гарантирует 100% отсутствие проблем. Такая гарантия заведомо недостижима. При чем не только в разработке, а в инженерии вообще Ни в производстве микроэлектроники, ни в производстве иголок, ни в нарезании хлеба на порции.

Парадокс — из этого никак не следует ненужность тестов, испытаний и тд

Нас интересует степень соответствия требованиям которая определяется методологией, а не количеством тестов. Например, мы точно знаем, какие кейсы работают и используем именно их. Находим другие кейсы — включаем их в тесты, и снова можем использовать.
На самом деле это предположение, если в тестах 2х2=4, то ожидаем, что и в продакшне будет 2х2=4. Если это не так, находим причину, устраняем, покрываем тестами, и снова опираемся на ровно то же предположение.
Соответсвенно, со временем степень соответствия ожиданиям растет.

На примере, ты пишешь некий шустрый аналог мутекса. От него все и всегда ждут гарантий.
1 "Невозможно гарантировать изменение кода без вероятности внесения бага."

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

2 Следовательно, нужен жесткий контроль, не глазом, а фиксация внешнего поведения.

Соответсвенно — внешнее поведение мутекса надо покрыть тестами. Использующий его код — другими тестами.
Более того — при обнаружении проблем их нужно решать и эти кейсы так же покрывать тестами.

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

I>Небольшой ликбез по контролю качества — качество, как степень соответствия требованиям, есть вероятностная величина которая никогда не бывает 100%. 0 — да. 100 — никогда.

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

I>>>"Никто — ни конечный пользователь, ни программист — не сможет сказать по внешнему виду, что что-то изменилось"
I>>>(Рефакторинг, 2003, изд Символ, Спб, стра 62 последний абзац)

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

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

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

_AB>Ага, ты один д`Артаньян — мы же уже выяснили это.

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

_AB>Тыкать палочкой — это поведение исследователя, а не нарцисса. Поведение нарцисса крутится вокруг повышения самооценки, вокруг своего "я".

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

_AB>Ух ты... Так это ты у нас специалист по расстройствам личности и неврологии?

Много прочитал по этому вопросу. Своя рубашка ближе к телу и всё такое.

C>>2. Как мы уже выяснили, ты считаешь себя крупным специалистом по неврологии, логике и лингвистике (добавь, если я что-то пропустил).
_AB>Врешь. Мы такого не выясняли.

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

_AB>Э-э-э... Как неврология, логика и лингвистика связаны с задачей по программированию?

Так ты программист по профессии или нет?

_AB>А вот это прямая ложь от тебя.

Доказано, и много раз. То ты понапишешь одно, то в следующем сообщении уже совсем противоположное.

_AB>Труслив тот аноним, что мне прислал сообщение в личку в твою поддержку.

Нет, скорее просто наивен. Кто это был — без понятия.

_AB>Вот уж кто труслив.

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

_AB>Ни в одной вменяемой стране за это никому прилететь не может.

За клевету — легко, и такое уже много раз бывало. Опять ты пургу несешь.

_AB>Убрать отсутствующую дискриминацию.

Просто посмотри на себя.

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

Я вижу, ты решил врать в духе Геббельса — чем безумнее, тем лучше

_AB>Напомни-ка мне, что ты там говорил о постановке диагнозов по фотографиям? Двойные стандарты в действии? Не, мне лично пофиг, что ты там мне припишешь. Чем бы дитя не тешилось, лишь бы не размножалось, как говорится. Просто как у тебя в мозгу умещается недовольство тем, что кто-то поставил твой диагноз под сомнение без спец. образования и личного обследования и твоя склонность раздавать диагнозы другим при том самом отсутствии спец. образования и личного обследования?

Какие-то симптомы (точнее, их наличие или отсутствие) можно определить по поведению пациента, в том числе и по тому, что он пишет. Какие-то — невозможно без лабораторного обследования.
Ты недавно имел наглость заявить, что никакой эпилепсии у меня нет. Но поставить здесь негативный диагноз — с разумной долей уверенности — можно только по результатам записи ЭЭГ и МРТ, иначе — никак. Вообще никак. Я объяснил достаточно доступно для тебя?
Ты же постоянно ведешь себя как человек с явными проблемами. Здоровые люди так себя не ведут. Точный диагноз я поставить не могу конечно, но с тобой точно что-то очень сильно не так.

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

I>>Небольшой ликбез по контролю качества — качество, как степень соответствия требованиям, есть вероятностная величина которая никогда не бывает 100%. 0 — да. 100 — никогда.

C>Это именно то, что я написал тебе в прошлый раз, но ты уперся рогом. Теперь же внезапно сделал вид, что "я никогда и не говорил другого"
C>Так что я просто процитирую тебя же еще раз:

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

Соответсвенно, ту часть что ты процитировал, надо читать именно в таком вот ракурсе:
"Никто — ни конечный пользователь, ни программист — не сможет сказать по внешнему виду, что что-то изменилось""
Здесь всего лишь про вероятность, а не 100% отсутствие симптомов
"Любые внешние провеки, в любом количестве."
Здесь про степень контроля, который дает нам степень соответствия требованиями. На самом деле, одного контроля недостаточно, методология и техногия играют роль
1. ручной труд дает больше ошибок
2. невнятное проектирование или его отсутствие дают больше ошибок, нежели, скажем, формализованый подход к проектированию.
3. невнятные требования дают хуже качество нежели четкие

И везде речь про вероятность. Проектирования, требования хороши сами по себе, но без контроля они мало(вероятность) чего дают(вероятность). Аналогично и с контролем. Как бы старательно ты не контролировал, кривые требования дадут(вероятность) на выходе кривой(вероятность) продукт.

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

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

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

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

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

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

Это какая то слишком вольная интерпретация. Цитата выше это Фаулер.

Полное отсутствие симптомов достижимо вполне себе. Например, много качественных тестов и они зеленые и так на всех уровнях, логи до соответствуют логам после, а ручное тестирование ничего не находит.

И тем не менее — указаная картина не говорит о 100% отсутствии багов. И это не повод отказываться от рефакторинга.

Хорошо бы увидеть ссылку, а то у тебя какая то вольная интерпретация.

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

I>Это какая то слишком вольная интерпретация.

Это твоя интерпретация.

I>>>"Никто — ни конечный пользователь, ни программист — не сможет сказать по внешнему виду, что что-то изменилось"
I>>>(Рефакторинг, 2003, изд Символ, Спб, стра 62 последний абзац)

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

I>Цитата выше это Фаулер.

А последняя строка — это ты.
Тебе не кажется, что ты уже совсем заврался?

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

C>Это твоя интерпретация.

Нисколько, смотри ниже.

C>

I>>>>"Никто — ни конечный пользователь, ни программист — не сможет сказать по внешнему виду, что что-то изменилось"
I>>>>(Рефакторинг, 2003, изд Символ, Спб, стра 62 последний абзац)

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

I>>Цитата выше это Фаулер.
C>А последняя строка — это ты.

У Фаулера нет указания, какие проверки. Речь только про пользователя и программиста.
С этим согласен?

Следовательно, если программист или пользователь сделают нечто, что обнаружит разницу, изменения не могут считать рефакторингом.
С этим согласен?

Проверяем:
— программист пишет новый тест, который фейлится после рефакторинга
— программист пишет много новых тестов, которые фейлятся после рефакторинга
...

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

C>Тебе не кажется, что ты уже совсем заврался?

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

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

I>У Фаулера нет указания, какие проверки.

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

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

I>>У Фаулера нет указания, какие проверки.

C>Зато у тебя есть. Цитирую еще раз, для самых-самых сообразительных: "Любые внешние провеки, в любом количестве."

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

C>А любые — это может включать в себя и такие вещи, как микроскопические изменение в таймингах, например.

Попробуй прочесть целиком, а не только первую фразу.

Степень соответствия качеству никто не отменял. Я уже говорил, что 100% соответствие не существует. Ты продолжаешь это все игнорировать.

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

Всегда будут изменения это значит, что их всегда можно отыскать тем или иным способом. Эта часть понятна?

Тут ты обычно заканчиваешь читать и пишешь очередной опус.

1 См выше — степень соответствия качеству никогда не бывает 100%. Соответственно, граница рафакторинг-нерефакторинг определяется в т.ч. именно этой степенью соответствия.

2 Есть требования — фукнциональные и нефункциональные, в т.ч. неявные.

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

КАААААК! ЭТО НЕ РЕФАКТОРИНГ!!!!! ТЫ САМ СКАЗАЛ!!!!!!1111 ТЫ ВРЁШЬ!!!расрасрас

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

Итого — микроскопические изменения отражены в требованиях? Если да, от ожидания адеватные. Если нет — то ожидания неадекватные.

Аналогичный пример с твоими таймингами. Ожидания адекватные? Тогда красный тест говорит о том, что изменения ломающие. Неадекватные — ничего не говорит.

Теперь добавляем сюда степень соответсвия. Самое главное — внятно обозначить её. Тогда получится не "любое изменение таймингов" а "изменение таймингов выше уровня х"

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

I>Ты выдрал фразу из контекста.

Врёшь.

I>Я уже говорил, что 100% соответствие не существует.

Это я говорил. Ты же пытался доказывать, что существует. Во всяком случае, до того, как ты сделал разворот на 180 градусов и сам этого не заметил

Возьми наконец свои яйца в кулак и признай, что облажался.