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

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

Итак.

Правда №1: я не знаю объективного способа подтвердить, что с проектированием продукты делаются быстрее и дешевле, чем без него.

То есть, для меня это очевидно. Это логично и рационально. Но не проверить.

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

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

Правда №2: никто не читает…

Одним из основных признаков системы, отличающим ее от #НЕСистемы, является подчиненность всей структуры некоторым целям. Проектная работа команды представляет собой тоже некую систему и, следовательно, должна «идти на поводу» у какой-то цели. Потому установив коммуникации между участниками проекта, начнем вместе с ними определять цели, которые каждое из заинтересованных лиц хочет достичь в результате создания нового продукта.

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

Поскольку мы постоянно оперируем очень сложными конструкциями и понятиями для эффективного управления ими, на протяжении всего курса мы будем использовать прием «Классифицирование» объектов анализа.

А вы никогда не задумывались, почему, с одной стороны, у нас появляются всё более крутые и мощные инструменты для разработки? На бэкенде мы можем делать микросервисы, писать офигительные SPA-приложения — но при этом будто бы сама программа становится всё хуже и хуже.

Каждый раз происходит одна и та же история: мы хотим сделать как лучше, но код в итоге всё равно превращается во что-то странное и не поддерживаемое.

Откуда берётся эта эрозия программного обеспечения? Почему так выходит, что новые технологии не только не помогают, но иногда даже мешают нам писать качественные программы? Почему, когда мы стараемся делать хорошо — получается плохо?
И главное — что с этим делать?

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

Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language — унифицированный язык моделирования).

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

-------------

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

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

Привет! Меня зовут Илья, последние 7 лет я занимаюсь фронтендом и наконец решил отметиться на Хабре. Стартую с темы, которая, как кажется, уже успела приесться, но всё ещё вызывает жаркие споры — код ревью (CR). Не смотря на сотни статей и мануалов, каждая команда подходит к этому процессу по‑своему. Хочется зафиксировать и осмыслить собственный опыт, показать, как мы подходили к настройке процесса в реальном проекте, и почему, на мой взгляд, код‑ревью не может быть универсальным, а должен опираться на контекст команды.

В этой статье не будет технических деталей вроде рекомендаций по максимальному количеству строчек в diff‑е или формату названий коммитов. Я хочу подняться на уровень выше и поговорить о целях, ключевых факторах и реальных компромиссах которые встречаются в CR.

Разработка проектного решения и документирование активностей по его воплощению на производстве больших ИТ-продуктов, процесс длительный, поэтапный, к тому же очень кропотливый и требующий слаженной работы разношерстного коллектива. Поэтому с самого начала необходимо продумать и подготовить ландшафт (среду обитания), в которой это процесс будет проистекать. Из моего опыта, если команда обеспечена комфортной средой для работы с артефактами проекта, а также для коммуникации участников между собой, то она уже на 50% обеспечила успешное развитие проекта.

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

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

Привет, Хабр! Меня зовут Евгений Кермас, я главный эксперт по технологиям в Управлении развития технологий модельного риска в Сбере.

В этой статье я попробую ответить на вопрос: «Что делать, если вы, как архитектор, пришли на существующий проблемный проект в качестве кризисного-менеджера?» Расскажу о нескольких подходах и дам советы, которые могут помочь в принятии решений в создании архитектуры и планировании проекта. Для этого разберём один пример с максимальным количеством проблем. На входе у нас есть монолит с запутанным кодом, на legacy-инфраструктуре, с нецелевым техстеком и большим грузом проблем, как технологических, так и организационных.

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

Чаще всего процесс формализации требований к целевой системе включает 3 этапа:

Большой проект. Сложная система. Куча требований. Первое, что приходит в голову любому инженеру: «Надо декомпозировать!» Разложим по модулям, разделим на команды, каждый займется своим куском. Большую сложную задачу превратим в набор простых понятных подзадач. Так учат делать везде. Так делают все. Это основа основ. Но никто не говорит о том, что происходит дальше. Никто не предупреждает о скрытых ловушках, которые ждут на этом пути. А их там... много.

При подготовке специалиста в области проектирования Информационных систем, важно учитывать конъектуру применения навыков в дальнейшем. Это может быть либо роль «Проектировщик» в каком‑то из проектов, либо постоянная профессия «Проектировщик ИТ‑продуктов».

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

Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language — унифицированный язык моделирования).

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

Это третий принцип. Весь список здесь.

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

