Сообщение Re[13]: Компьютеры с правом системного владения - уходят? от 28.03.2024 10:23
Изменено 28.03.2024 10:27 Pauel
Re[13]: Компьютеры с правом системного владения - уходят?
Здравствуйте, pva, Вы писали:
pva>Речь не шла о каком-то их изобретении — банально доступ к управлению hotspot и т.п. которое вынесли из юзерлевела в систем.
pva>Они просто следуют по пятам гугла добавляя кучу ограничений в АПИ и режут поддержку в KNOX.
Нету здесь никакого следования по чьим то примерам. Всё АПИ, к которому вы даёте доступ, означает прежде всего умножение работы для вас
1 дополнительный мейнтенанс
2 дополнительная документация
3 дополнительный девелопмент суппорт
4 дополнительный суппорт
5 дополнительные издержки с версионированием
Как только вы комуто дали доступ, вам теперь вообще все фичи надо писать с оглядкой, вам теперь добавляет длинный перечень работ.
На примере. Вот, скажем, есть у вас либа — клиент к вашему приложению.
Разработчики вон того проекта просят дать доступ к http клиенту или возможность подкидывать свой собственный http клиент или понадобавлять интерцепторов туда и сюда
Вы соглашаетесь — это ж круто и всё такое.
А теперь смотрите какая вещь — если вы захотите добавить какую то схему аутентификации, вам придется приседать вдвое больше
1 мейнтейнить код связаный этим http клиентом — например, понаписывать тестов на все случаи жизни, что вызовы идут через внешних хттп клиент как положено, ошибки транслируются как надо, конфигурация применяется как положено, маппинг значений туда и обратно
2 документация — вам надо описать всё, что относится к особенностям работы с внешним http клиентом — интерфейсы, параметры, маппинг туда-обратно, обработку ошибок и тд
3 помощь разработчикам и командам в использовании вашего компонента, траблшутинг и тд
4 багфикс идет через прослойку менеджеров, где надо согласовывать как именно фиксить
5 теперь изменение кода связанного с хттп клиентом должно отражаться в версиях, и не дай бог внесете ломающее изменение , вам придется месяцами ходить на митинги и объяснять что и почему вот так вот сделано
Теперь маленький рефакторинг для перформанса или экономии памяти может оказаться для вас недоступным, т.к. он ломает интеграцию с внешним клиентом который юзает половина команд
Или так — одна команда команда просит добавить oidc client credentials grant, а другая просит "убрать аутентификацию вовсе т.к. она ест перформанс, а у них всё в приватной сети"
И теперь, раз вы дали доступ к вашему внутреннему апи, вам нужно разребать кучи таких кейсов, анализировать, добавлять ключики тут и там
В итоге ваш клиент требует для развития или в несколько раз больше людей, или в несколько раз большие сроки, и многократно больше тестов в любом из случаев.
pva>Речь не шла о каком-то их изобретении — банально доступ к управлению hotspot и т.п. которое вынесли из юзерлевела в систем.
pva>Они просто следуют по пятам гугла добавляя кучу ограничений в АПИ и режут поддержку в KNOX.
Нету здесь никакого следования по чьим то примерам. Всё АПИ, к которому вы даёте доступ, означает прежде всего умножение работы для вас
1 дополнительный мейнтенанс
2 дополнительная документация
3 дополнительный девелопмент суппорт
4 дополнительный суппорт
5 дополнительные издержки с версионированием
Как только вы комуто дали доступ, вам теперь вообще все фичи надо писать с оглядкой, вам теперь добавляет длинный перечень работ.
На примере. Вот, скажем, есть у вас либа — клиент к вашему приложению.
Разработчики вон того проекта просят дать доступ к http клиенту или возможность подкидывать свой собственный http клиент или понадобавлять интерцепторов туда и сюда
Вы соглашаетесь — это ж круто и всё такое.
А теперь смотрите какая вещь — если вы захотите добавить какую то схему аутентификации, вам придется приседать вдвое больше
1 мейнтейнить код связаный этим http клиентом — например, понаписывать тестов на все случаи жизни, что вызовы идут через внешних хттп клиент как положено, ошибки транслируются как надо, конфигурация применяется как положено, маппинг значений туда и обратно
2 документация — вам надо описать всё, что относится к особенностям работы с внешним http клиентом — интерфейсы, параметры, маппинг туда-обратно, обработку ошибок и тд
3 помощь разработчикам и командам в использовании вашего компонента, траблшутинг и тд
4 багфикс идет через прослойку менеджеров, где надо согласовывать как именно фиксить
5 теперь изменение кода связанного с хттп клиентом должно отражаться в версиях, и не дай бог внесете ломающее изменение , вам придется месяцами ходить на митинги и объяснять что и почему вот так вот сделано
Теперь маленький рефакторинг для перформанса или экономии памяти может оказаться для вас недоступным, т.к. он ломает интеграцию с внешним клиентом который юзает половина команд
Или так — одна команда команда просит добавить oidc client credentials grant, а другая просит "убрать аутентификацию вовсе т.к. она ест перформанс, а у них всё в приватной сети"
И теперь, раз вы дали доступ к вашему внутреннему апи, вам нужно разребать кучи таких кейсов, анализировать, добавлять ключики тут и там
В итоге ваш клиент требует для развития или в несколько раз больше людей, или в несколько раз большие сроки, и многократно больше тестов в любом из случаев.
Re[13]: Компьютеры с правом системного владения - уходят?
Здравствуйте, pva, Вы писали:
pva>Речь не шла о каком-то их изобретении — банально доступ к управлению hotspot и т.п. которое вынесли из юзерлевела в систем.
pva>Они просто следуют по пятам гугла добавляя кучу ограничений в АПИ и режут поддержку в KNOX.
Нету здесь никакого следования по чьим то примерам. Всё АПИ, к которому вы даёте доступ, означает прежде всего умножение работы для вас
1 дополнительный мейнтенанс
2 дополнительная документация
3 дополнительный девелопмент суппорт
4 дополнительный суппорт
5 дополнительные издержки с версионированием
Как только вы комуто дали доступ, вам теперь вообще все фичи надо писать с оглядкой, вам теперь добавляет длинный перечень работ.
На примере. Вот, скажем, есть у вас либа — клиент к вашему приложению.
Разработчики вон того проекта просят дать доступ к http клиенту или возможность подкидывать свой собственный http клиент или понадобавлять интерцепторов туда и сюда или дать доступ к серилизатору-десериализатору
Вы соглашаетесь — это ж круто и всё такое.
А теперь смотрите какая вещь — если вы захотите добавить какую то схему аутентификации, вам придется приседать вдвое больше
1 мейнтейнить код связаный этим http клиентом — например, понаписывать тестов на все случаи жизни, что вызовы идут через внешних хттп клиент как положено, ошибки транслируются как надо, конфигурация применяется как положено, маппинг значений туда и обратно
2 документация — вам надо описать всё, что относится к особенностям работы с внешним http клиентом — интерфейсы, параметры, маппинг туда-обратно, обработку ошибок и тд
3 помощь разработчикам и командам в использовании вашего компонента, траблшутинг и тд
4 багфикс идет через прослойку менеджеров, где надо согласовывать как именно фиксить
5 теперь изменение кода связанного с хттп клиентом должно отражаться в версиях, и не дай бог внесете ломающее изменение , вам придется месяцами ходить на митинги и объяснять что и почему вот так вот сделано
Теперь маленький рефакторинг для перформанса или экономии памяти может оказаться для вас недоступным, т.к. он ломает интеграцию с внешним клиентом который юзает половина команд
Или так — одна команда команда просит добавить oidc client credentials grant, а другая просит "убрать аутентификацию вовсе т.к. она ест перформанс, а у них всё в приватной сети"
И теперь, раз вы дали доступ к вашему внутреннему апи, вам нужно разребать кучи таких кейсов, анализировать, добавлять ключики тут и там
В итоге ваш клиент требует для развития или в несколько раз больше людей, или в несколько раз большие сроки, и многократно больше тестов в любом из случаев.
Поэтому, в разработке АПИ правило большого пальца это "отказать"
pva>Речь не шла о каком-то их изобретении — банально доступ к управлению hotspot и т.п. которое вынесли из юзерлевела в систем.
pva>Они просто следуют по пятам гугла добавляя кучу ограничений в АПИ и режут поддержку в KNOX.
Нету здесь никакого следования по чьим то примерам. Всё АПИ, к которому вы даёте доступ, означает прежде всего умножение работы для вас
1 дополнительный мейнтенанс
2 дополнительная документация
3 дополнительный девелопмент суппорт
4 дополнительный суппорт
5 дополнительные издержки с версионированием
Как только вы комуто дали доступ, вам теперь вообще все фичи надо писать с оглядкой, вам теперь добавляет длинный перечень работ.
На примере. Вот, скажем, есть у вас либа — клиент к вашему приложению.
Разработчики вон того проекта просят дать доступ к http клиенту или возможность подкидывать свой собственный http клиент или понадобавлять интерцепторов туда и сюда или дать доступ к серилизатору-десериализатору
Вы соглашаетесь — это ж круто и всё такое.
А теперь смотрите какая вещь — если вы захотите добавить какую то схему аутентификации, вам придется приседать вдвое больше
1 мейнтейнить код связаный этим http клиентом — например, понаписывать тестов на все случаи жизни, что вызовы идут через внешних хттп клиент как положено, ошибки транслируются как надо, конфигурация применяется как положено, маппинг значений туда и обратно
2 документация — вам надо описать всё, что относится к особенностям работы с внешним http клиентом — интерфейсы, параметры, маппинг туда-обратно, обработку ошибок и тд
3 помощь разработчикам и командам в использовании вашего компонента, траблшутинг и тд
4 багфикс идет через прослойку менеджеров, где надо согласовывать как именно фиксить
5 теперь изменение кода связанного с хттп клиентом должно отражаться в версиях, и не дай бог внесете ломающее изменение , вам придется месяцами ходить на митинги и объяснять что и почему вот так вот сделано
Теперь маленький рефакторинг для перформанса или экономии памяти может оказаться для вас недоступным, т.к. он ломает интеграцию с внешним клиентом который юзает половина команд
Или так — одна команда команда просит добавить oidc client credentials grant, а другая просит "убрать аутентификацию вовсе т.к. она ест перформанс, а у них всё в приватной сети"
И теперь, раз вы дали доступ к вашему внутреннему апи, вам нужно разребать кучи таких кейсов, анализировать, добавлять ключики тут и там
В итоге ваш клиент требует для развития или в несколько раз больше людей, или в несколько раз большие сроки, и многократно больше тестов в любом из случаев.
Поэтому, в разработке АПИ правило большого пальца это "отказать"