Проектирование и рефакторинг *

Всем привет! Меня зовут Кирилл Якименко, я – BIM-эксперт компании КРОК, работаю с BIM-технологиями уже около 6 лет, входил даже в клуб Autodesk Expert Elite. В КРОК я занимаюсь тем, что внедряю BIM технологии, развиваю и поддерживаю их применение.

Сегодня я вам расскажу о том, какой путь прошел КРОК в эволюции автоматизации процессов в Revit, как большой и тяжелый проект нам помогал в этом, а не мешал.

Один из самых вредоносных принципов в разработке, когда-либо получивших широкую известность — YAGNI. Его озвучил Рон Джеффрис в 1998, а спустя более двадцати лет — еще и Кармак подлил керосин в огонь со своим: «Неопытным разработчикам трудно оценить, как редко разработка архитектуры с учетом будущих требований приводит к успеху».

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

— Давай предусмотрим передачу конфигурационных параметров в эту функцию? — YAGNI.
— Инъекция зависимости здесь уместнее приколоченной гвоздями реализации хранилища. — YAGNI.
— Черный кофе без сахара, пожалуйста. — YAGNI!

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

Зайду с козырей: КДПВ этой заметки имеет прямое отношение к тексту.

Если вы сфокусируете взгляд на синей рамке, вы увидите растопырившего лапы Амбидиректуса с вытянутой шеей и маленькой головой, развернутой влево. Перефокусируясь на красную рамку, вы познакомитесь с его приготовившимся нырнуть в стену справа Alter Ego, с плотно ввинченной в шею головой и замершими во взмахе назад передними конечностями.

Я показал вам этого Амбидиректуса для того, чтобы проиллюстрировать основную мысль этого текста: споры о превосходстве той или иной парадигмы над остальными — не имеют никакого смысла и всегда являются религиозной войной остроконечников против тупоконечников.

Привет, хабровчане!

Я Дима, Backend-разработчик на Go.

Расскажу о GraphQL, сравню с REST. Разберемся в плюсах и минусах каждого подхода к проектированию API. Выбираем лучший для вашего проекта!

Привет, Хабр! Меня зовут Сережа Сахаров, я PHP-разработчик в Lamoda Tech. Одной из первых задач в компании для меня стал рефакторинг крупной части кодовой базы. Тогда я уже знал о Rector, но использовать его долгое время не доводилось. И в тот момент, что для решения моей задачи он хорошо подойдёт, если добавить еще несколько кастомных правил.
В процессе я получил интересный опыт, который выходит за рамки шаблонного применения инструмента, разобрался во внутреннем устройстве и механизмах работы, и хочу поделиться этим с PHP-сообществом. Если вам часто приходится сталкиваться с рефакторингом старых PHP-проектов, при этом их потребности выходят за пределы штатного набора правил, эта статья для вас.

К сожалению, в последнее время всё больше и больше людей советуют использовать JWT для управления пользовательскими сессиями в веб-приложениях. Это ужасная идея, и в этом посте я объясню, почему.

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

Проверяя код проекта TDengine с помощью PVS-Studio, можно встретить код с запахом, канонические ошибки и опечатки. Многое из этого можно избежать, если изначально аккуратно оформлять код, делать логику простой и избегать макросов. Давайте рассмотрим некоторые фрагменты кода и подумаем, как можно провести его рефакторинг так, чтобы багам просто не было там места.

Недавно я собеседовался в Амазон и Майкрософт в офисы в Испании (так как я тут живу). Пока готовился много что понял, сейчас поделюсь.

Собеседование на проектирование систем.

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

Последние пару лет в свободное от Настоящей Работы время я в роли CTO/соло-бэкендера участвовал в создании Stry — фитнес-стартапа с подписной моделью. Теперь, когда наша команда официально объявила о прекращении дальнейшего развития проекта, пришло время порефлексировать и поделиться полученным опытом. В этой статье я в двух словах представлю продукт, детально опишу архитектуру проекта и расскажу о наших (моих?) основных технических успехах и неудачах. Поехали!

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

Или почему все хотят стать «платформой», даже если не знают, как это работает

Вы замечали, что сегодня все компании — от гигантов типа Netflix до маленького стартапа по записи калорий и БЖУ — вдруг стали «платформами»? Это не просто хайп. Платформенная инженерия — как кислород для цифрового бизнеса: незаметно, но критично. Но что это такое, и почему без нее теперь как без рук? Давайте разбираться без заумных терминов.

