Как стать автором
Поиск
Написать публикацию
Обновить
102.17

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

Реорганизация кода

Сначала показывать
Порог рейтинга
Уровень сложности

Правильный старт: как заложить фундамент проекта

Время на прочтение2 мин
Количество просмотров1.9K

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

Читать далее

Новости

От джуна до тимлида и обратно: почему я выбрал код

Уровень сложностиПростой
Время на прочтение3 мин
Количество просмотров24K

За 20+ лет в разработке я прошёл путь от студента с книгой по C++ до техлида, но понял: управление людьми приносит меньше удовольствия, чем написание кода. Карьерный рост — это не всегда движение вверх по иерархии, иногда стоит выбрать то, что действительно нравится, а в IT можно хорошо зарабатывать просто программируя.

Читать далее

Универсальная С++ фабрика объектов: для Qt и не только

Уровень сложностиСложный
Время на прочтение47 мин
Количество просмотров5K

Привет, Хабр! Меня зовут Михаил Полукаров, я занимаюсь разработкой Desktop-версии корпоративного супераппа для совместной работы VK Teams.

Если вы тоже работали с большими проектами, где активно применяются объектно-ориентированные паттерны проектирования, то наверняка сталкивались с паттернами проектирования Factory Method или AbstractFactory. В процессе разработки я неоднократно ловил себя на мысли, что часто пишу однотипный код таких фабрик, и задумался о том, как можно было бы избежать таких самоповторений. 

В этой статье я покажу, как сделать универсальную фабрику объектов, покрывающую большую часть потребностей, следующую принципам DRY (Don’t Repeat Yourself), а также как можно использовать некоторые «фишки» новых стандартов С++. 

Читать далее

Когда State уже не спасает: путь к Statechart

Уровень сложностиСредний
Время на прочтение13 мин
Количество просмотров1.7K

В мире разработки программного обеспечения управление состоянием объекта - одна из фундаментальных задач. Когда поведение объекта должно меняться в зависимости от его внутреннего состояния, разработчики часто обращаются к паттерну State. Однако здесь и возникает путаница: его нередко отождествляют с более общей концепцией — State Machine (Конечный автомат), а то и вовсе не видят разницы.

Погрузимся в мир управления состояниями — от простого к сложному!

Читать далее

Про архитектуру приложений для тех, кому мало Чистой архитектуры

Уровень сложностиСложный
Время на прочтение19 мин
Количество просмотров13K

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

Лет пять назад я обнаружил для себя Чистую архитектуру Дяди Боба и на некоторое время успокоился, пока поток новых источников постепенно не начал менять мое отношение и к этой книге. Но, если вы решили для себя, что Чистая архитектура — это ваш окончательный выбор, то я точно не буду вас отговаривать, потому что, на мой взгляд, это однозначно лучше, чем, наверное, 90% того, что вам встретится на рынке.

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

Раньше мы в 3 частях [1, 2, 3] пробежались по основным идеям архитектуры систем. Поэтому, если вы ищете информацию по System Design, микросервисам и топологии команд, то вам туда. Эта же статья про архитектуру внутри кодовой базы: она посвящена концепциям программирования, влияющим на структуру приложения, поэтому описывает не только архитектурные подходы, но и иные идеи, оставляющие на дизайне свой отпечаток.

Читать далее

Проектирование Информационных систем. Часть 11. Управление изменениями требований

Уровень сложностиСредний
Время на прочтение13 мин
Количество просмотров2K

Для эффективной организации производства Информационных систем (ИС) требования должны стать каркасом, связывающим все этапы жизненного цикла ИТ‑продукта и передаваться от одной фазы к следующей, обеспечивая непрерывность и согласованность всего проекта. Так при реализации разработчики наделяют продукт функциональностью в соответствии с утвержденными требованиями. А тестировщики на основе спецификации требований разрабатывают план тестирования: к каждому функциональному требованию привязывают сценарии, тест‑кейсы и подтверждают, что готовое решение удовлетворяет требованиям, и так далее по цепочке.

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

Процедура передачи может регулироваться, например, управленческими правилами делегирования, а именно:

Читать далее

Минификация кода для повышения эффективности LLM: влияние на лингвистику, генерацию и анализ программ

