А если крэша не будет, но всем этим людям будет показываться красивое сообщение об ошибке «Приложение не работает — обратитесь к администратору» и работу они делать свою не могут — это окей? Можно не спешить?
Что ж, если решение про «надо бросать и переключаться» или «не надо» — это не к Вам — это многое объясняет. Возможно, когда именно Вам надо будет решать, кому куда переключаться, Вы взглянете на это по другому.
а по мне — есть. и он очень простой — если реакция на событие «бросить текущую работу и переключиться немедленно на проблему» — это действительно критично. Если этого не происходит — значит не так уж оно и важно, чтобы там в логах не было написано.
мне кажется, у меня нет с Вами спора. В вашем приложении уровень качества настолько высок, что падения приложения — это редкое исключительное явление. Потому Вы можете себе позволить трактовать его, как критическое на Вашем проекте. Чем не могут похвастаться все другие проекты.
Вы говорите это так, словно это противоречит чему-то написанному в тексте. Если Вы выдерживаете такой уровень качества, что остановка приложения — это практические невероятное событие — я искренне жму Вам руку. Но статья ведь о том, что механическое придание максимального уровня важности событию, которое происходит регулярно, бессмысленно.
это отлично — это говорит о высоком качестве Вашего приложения, но также существуют продукты/команды, где крэш это «нужно будет глянуть, что там», особенно когда разовый и трудновоспроизводимый
Я понимаю под этим «единицу развертывания». Eдиницы, с которыми непосредственно взаимодействуют люди, я называю «приложения», а те, с которыми не люди — сервисами. Похоже, что приложение в Вашем случае — это сумма «моих» приложений (фронтовых модулей). Ну а проект — это набор таких единиц, который решает задачу.
да, кстати, я предположу из примера пункта 2, что Вы ведете речь не совсем про глобальный слой кода в терминах статьи, а про переиспользование приложения (технического), коим является Ваш сервис настроек. Т.е. это вопрос о построении систем связанных приложений и он существенно шире и сложнее, чем вопрос организации кода для одного приложения. В статье никак не рассмотрены вопросы организации эффективных систем из приложений (сервисов). Грубо говоря, не описано, как решать, что лучше: «посчитать» в самом приложении или получать через «входы» по запросу как готовый результат.
В принципе, мы можете переназвать на свой вкус все специальные слова и это ничего не изменит. Причина, почему у меня .Tech, а не .Infrastructure — моя любовь использовать максимально возможные короткие имена.
Не могу согласиться про .Logic вместо .Calc так как термин логика уже «задействован» для описание слоев — логика приложения и логика бизнеса и будет вызывать путаницу. Имхо, хорошей альтернативой .Calc еще было было бы .Alg — Algorithms.
Про пример — не возьмусь обещать пока. Как оказалось, написать статью намного сложнее, чем мне думалось все это время: )
Спасибо на добром слове. Да, я согласен насчет замечания об однотипности проектов. В черновике статьи я изначально рассуждал об количестве однотипных проектов в повседневной
работе программистов, но решил это выбросить из финальной версии, чтобы уместиться в разумные рамки размера текста.
я бы хотел подчеркнуть, что суть того, что описано в статье, не сильно должны влиять на сами дизайн-решения. Какое бы решение Вы не приняли и кто бы не ставил задачу — так или иначе у вас появится код. А предложенная классификация позволяет этот код более организованно хранить и самой структурой дополнительно отражать замысел его создателя. Если в конкретном проекте некую фичу нецелесообразно делать как чисто глобальную, соответственно Вы и думаете про нее как про «проектную» или «смежную» и позиционируете так. А засчет соглашения и другие участники команды четко знают, как про нее стоит «думать».
Не могу согласиться про .Logic вместо .Calc так как термин логика уже «задействован» для описание слоев — логика приложения и логика бизнеса и будет вызывать путаницу. Имхо, хорошей альтернативой .Calc еще было было бы .Alg — Algorithms.
Про пример — не возьмусь обещать пока. Как оказалось, написать статью намного сложнее, чем мне думалось все это время: )
работе программистов, но решил это выбросить из финальной версии, чтобы уместиться в разумные рамки размера текста.