Из современного конструктора LEGO можно собрать только одну модель игрушки, например, самолет. Кастомизировать? Можете поменять местами кресла пилотов — вот и вся кастомизация. Лет 30 назад из конструктора можно было собрать примерно все, от самолета до грузовика, при том же количестве деталей как и в современных. Создатели большинства современных методологий в детстве играли в старое Лего. Те, кто сейчас пользуется методологиями — играли уже в современный. Разница в инженерных практиках огромна.



Под катом Филипп Дельгядо (dph) расскажет об инженерном подходе к формированию методологии. Все проекты и команды разные, а лидеры — неповторимы. Подогнать одну методологию под всех не получится — таких просто нет. Придется брать конструктор и строить из него что-то свое, уникальное. В расшифровке одного из лучших докладов TeamLead Conf не будет секретных тайн шаолиньских монахов — только банальности, проверенные опытом. Нас ждет каталог деталей методологии разработки, на что обращать внимание при ее конструировании и внедрении, правила перестраивания методологий. Для всех идей приведены реальные примеры из опыта Филиппа. За свою карьеру он попробовал все — от Visual Basic до хардкорного SQL, разрабатывал крупнейший в России букмекерский движок и Яндекс.Деньги, а сейчас работает над нагруженными проектами на Java. Регулярно делает доклады на разных конференциях, в том числе и на HighLoad++.

В рамках недавно прошедшей конференции DotNext 2018 состоялся BoF по Domain Driven Design. На нем был затронут вопрос работы с исключениями, который вызвал жаркий спор, но не получил развернутой дискуссии, поскольку не являлся основной темой.

Также, изучая множество ресурсов, начиная от вопросов на stackoverflow и заканчивая платными курсами по архитектуре, можно наблюдать, что в IT-сообществе сложилось неоднозначное отношение к исключениям и к тому, как их использовать.

Наиболее часто упоминается, что с использованием исключений легко построить поток исполнения, имеющий семантику оператора goto, что плохо сказывается на читабельности кода.

Есть разные мнения о том, стоит ли создавать собственные типы исключений или использовать стандартные, поставляемые в .NET.

Кто-то делает валидацию на исключениях, а кто-то повсеместно использует монаду Result. Справедливо, что Result позволяет по сигнатуре метода понять, возможно ли не только успешное выполнение. Но не менее справедливо, что в императивных языках (к которым относится C#) повсеместное использование Result приводит к плохо читаемому коду, засыпанному конструкциями языка настолько, что с трудом можно разглядеть исходный сценарий.

В данной статье я расскажу о практиках, принятых в нашей команде (если кратко — мы используем все подходы и ни один из них не является догмой).

Речь пойдет об enterprise-приложении, построенном на базе ASP.NET MVC+WebAPI. Приложение построено по луковой архитектуре, общается с базой данных и брокером сообщений. Используется структурированное логирование в ELK-стек и настроен мониторинг при помощи Grafana.