Уровень сложностиПростой
Время на прочтение8 мин
Количество просмотров749

Большие языковые модели (LLM) становятся неотъемлемой частью инструментов генерации, анализа и автоматизации программирования. Их возможности позволяют автоматизировать разработку, искать ошибки, генерировать тесты, осуществлять перевод между языками программирования. Однако одно из ключевых ограничений — контекстное окно, то есть максимально возможная длина входных данных. С ростом объема современных программ эффективность работы LLM с длинным кодом становится всё более актуальной задачей, особенно учитывая вычислительные и финансовые издержки обработки длинных последовательностей.

Минификация кода — процесс сокращения программного текста до минимального, необходимого для сохранения семантики. Для современных LLM это уже не только техническая задача (как раньше для web‑ресурсов), а способ оптимизации использования ресурсов, экономия токенов, увеличение объема анализируемого кода, ускорение анализа и генерации. В данной статье рассматривается современное состояние исследований по минификации в контексте LLM, формулируются гипотезы о её влиянии, а также обсуждаются перспективы для программной лингвистики.

Читать далее

Практические вопросы архитектуры ПО, из чего строить будем?

Уровень сложностиПростой
Время на прочтение13 мин
Количество просмотров2.9K

Вы знаете из чего и как строятся программы? Странно что ни в одной из статей о программной архитектуре вы не найдете упоминаний о том из чего эти программы строятся.

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

Читать далее

Невидимые загрузки или о пользе свободно стоящих функций

Время на прочтение5 мин
Количество просмотров1.3K

Довольно долго я тягался с по-настоящему глупой проблемой на C++: мне не нравятся функции-члены, но я вынужден их писать, чтобы программисту было хоть немного удобнее работать. Функции-члены обеспечивают две вещи: разграничение областей видимости и обнаружимость. Разграничение областей видимости — менее актуальная из этих задач, поскольку в моём коде на C++ я и так не использую модификаторы private/public. Обнаружимость — большая проблема: я могу написать x.F, а IDE предложит x.Func(). Отлично! «Но правильные программисты пользуются только vim и скромными IDE». Что ж, привет вам, воображаемые мифические обычные программеры. Здесь вам ничего не угрожает, но, пожалуйста, уходя — надевайте сразу два беджика:  «vim отстой» и «Я ненавижу emacs». Отлично помогает завязать разговор с «настоящими» программистами.

Читать далее

Пишем агента на Kotlin: KOSMOS

Уровень сложностиСредний
Время на прочтение25 мин
Количество просмотров2.7K

Интернет завален реализациями на Питоне, но иногда удобнее разбираться с технологиями на своём основном языке. Для мен;я это Kotlin.

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

Статья обещает соблюдать два принципа, упрощающих восприятие:

‣ Движение от частного к общему, потому что легче воспринимать примеры, чем абстракцию.
‣ Быстрая обратная связь, как с REPL.

Агента реализуем так, чтобы легко было заменить лежащую в основе LLM. Посмотрим, как отличается работа при использовании REST API в сравнении с SDK, пощупаем Гигачат и Anthropic.

Ах да, 🪐 KOSMOS — акроним. Kotlin Open Synthetic Mind Orbiting System.

Читать далее

AI-бот для QA-инженеров: как я сделал Telegram-ассистента для ежедневной прокачки

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров5.1K

Привет! Меня зовут Евгений. Я — Full-Stack QA Engineer в Devscribed и сегодня хочу поделиться своим экспериментом — QA Mentor Bot. Это Telegram‑бот, который отправляет в телеграмм группу случайные вопросы по тестированию и сразу же генерирует на них развёрнутые ответы с помощью AI. В этой статье я расскажу, как устроен проект и с какими «подводными камнями» столкнулся в процессе разработки.

Читать далее

Паттерн Спецификация: реальный опыт применения

Уровень сложностиСредний
Время на прочтение12 мин
Количество просмотров5K

Четыре года назад на собеседовании я услышал от интервьюера о том, как замечательно паттерн Спецификация помогает справиться с проблемой разрастания репозитория. Я думаю, многие с этим сталкивались, когда количество методов типа getByThisAndThat(…) улетает за десяток, а то и за несколько десятков, и репозиторием становится пользоваться неудобно.