Я исхожу из того, что код — это продукт, и первый пользователь — это коллега рядом. Он первым будет его смотреть, комментировать, рефакторить. Структура папок и кода — это дизайн продукта. Хороший дизайн соответствует принципу наименьшего удивления. Я делю код по смыслу согласно «решётке», поэтому организую структуру папок 2-я способами в зависимости от проекта:

— Layer Folder Structure (LFS)
— Scope Folder Structure (SFS)

Рост больших языковых моделей (LLM) и генеративного ИИ в корне меняет способ создания программного обеспечения. Современные разработчики все чаще полагаются на помощников ИИ (например, ChatGPT, GitHub Copilot) для написания кода, документирования программ и создания тестов. Рутинные задачи, которые когда-то выполнялись вручную — создание шаблонного кода, документирование API или рефакторинг — теперь можно частично передать на аутсорсинг ИИ под руководством человека. Эта тенденция побудила преподавателей заметить, что существующие методы оценки (например, домашние задания по кодированию) становятся неэффективными в эпоху помощников ИИ. Поэтому университетам по всему миру необходимо пересмотреть учебные программы: сохранить строгие основы и при этом научить студентов работать с инструментами ИИ.

В формирующейся парадигме «Водопад 2.0» разработка программного обеспечения становится более структурированной и фазово-управляемой. Каждая фаза стабильна и четко определена — почти как производственная линия или сборочная линия — но общий процесс остается итеративным. Большие языковые модели (LLM) теперь выступают в качестве автоматизированных «членов команды» в этом процессе, помогая экспертам в предметной области на каждом этапе. В результате традиционные артефакты — записи архитектурных решений (ADR), руководства по коду/стилю, документы для новых сотрудников, планы тестирования, конфигурации CI/CD, спецификации API, контрольные списки безопасности и т. д. — должны эволюционировать. В этом рабочем процессе, дополненном ИИ, эти документы становятся как входными данными, так и выходными данными ИИ, помогая направлять генерацию и сохранение знаний. Лучшая практика — хранить их как контролируемые версии, читаемые человеком файлы (например, Markdown в основном репозитории), позволяя ИИ помогать создавать и поддерживать их контент.

Появление мощных LLM превращает разработку программного обеспечения в более структурированный конвейерный или водопадный процесс. Вместо того, чтобы многие разработчики итерировали короткими спринтами, конвейер с поддержкой LLM может разбить работу на стабильные фазы (требования, проектирование, реализация, тестирование), которые идут последовательно. Как отмечает один эксперт, «кодирование перешло от творческого поиска к модели производственной линии», и ИИ помогает сделать каждую фазу более предсказуемой. В этой парадигме «Waterfall 2.0» эксперты в предметной области (например, менеджеры по продуктам, дизайнеры) напрямую подключаются к потоку разработки с помощью подсказок ИИ, и отдельные шаги фиксируются, но все еще адаптируются с течением времени. Результатом является в основном линейный сквозной процесс — анализ, генерация историй, кодирование, QA — который по-прежнему включает циклы обратной связи по мере необходимости.

Например, конвейер Waterfall 2.0 может начинаться с глубоких требований и исследований, а затем передаваться LLM, который генерирует пользовательские истории и спецификации тестов. Затем система будет проходить циклы ATDD (приёмочные тесты)/BDD(поведенческие тесты)/TDD (используя синтетические данные обучения), использовать ИИ для написания основной части кода и, наконец, запускать автоматизированные тесты и шаги по исправлению. На практике ИИ может сканировать заметки со встреч для составления пользовательских историй и даже создавать фрагменты кода из простых подсказок. Хотя на бумаге это выглядит линейно, общая гибкость сохраняется: как замечает Аджит Джаокар, у нас будут «теперь фазы, которые будут более стабильными», даже если команды будут переходить между ними.

Рост числа продвинутых LLM (таких как ChatGPT, Claude, Gemini) меняет разработку программного обеспечения. Сегодня один разработчик, вооруженный ИИ, может придумать, закодировать и запустить полнофункциональные приложения или MVP за долю традиционного времени.

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

Представьте, что у вас есть некая система, которая работает определённым образом. У неё есть свой API, свои архитектурные принципы, рекомендуемые подходы к разработке и т.п. С другой стороны, у вас у самого есть видение своего будущего проекта, его архитектуры и того, как бы вы хотели управлять функционалом, предоставляемым «некой системой». Видение есть, а вот уверенности, что так можно – нету. Вот, делюсь своим подходом, как я поступаю в таких ситуациях.

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

В этой статье мы разберем, как объединить мощь C# для бэкенда и элегантность WPF для фронтенда, чтобы создать инструмент, который не только собирает данные, но и превращает их в ценную информацию.

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