Здравствуйте, 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# тоже врёте. Делов-то.
Я не имел ввиду уж такое вранье. Я говорил о преувеличениях. Вроде все программисты со мной согласны, или все так делают, это стоит кучу денег, без реального анализа. У тебя я такое вижу, наверняка есть и у меня. Немного иронии или самоиронии не помешает в разговоре, не надо из этого делать трагедию.

Здравствуйте, 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# тоже врёте. Делов-то.
Я не имел ввиду уж такое вранье. Я говорил о преувеличениях. Вроде все программисты со мной согласны, или все так делают, это стоит кучу денег, без реального анализа. У тебя я такое вижу, наверняка есть и у меня. Немного иронии или самоиронии не помешает в разговоре, не надо из этого делать трагедию.