Вдохновившись таким позитивным отзывом, я изучил первоисточник и начал экспериментировать с использованием спецификации как со средством упрощения репозитория.

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

Читать далее

Обработка асинхронных операций с Flowable — Часть 4: Эволюция Async Executor

Уровень сложностиСредний
Время на прочтение12 мин
Количество просмотров202

Добро пожаловать в четвёртую и заключительную часть серии о новом Flowable Async Executor. До этого момента путь был довольно насыщенным:

Однако остаётся один важный вопрос: как мы пришли к текущей реализации? Что подтолкнуло нас к этим изменениям и почему? Как мы нашли узкие места и использовали эти данные для создания лучшего подхода? И, учитывая, что первая версия появилась более десяти лет назад, как Async Executor эволюционировал, сохраняя обратную совместимость?

Именно этому посвящена эта часть. Мы воспользуемся возможностью оглянуться назад и вспомнить различные реализации, которые появлялись за это время. Мы выделили четыре поколения Async Executor и кратко рассмотрим каждое из них. Поскольку Flowable является форком Activiti, история начинается с первой версии Activiti (5.0.0).

Читать далее

Ближайшие события

Комментарии vs. самодокументируемый код: что выбрать?

Уровень сложностиПростой
Время на прочтение3 мин
Количество просмотров3.9K

Если вы когда-либо сталкивались с чужим кодом (или даже со своим, написанным полгода назад), то знаете, как сложно бывает понять, что именно делает тот или иной фрагмент. В такие моменты особенно остро ощущается потребность в пояснениях. Но какие есть способы, помогающие сделать код понятным?

Разберемся вместе.

Читать далее

Сказание о стратегических паттернах DDD

Уровень сложностиСложный
Время на прочтение20 мин
Количество просмотров9.7K

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

В этой статье не будет примеров кода и конкретных архитектурных приёмов. Но если, читая книги и статьи по Domain Driven Design, вы недоумеваете «зачем это всё вообще», возможно, у меня есть для вас ответ. Правда, боюсь, что он вам не особо понравится.

Читать далее

Архитектурные принципы

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров9.9K

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

Итак, без долгих предисловий:

Читать далее

Как я пишу код быстрее

Уровень сложностиПростой
Время на прочтение10 мин
Количество просмотров12K

Вечный вопрос разработчика: как писать код быстрее, не превращая его в поддерживаемый кошмар? Дедлайны давят, требования растут, а перфекционизм подсказывает: «Ещё рефакторинг!»

Автор годами искал баланс между скоростью и качеством в разработке ПО и вывел практические правила. Делимся опытом: черновики вместо идеала, борьба с отвлечениями, маленькие патчи и другие навыки, реально ускоряющие работу.

Готовы ускориться?

Разработка требований к ПО с помощью Markdown, Git и Obsidian

Уровень сложностиСредний
Время на прочтение9 мин
Количество просмотров9.3K

Пошаговое руководство по использованию Git, Obsidian, Markdown и любимого IDE для разработки требований и трассируемого в них программного кода.

Читать далее

BSSN: Лучшая простая система на сегодня

Уровень сложностиПростой
Время на прочтение25 мин
Количество просмотров1.9K

Автор оригинальной статьи: Daniel Terhorst-North 

Вы можете накормить волков и сохранить овец, если сделаете все правильно.

Многие организации живут в постоянном напряжении между двумя путями разработки: быстрым, но «грязным», и надежным, но медленным. Одни торопятся, оправдывая технический долг «прагматизмом», другие осторожничают, опасаясь ошибок и занимаясь оверинженерингом. Я предлагаю третий путь — «лучшую простую систему на сегодня» (Best Simple System for Now, BSSN), которая сочетает преимущества обоих подходов и не заставляет идти на компромиссы.

Читать далее

Ликбез по UseCase’ам Android: от базовых реализаций до мультипровайдерных и многомодульных систем — Часть 2

Уровень сложностиПростой
Время на прочтение15 мин
Количество просмотров1.4K

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

Читать далее
1
23 ...

Вклад авторов