Дима пишет | Дмитрий Смотров: заметки с тегом архитектура_кода

Неявные последствия выбора архитектуры

Fri, 11 Jul 2025 11:19:58 +0300

Фото специально размыто, коммерческая тайна и все такое :)

Последний раз писал апишку почти год назад. Сейчас временно моя команда раскидалась на помощь другим, я пошел помогать в старую команду и сел запиливать базовые CRUD операции, тыкать в аналитиков палкой, требуя спецификации к входным и выходным схемам, в темпе вальса мокать апишку, чтобы фронты могли потестить свою верстку и все такое. Типичное крудошлепство, почти отдых, за исключением того, что сервис совсем новый, только в CI закинута болванка сервиса, чтобы можно было деплоится, и все.

Наши сервисы имеют слоистую архитектуру с кучей другой паттернов: адаптеры, репозитории для запросов в хранилище, команды и запросы(привет CQRS), unit of work для обеспечения транзакционности действий в системе, агрегаты, сервисы, билдеры на сервисы и билдеры на модели, все еще на интерфейсах, чтобы тестировать удобно было... Чтобы реализовать ручку, нужно реализовать 5-6 интерфейсов и реализаций. Ситуация, как в тех бородатых анекдотах про реализацию чего-угодно в Java: сначала напишите фабрику, а если фабрика уже есть — напишите абстрактную фабрику. Пришлось вспоминать, как вообще все эти сущности между собой должны дружить.

Понятно, что вернувшись через год к типу задач, реализация которых подразумевает кучу всего, нужно будет переключить мозги, но по моему мнению, если ты возвращаешься к своему проекту и вообще не понимаешь, что тут и как работает — это либо ты сильно все упростил, либо сильно перемудрил. Причем с первым разобраться сильно проще, чем со вторым, на мой взгляд.

Отсюда два вывода:
1) Настраивайте себе шаблонизаторы, когда у вас устоявшиеся подходы.
2) Если ваш сервис предполагает, что про его разработку забудут на полгода-год(на моей памяти есть такой сервис для получения курса валют), есть смысл писать его проще — в плоских структурах и куче if-ов быстрее разобраться(да-да, рубрика «Вредные советы»). Опять же если не написана совсем жесть, тогда земля пухом 🔫.

💻 Всем доброй ночи, а я пошел запиливать себе шаблоны наконец-то, ибо те 30 файликов на скрине ПРа меня утомили. Это кстати реализация Create операции, с тестами...

Замена циклов

Wed, 28 May 2025 21:57:41 +0300

Есть вещи из моей практики C++ программиста(кроме статической типизации), по которым я скучаю.
Например по алгоритмам из стандартной библиотеки.

Вот на примере кусок кода все из той же Chromium OS, который двигает панели.

На первом скрине исходный код, на втором и третьем результат рефакторинга. Вариант на третьем скрине использует обобщенный бинарный алгоритм поиска, за счет чего более хорош по сложности, но суть не в этом.

Суть в очень красивом, по моему мнению, и лаконичном подходе с использованием обобщенного программирования или дженериков в простонародье. Насильно все к ним приводить не стоит, но уместное использование сильно режет количество кода. Меньше кода — меньше https://dimasmotrov.ru/all/menshe-znaesh-krepche-spish/ потенциального места для ошибок.

В питонячьей среде дженерики тоже есть, но вот аналога stl нет, да и не будет его. А мест, где нужно итерироваться по коллекциям, тьма. Пишем for дальше, что поделать 💻

Меньше знаешь — крепче спишь

Wed, 28 May 2025 21:55:11 +0300

Фраза спорная, но в написании кода помогает: несколько раз за последние 2 недели ловил себя на смешной ошибке, когда автодополнением кода вставлял имя не той переменной, которое требовалось.

В моем случае ошибки относительно безобидные — несколько раз в логи вместе поля computer_uid я писал просто uid. В будущем это явно бы могло сыграть со мной злую шутку, если бы пришлось решать проблему на стороне клиента.

Причем подобные ошибки достаточно легко пропустить, а допустить их можно много раз в одном блоке кода.

Можно себя обезопасить, задав себе вопрос: а не слишком ли много знает этот кусочек кода/класс/подпрограмма?

Если много — то уберите лишний контекст, дайте ровно столько данных, сколько нужно. Дадите больше данных — можете их криво использовать.

Интересно, почему в MISRA или NASA стандартах для надежного C кода, который должен стабильно работать в автомобилях и на луне, нет подобного пункта.

Отберите у себя возможность ошибки, как родители отбирали у вас провод от компьютера в детстве💻