Архив рубрики ‘архитектура по’

Как Claude убедил заказчиков, что я некомпетентен

Привет, Хабр. Меня удалили из рабочего чата после того, как заказчики поверили нейросети больше, чем живому специалисту, с которым работали полгода и у которого всё это время всё работало. Быть может, звучит это как обида фрилансера, которого кинули. Ну и да, меня кинули — не доплатили, опять (про «опять» далее). Статья про штуку, которую я […]

70% кода с AI — и ни на день быстрее

Вступление В какой-то момент это происходит почти в каждой компании. Собрание. Слайды. Уверенный голос. «Мы должны активнее использовать AI».«Он ускорит разработку в несколько раз».«Нам нужно повышать эффективность».«Возможно, нам и не понадобится столько людей». Формулировки могут быть мягкими. Могут быть вдохновляющими. Могут быть завёрнутыми в стратегию трансформации. Суть остаётся той же: технология должна кратно увеличить производительность.

Билеты, баги и БДСМ: хроники тревел-стартапа

Почему проекты превращаются в спагетти даже у хороших программистов

Когда программист впервые слышит слово «архитектура», он обычно представляет что-то скучное: диаграммы, стрелочки, коробочки, совещания на три часа и человека, который запрещает писать код. А потом проходит несколько лет. И внезапно оказывается, что проект, который «быстро накидали», начинает разваливаться от любого изменения. Добавили одну кнопку — сломался импорт. Поменяли отчёт — умерла авторизация. Обновили библиотеку […]

Ваша кодовая база умрёт через 7 лет. Считаем на пальцах

Откройте свой git log за последний месяц. Посчитайте коммиты, начинающиеся со слов fix, hotfix, temp, workaround или (классика жанра) – //TODO:переписать нормально.

Когда онбординг длится 2 месяца — День 1: Убрать хаос

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

Объединяем уровни абстракции: обобщаем артефакты анализа для общего видения концепта задачи

Добрый день, дорогие читатели! В практике системного анализа довольно часто можно встретить требования в формате пользовательских историй (User Stories, далее US). Пользовательские истории предоставляют стейкхолдеры или бизнес-аналитики как входные данные. Так или иначе, US становятся одним из ключевых артефактов требований для реализации фичей.

Почему наш язык — лучший язык для программирования (ответ на манифест из 70-х)

Недавно на Хабре вышла статья «Почему наш язык — худший язык для программирования». Автор справедливо отметил проблему двусмысленности естественного языка (ЕЯ) и предупредил, что программирование словами приведет к хаосу. Я начну с неожиданного: автор оригинальной статьи абсолютно прав. Он прав, если мы говорим о программировании заклинаниями

Как измерять переход к Self-Contained Systems: фитнес-функции для архитектуры на 1000+ приложений

TL;DR В Swissquote используют архитектурные фитнес-функции, чтобы автоматически измерять, где системы соответствуют принципам SCS, а где отклоняются. Проверки гоняются ежедневно по 1000+ приложениям и агрегируются на уровне команд/отделов/департаментов. Требования сведены к числовым оценкам 0–1, результаты видны и инженерам, и руководителям, с историей по дням. Для приоритизации ввели уровни бронза / серебро / золото как наборы […]

Проектирование в условиях нестабильности: от функционального хаоса к архитектурной устойчивости

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