Если коротко, то платформенная инженерия - это когда решив, что у вас есть гениальная идея, которая нанесёт непоправимую пользу компании, вы занимаетесь только ею, а не погибаете на этапе логирования, мониторинга, авторизации пользователей и прочих функций, который часто ctrl+c ctrl+v из проекта куда у вас есть доступ.

Если чуть дольше, то...

Недавно один из пользователей попросил добавить эту мелкую фичу. Как обычно, дольше размышлять чем делать... Некоторые из посетивших мыслей решил записать в маленькую статью, в качестве пояснения/сопровождения к коммиту в гитхабе. Ну и без бага не обошлось - глупо, но поучительно :)

(не рассматривайте эту статью в качестве поучения "как надо писать" - код несколько архаичен и коряв, и реализация на KV таблице может выглядеть спорно)

Как-то мне выпало написать небольшой микросервис, код которого практически полностью состоял их одних реализаций паттернов "Банды четырех". В этой статье я хочу рассказать о том, как последовательное решение поставленной задачи приводило к использованию все новых паттернов, и как эти паттерны взаимодействовали между собой.

Будет много схем и кода, демонстрирующих практические примеры применения паттернов Композит, Билдер, Визитер, Цепочка обязанностей и Декоратор. Не смотря на то, что примеры кода написаны на PHP, статья может оказаться интересной и для разработчиков, использующих другие языки.

Сейчас среди Java/Kotlin команд распространено применение Чистой (ака Гексагональной, ака Луковой — Clean, Hexagonal, Onion) архитектуры для разработки бакэндов прикладных приложений (да и Android‑приложений тоже). Однако это семейство архитектур в контексте прикладной разработки зачастую не даёт никаких преимуществ, а только привносит лишние церемонии и тем самым замедляет её.

В этом посте я подробно разбираю, почему, на мой взгляд Чистая архитектура не является лучшим выбором по умолчанию для прикладных приложений, и кратко рассказываю об альтернативной архитектуре (спойлер: Промышленная функциональная архитектура), которую использую в качестве дефолтной последние 3 года и пока что доволен.

Но перед тем как перейти к Чистой архитектуре, сначала надо разобрать принцип инверсии зависимостей (Dependency Inversion Principle, DIP).

Привет! Хотелось бы поделиться с вами своей мудростью примером структуры, которая подойдёт практически для любых сервисов вне зависимости от того, гоняете ли вы JSON-ы в микросервисах или разрабатываете монолитное решение со сложной бизнес-логикой.

Проверяя код проекта TDengine с помощью PVS-Studio, можно встретить канонические ошибки и опечатки. Многих из них можно избежать, если изначально аккуратно оформлять код, делать логику простой и избегать макросов. Давайте посмотрим на эти ошибки и подумаем, как можно повести рефакторинг кода так, чтобы им просто не было там места.

Представьте: у вас есть монолит на PHP. Большой, сложный, местами запутанный – но такой родной. Он верой и правдой служит бизнесу много лет. А потом случается неизбежное – компания растет, нагрузки увеличиваются, и ваш надежный монолит начинает... задыхаться.

Я – Кирилл Кузин, go-разработчик платформенной команды Ви.Tech (IT-дочка ВсеИнструменты.ру). Последние три года мы переводим высоконагруженные части нашего кода с монолита на Go-сервисы. За это время успели перенести критически важные компоненты, увеличить производительность в десятки раз и найти свой путь между монолитом и микросервисами. О нем я сегодня и расскажу.

На относительно простом примере показываю как можно сделать программу «снова великой». Ключевые стадии рефакторинга, Java, эмулятор и Jenna Ortega в нейросетевом исполнении.

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

В системном дизайне понимание разницы между классами проектирования (design classes) и классами анализа (analysis classes) носит ключевой характер. Классы анализа подобны детективу — они исследуют и понимают проблему. Они сфокусированы на том, что система должна делать, без погружения в то, как именно это должно быть реализовано. Эти классы помогают разработчикам понять требования к программе и ее цели. В то время как классы проектирования подобно архитектору берут результаты изысканий классов анализа и создают план, как именно система будет работать.