Программисты много говорят про сложность решений. Мы можем часами размышлять о правильных шаблонах, красивых абстракциях и цепочках зависимостей. Однако, давайте поговорим открыто, всегда ли сложность обусловлена решаемой проблемой? Не оказываемся ли мы в плену наших стереотипов и убеждений?
Привет! В Монолите весь код должен быть в едином стиле, a в разных микросервисах можно использовать разные подходы, языки программирования и фреймворки. Для простых микросервисов с 1 — 2 контроллерами и 1 — 10 действиями особо смысла городить слои абстракций нет. Для сложных микросервисов с различными состояниями и логикой перехода между ними наоборот лучше изначально не лениться. Я хочу рассказать о моем опыте организации кода и использования подходов DDD, Портов и Адаптеров для обоих случаев. Есть кратко суть статьи: Джун — пишет код в контроллере. Мидл — пишет кучу абстракций. Сеньор — знает когда нужно писать код в контроллере, а когда нужны абстракции.Читать полностью »
В Тинькофф для разработки систем автоматизации бизнес-процессов мы используем фреймворк Camunda + Spring. Сами бизнес-процессы описываем с помощью BPMN (Business Process Management Notation) в виде блок-схем.
Наиболее часто используемый элемент на наших схемах — service tasks (прямоугольник с шестеренкой). Camunda поддерживает два способа выполнения service tasks:
Второй способ позволяет выполнять задачи с помощью внешних систем — например, если нужно вызвать одно camunda-приложение из другого или вообще делегировать работу в какую-либо внешнюю систему.
Читать полностью »
Архитектурный или проектный рефакторинг это всегда болезненная проблема на проекте. Польза от рефакторинга, для нас технических специалистов очевидна, но продать и обосновать эту идею клиенту зачастую бывает тяжело. Главная причина в том, что мы технические специалисты не знаем как говорить с бизнесом.
Главная проблема в коммуникация между техническими специалистами и людьми, которые делают деньги. Они говорят на разных языках, хотя и пытаются решить одни и те же проблемы.
Данная статья является переводом оригинала с английского: Architecture Refactoring and Design Refactoring How to Sell it Client. Если у вас есть коллеги, не владеющие русским языком, они могут прочитать оригинал на моем болге.
Польза от рефакторинга очевидна для всех технических специалистов, но зачастую мы не можем донести эту идею до бизнеса. Почему так случается? Мы пропускаем несколько незначительных для нас, но очень важных шагов для бизнеса.
Разделим весь процесс на 6 простых, но обязательных шагов:
Данная статья основана на реальных событиях,
и все проблемы в ней не вымышленные. (С)
В начале хотелось бы отметить, что статья не призвана показать изобретение велосипеда, потому как многие приёмы уже давно существуют в культуре разработки баз данных. Однако обобщить, проанализировать проблемы, которые они могут решить и показать, как с ними можно работать. А проблем хватает несмотря на то, что нормативно-справочная информация (НСИ) не относится к бизнес-логике, а скорее находится в обслуживании у неё. Стандартный процесс по рисованию очередной таблички для хранения справочника очень скоро начинает обрастать костылями или трудоёмкими переделками.
Читать полностью »
Синий кит — отличный пример того, как проектирование сложного проекта пошло не по плану. Кит внешне похож на рыбу, но он млекопитающее: кормит детенышей молоком, у него есть шерсть, а в плавниках до сих пор сохранились кости предплечья и кистей с пальцами, как у сухопутных. Он живет в океанах, но не может дышать под водой, поэтому регулярно поднимается на поверхность глотнуть воздуха, даже когда спит. Кит самое большое животное в мире, длиной с девятиэтажный дом, а массой как 75 автомобилей Volkswagen Touareg, но при этом не хищник, а питается планктоном.
Когда разработчики работали над китом, то не стали писать все с нуля, а использовали наработки из старых проектов. Он словно слеплен из несовместимых частей кода, которые не тестировались, а все проектирование сводилось к выбору фреймворка и к срочному «велосипедированию» уже в продакшне. В итоге получился проект красивый внешне, но с кусками дремучего легаси и костылей под капотом.
Для создания проектов, которые помогают бизнесу зарабатывать, а не похожих на морское животное, которое не может дышать под водой, есть DDD. Это подход, который фокусируется не на инструментах или коде, а на изучении предметной области, отдельных бизнес-процессов и на том, как код или инструменты работают для бизнес-логики.
Что такое DDD и какие инструменты в нем есть, мы расскажем в статье на основе доклада Артема Малышева. Подход DDD в Python, инструменты, подводные камни, контрактное программирование и проектирование продукта вокруг решаемой проблемы, а не используемого фреймворка — все это под катом.
Читать полностью »
Интернет полон статей про UML, вы найдете сотни примеров для каждого вида диаграмм, и без проблем создадите свои, нотация не сложная. Но так ли уж необходимо тратить на это время? Наш богатый опыт говорит «Да». Если у вас в команде более 2 человек и проект от 3 месяцев, то уже имеет смысл отрисовать 2-3 вида диаграмм. В одной нашей команде более 30 человек, проект длительностью более 3 лет, и мы используем...2-3 вида диаграмм.
Нотация UML избыточна. С другой стороны она недостаточна для проектирования распределенных систем, и здесь нам помогает Archimate. В этой статье мы расскажем, что действительно полезно из всего этого многообразия, и рассмотрим на примере полный цикл создания диаграмм для проекта.
Читать полностью »
Оценивая свою работу, я недавно много размышлял о том, как мне писать хороший код. Учитывая, что никто не интересуется тем, как писать плохой код, возникает вопрос: как узнать, что ты написал на Go хороший код? Если есть какая-то шкала между хорошо и плохо, то как понять, какие части шкалы относятся к хорошему? Каковы его свойства, атрибуты, отличительные признаки, паттерны и идиомы?
Читать полностью »
Legacy-код — это «старый» код, возраст которого может быть как 2 месяца, так и 10 лет. Часто его писали разработчики, о которых в компании смутно помнят. Возможно, их вообще не было, а legacy-код родился вместе со Вселенной во время Большого Взрыва. С тех пор требования к нему менялись много раз, код правили в режиме «нужно было еще вчера», а документацию никто не писал, как и тесты. Legacy-код запутан и хрупок, в нем не видно ни начала, ни конца. Как к нему подступиться?
Здесь и далее кадры из сериала «Рик и Морти». Авторы Джастин Ройланд и Дэн Хармон.
Подбираться к нему нужно с тестов, но готовьтесь к боли. Проблемы начнутся уже с того момента, как вы решите взяться за такой проект. Вам нужно понять, зачем вы хотите за него браться, убедить руководство одобрить тестирование legacy-кода, а коллег — помочь. После этого возникнут вопросы, с чего начать изучение, какие тесты запустить первыми и как все не сломать? Но главное — как не впасть в отчаяние, когда поймете, что работе нет конца.
Кирилл Борисов 12 лет в индустрии, за эти годы прошел долгий путь по костылям, битому коду и гниющим каркасам старых систем: от монолитных учетных систем до микросервисов авторизации. Путешествие наградило его опытом и историями, которыми он поделится в виде ценных советов.Читать полностью »
Как выжить в схватке с техническим долгом? Что делать, если у вас легаси тяжелой стадии? В статье на примере трёх кейсов предлагаю разобраться, как построить процесс работы с техническим долгом и какие инженерные подходы для этого использовать.
Читать полностью »
