Какой самый популярный стиль организации кода вы встречали в корпоративных кодовых базах? Лично я чаще всего видел решение, подразумевающее группировку всех файлов по их типу. Таким образом, к примеру, в системе MVC все контроллеры, все сервисы, все репозитории, все POJO и так далее находятся вместе. Давайте назовем такое решение "стековым" стилем организации кода.
Впервые принципы SOLID были представлены в 2000 году в статье Design Principles and Design Patterns Роберта Мартина, также известного как Дядюшка Боб.
С тех пор прошло два десятилетия. Возникает вопрос - релевантны ли эти принципы до сих пор?
Перед вами перевод статьи Дядюшки Боба, опубликованной в октябре 2020 года, в которой он рассуждает об актуальности принципов SOLID для современной разработки.
Недавно я получил письмо с примерно следующими соображениями:
Годами знание принципов SOLID было стандартом при найме. От кандидатов ожидалось уверенное владение этими принципами. Однако позже один из наших менеджеров, который уже почти не пишет код, усомнился, разумно ли это. Он утверждал, что принцип открытости-закрытости стал менее важен, так как по большей части мы уже не пишем код для крупных монолитов. А вносить изменения в компактные микросервисы - безопасно и просто.
Принцип подстановки Лисков давно устарел, потому что мы уже не уделяем столько внимания наследованию, сколько уделяли 20 лет назад. Думаю, нам стоит рассмотреть позицию Дена Норса о SOLID - “Пишите простой код”
Так вышло, что на заре моей карьеры в IT меня покусал Oracle -- тогда я ещё не знал ни одной ORM, но уже шпарил SQL и знал, насколько огромны возможности БД.
Знакомство с DjangoORM ввело меня в глубокую фрустрацию. Вместо возможностей -- хрена с два, а не составной первичный ключ или оконные функции. Специфические фичи БД проще забыть. Добивало то, что по цене нулевой гибкости мне продавали падение же производительности -- сборка ORM-запроса не бесплатная. Ну и вишенка на торте -- в дополнение к синтаксису SQL надо знать ещё и синтаксис ORM, который этот SQL сгенерирует. Недостатки, которые я купил за дополнительную когнитивную нагрузку -- вот уж где достижение индустрии. Поэтому я всерьёз считал, что без ORM проще, гибче и в разы производительнее -- ведь у вас в руках все возможности БД.
Так вот, эта история с SQLAlchemy -- счастливая история о том, как я заново открыл для себя ORM. В этой статье я расскажу, как я вообще докатился до такой жизни, о некоторых подводных камнях SQLAlchemy, и под конец перейду к тому, что вызвало у меня бурный восторг, которым попытаюсь с вами поделиться.
Задачу генерации текстовых строк по шаблону никак нельзя назвать новой, даже с натяжкой. Сюда можно отнести и заполнение стандартных форм наподобие приходных кассовых ордеров, и экспорт XML/JSON во внешние системы, когда состав данных меняется реже формы их представления. Если основательно задуматься в момент натягивания совы на глобус, то в ту же категорию можно отнести и задачу формирования отчетов, и настраиваемые реализации метода ToString(), и… да много еще чего.
Объединяет эти случаи одно: входными данными являются не только какие-то циферки сами по себе, но и шаблон, на основании которого они должны быть отформатированы для потребителя. Для программистов это удобно тем, что из разработки выкидывается довольно жирный кусок рутины, который можно перепоручить кому попало другим отделам. Для пользователей тоже хорошо, так как позволяет творить всякую фигню и настраивать продукт под себя (что бы это ни значило). Ну и совсем уж замечательно становится, когда внезапные изменения внешнего вида документов, придуманные затейниками из Минфина, не требуют внепланового деплоя новой версии продукта, а всего лишь элегантной правки шаблона.
В общем, оставим сову в покое и признаем, что в некоторых случаях шаблоны – это хорошо. А вот что нам может предложить .NET для того, чтобы воспользоваться преимуществами этой идеи?
Микросервисы — это не всегда хорошо и не нужно их применять бездумно. Меня бомбит от того, что все хотят себе микросервисы. Не понимают зачем, но хотят. Даже в компаниях из двух человек многие разработчики хотят втянуть раздробить свой продукт на десяток микросервисов. Не надо.
При написании нового метода или сервиса мы стараемся его максимально абстрагировать от внешних зависимостей, чтобы новый функционал реализовывал только заложенную ему логику. Об этом, собственно, нам и говорит один из принципов SOLID - Принцип единственной ответственности (single responsibility principle).
Я постоянно встречаю код, где если у метода больше двух входных аргументов, добавляется условный (array $args), что влечет за собой реализацию проверки наличия ключа, либо она отсутствует и тогда увеличивается вероятность того, что метод может закрашиться в рантайме.
Возможно, такой подход в PHP сложился исторически, из-за отсутствия строгой типизации и такого себе ООП. Ведь как по мне, то только с 7 версии можно было более-менее реализовать типизацию+ООП, используя strict_types и type hinting.
Привет, меня зовут Алексей, я системный архитектор e-commerce платформы Lamoda, и в этом посте — мое представление о том, чем на самом деле занимается ИТ-архитектор, какие вопросы решает в ежедневной работе и за что несет ответственность.
С начала 90-х ИТ-сфера сильно эволюционировала, и роль архитектора (я не буду говорить о профессии, потому что считаю, что как таковой ее у нас нет) развивалась вместе с ней. В 2021-ом перед ним стоит задача куда шире, чем проектирование. Он как архитектор зданий, которому нужно не просто построить условный дом, но и вписать его в окружающий контекст, включить в существующую экосистему. Архитектор принимает решения о важных вещах, выступает катализатором изменений, которые нужны проекту. Он использует нарративы, описывая, как должны выглядеть системы и какие паттерны использовать, чтобы команда могла их одобрить и реализовать
Почему у многих возникают проблемы с этим принципом? Если ли более простое объяснение?
️В данной статье мы НЕ будем рассматривать общие примеры данного принципа, о которых уже есть много материалов (пример с квадратом и прямоугольником или управления термостатами). Здесь мы немного подробнее остановимся на таких понятиях как «Предусловия», «Постусловия», рассмотрим что такое ковариантность, контравариантность и инвариантность, а также что такое «исторические ограничения» или «правило истории».
Классический сценарий использования большинства приложений, будь то веб или любое другое приложение с пользовательским интерфейсом: пользователь заходит в приложение, просматривает какую-то информацию, вводит свои данные, сохраняет. Весь сценарий состоит из потоков данных: либо идущих от сервера к пользователю – на чтение, либо от пользователя идущие на сервер – на запись.
Современные приложения работают со все большим количеством информации, и, понятно, что чем эффективнее подходы работы с потоками данных, тем эффективнее работа приложения в целом.
За пять предыдущих лет человечеством было произведено информации больше, чем за всю предшествующую историю (из них половина была произведена в нашем отделе УНП).
Проблематика
Существует класс приложений, в которых пользователи модифицируют исходные данные, но эти модификации должны применяться к основной системе только после согласования некоторой третьей стороной - руководителями/специалистами/сторонними организациями/другими уполномоченными пользователями. Также по итогам предварительного ознакомления с изменениями и ревью часто требуется внести некоторые корректировки, чтобы снова отправить на согласование, и после нескольких итераций изменения вступают в силу. Создается новая базовая модель, в которую также можно вносить изменения, которые необходимо согласовывать - процесс повторяется.
Мы занимались разработкой именно такой системы, и сегодня речь пойдет о новой версии реализации системы, которую мы разработали совместно со Skirgus.
Фантастическая история о том, как программисты приложение разрабатывали.
Собрались однажды 2 разработчика. И нужно было им новую HTTP API реализовать для игрового магазина. Дошло дело до выбора БД, которую стоит применить в проекте:
- Слушай, а как мы выберем? Реляционную БД использовать или NoSQL. В частности, может нужна документоориентированная?
- Сперва нужно понять какие данные будут в нашей предметной области!
Привет друзья! С вами Алекс и я продолжаю серию статей, посвящённых применению шаблонов проектирования в языке Golang.
Интересно получать обратную связь от вас, понимать на сколько применима данная область знаний в мире языка Golang. Ранее уже рассмотрели шаблоны: Simple Factory, Singleton и Strategy. Сегодня хочу рассмотреть еще один шаблон проектирования - Prototype.
Разработка корпоративных приложений со сложной бизнес-логикой всегда несет за собой немалые затраты. Причём львиная доля затрат приходится не на саму разработку, а на поддержку кода приложения: добавление нового функционала, поиск и исправление допущенных ошибок, рефакторинг и т.п. Мне как разработчику ПО всегда хотелось найти “серебряную пулю” для вопросов, возникающих при конструировании кода приложений, как написать потенциально сложное приложение, чтобы его было поддерживать как можно легче и дешевле. В этой статье хочу поделиться практическими знаниями о проектировании архитектуры кода программного обеспечения, полученными из опыта.
Наверное, каждый разработчик надеется, что разрабатываемая им система будет удобна и эффективна как для пользователей, так и для технической поддержки. Хочется все продумать и сделать хорошо сразу. Но объективно достичь это сложно. Всего не предусмотришь, да и ситуация со временем точно будет меняться. "Удобно и эффективно" предполагает выполнение почти всех операций программно, а не вручную. Тупой и рутинной работы человек делать не должен!
Перевод статьи "Why most unit testing is waste?"
Автор: James O Coplien, Перевод: Епишев Александр
1.1 Наши дни
Во времена FORTRAN, когда функция была функцией, иногда заслуживающей функциональных проверок, юнит-тестирование было одним из главных составляющих. Компьютеры производили вычисления, в то время как функции и процедуры представляли собой вычислительные блоки. В те времена доминирующий подход в дизайне предполагал создание комплексной внешней функциональности из более мелких кусков, которые, в свою очередь управляли еще более мелкими, и так далее, вплоть до уровня хорошо понятных примитивов. Каждый слой поддерживал находящийся над ним слой. В целом, у вас были большие шансы отследить, как функциональность на самом дне, так называемые функции и процедуры, были связаны с требованиями, выраженными в доступном человеку интерфейсе. Можно было рассчитывать, что хороший дизайнер поймет бизнес цель той или иной функции. Такими же возможными для понимания были и взаимосвязи в дереве вызовов, как минимум в хорошо структурированном коде. Вы могли мысленно смоделировать выполнение кода во время код-ревью.
Архитектура ПО — это Вселенная. Все очень сложно, но если все правильно, то все невероятно просто. Шаг за шагом познаю что и как. Ищу лучшие практики и шаблоны. В конечном счете, в очередной раз делаю одно и то же заключение:
Изученные правильные практики и шаблоны проектирования - лишь вектор, который вдохновляет на новые красивые и уникальные решения.
Здесь нет примеров хорошей архитектуры, советов как должно быть и как правильно. Я просто хочу зафиксировать мысли, которые надо не забывать воспроизводить при решении очередной задачи.
* В данной статье примеры будут на TypeScript
Что такое DDD (Domain Driven Design) вопрос обширный, но если в кратце (как Я это понимаю) — это про перенос бизнес логики, как она есть, в код, без углубления в технические детали. То есть в идеале, человек, который знает за бизнес процессы, может открыть код и понять, что там происходит (так кстати часто бывает в 1С).
Всё это сопровождается кучей разных рекомендаций по технической реализации вопроса.
Для лучшего понимания статьи советую прочитать материалы, касающиеся DDD.
Привет, друзья. С вами Alex Versus.
Ранее мы говорили про шаблоны проектирования Одиночка и Стратегия, про тонкости реализации на языке Golang.
Сегодня расскажу про Фабричный метод.
Системы Skyscanner сложно назвать маломасштабными. Наш сайт и приложение каждый месяц используются миллионами путешественников, мы обрабатываем умопомрачительные объёмы запросов, используя микросервисную архитектуру, которая сама по себе далеко не маленькая. В общей совокупности у нас задействовано несколько сотен микросервисов и микросайтов (веб-приложений, поддерживающих определённую часть нашего сайта), обслуживаемых сотнями экземпляров AWS Lambda и библиотек. Каждое из этих средств хранится в своём собственном репозитории GitHub, что даёт некоторые преимущества с точки зрения разделения задач, но имеет и свою цену: когда одно и то же изменение нужно выполнить во всех этих репозиториях, как это можно осуществить?
