Здравствуйте, 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, Вы писали:
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# тоже врёте. Делов-то.