Сообщение Re[60]: Годами не могу вырваться из некорректных вопросов на от 01.05.2020 16:18
Изменено 01.05.2020 16:49 Poopy Joe
Re[64]: Годами не могу вырваться из некорректных вопросов на
Здравствуйте, 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 делать?
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 делать?
Re[60]: Годами не могу вырваться из некорректных вопросов на
Здравствуйте, 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 делать?
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 делать?