Качество кода *

Хаотичные события в Android (навигация, тосты, запросы) часто превращаются в источник багов и нечитаемого кода. В этой статье вы узнаете, как использовать sealed-интерфейсы Kotlin для создания полной, типобезопасной модели экрана, где состояния и события управляются отдельно и предсказуемо. Вы научитесь превращать одноразовые побочные эффекты в строго контролируемый поток команд, получите compile-time гарантии, избавитесь от багов с поворотом экрана и сможете легко тестировать любые события UI. Рассмотренный подход не только защищает от ошибок, но и кардинально упрощает масштабирование логики. Вы сможете добавлять новые события без риска сломать существующую функциональность, а ваш UI-слой станет чистым и декларативным. При этом всё, что нужно для внедрения - это понимание базовых принципов Flow и ViewModel.

Здравствуйте, коллеги программисты!

Большинство фейлов в CI — это мелочи: забытый console.log, форматирование, линт, сломанный импорт, файл без теста. Такие ошибки не должны доезжать до сборки или код-ревью.

Git-хуки позволяют запускать проверки прямо во время git commit и блокировать коммит, если были обнаружены нарушения.

В прошлой статье я рассказывал про скрипты, которые я использую для проверки качества кода в PHP/Laravel.

В этой статье я хочу рассказать о скриптах для JavaScript/TypeScript и Python — линтинг, форматирование, тесты, статический анализ и проверка наличия тестов.

Все скрипты, описанные в статье, находятся здесь.

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

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

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

Моя главная претензия к современному «реактивному» сообществу проста: вы потеряли фундамент. Вы строите небоскребы на болоте, игнорируя три фундаментальных правила игры, которые заложили авторы библиотеки.

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

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

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

По данным GitHub, количество открытых библиотек растёт экспоненциально. Только в экосистеме npm (JavaScript) насчитывается более 2 миллионов пакетов. При этом:

Наконец таки статья о том как я облажался. Точнее — как облажалась команда, но ответственность все равно моя. Это разбор конкретной ошибки, которая стоила реальных денег.

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

Но это не проблема ИИ. Это проблема подхода.

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

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

Причина такого поведения оказалась в самом фундаменте: автотесты опирались на статичные, «зашитые» данные, созданные еще при первом покрытии кода. Они были разработаны более трех лет назад и для скорости были объявлены в виде констант непосредственно перед кодом теста.

Рекурсия — прекрасный инструмент математического анализа. В математике это реально полезный и фундаментальный инструмент, поэтому математики привыкают мыслить рекурсиями и активно агитируют за перенос этой логики в программирование. Благо в программировании функции технически могут вызывать самих себя. Из‑за этого возникли даже так называемые функциональные языки программирования, основанные на идее отказа от циклов в пользу «универсальной» рекурсии.

Однако, следует понимать что рекурсия в математике и рекурсия в программировании далеко не одно и тоже. Как отметил Ален И. Голуб в книге «Веревка достаточной длины, чтобы… выстрелить себе в ногу» (п. 6. Если вы не можете сказать это по‑английски, то вы не сможете выполнить это и на Си/Си++) — математическое мышление может помешать писать хорошие программы. И как раз рекурсия наглядно демонстрирует эту мысль.

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

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

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

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

Теперь легко и просто можно попробовать поиграться в упаковку скиллов - до всяких платных Claude Code и Clawdbot/Moltbot. Напомню, что это способ превращать удачные сессии с агентом в переиспользуемые сценарии /воркфлоу для агента: один раз настроили, дальше запускаете по команде и получаете результат в том же стиле.

В Manus это можно попробовать и бесплатно. К тому же, вы можете даже скачать Skill, который вы сделали совместно с Manus, тоже совершенно бесплатно.

Я проверила это на простом и полезном кейсе: агрегатор свежих AI-новостей с Reddit, который делает выжимки под Telegram. Ниже по шагам и со скринами.

Хороший ли я программист? Если коротко — я не знаю, что это значит.

Вот я программирую уже 52 года, с 1973 года, спасибо урокам в государственной средней школе — тогда это было редкостью и не все школы давали подобную возможность. Я работал в 15 разных компаниях в самых разных отраслях. Болше скажу, я основал две небольшие софтверные компании — одну в 1985 году и вторую в 1987-м, и руководил ими до 1994 года. А потом я вышел на пенсию в 2021-м году.

Так что же, я хороший программист потому, что я в целом 52 года в отрасли и всё это время программирую?

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

Долговечность — это преимущество лишь в том смысле, что ты всё это время сумел оставаться ценным и востребованным, но это не обязательно значит, что ты хорош.

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

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

Нейросети обещали магию: закидываешь код, получаешь оценку. На практике магия плохо масштабируется — разные результаты при каждом запуске, невозможность объяснить оценку, растущие счета за API. Тогда я сделал шаг назад и спросил: а что именно я пытаюсь автоматизировать? Оказалось, всё можно сделать детерминированно. Один скрипт, нулевые зависимости, одинаковый результат при каждом запуске. Завершающая часть серии про методологию EVA — от философии до готового инструмента.

Делимся практическим кейсом рефракторинга автотестов учетной системы: от линейных скриптов к архитектурному подходу, который ускорил написание тестов в три раза.

Технический долг в автотестах — это катастрофа, которая нарастает незаметно. Сначала «простые и быстрые» линейные скрипты кажутся хорошим решением, но с ростом продукта они превращаются в «спагетти-код», где любое изменение в интерфейсе вызывает часовую рутину правок. Мы прошли этот путь в проекте по разработке учетной системы и нашли выход через внедрение архитектурного паттерна Page Object Model (POM).

Состояние «до» с линейными автотестами

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

Сейчас все обсуждают Claude Code, Antigravity, Codex, спорят, коллекционируют “скиллы” для агентов. Но на практике у большинства всё ломается на первом шаге: люди пишут “сделай мне приложение” — и получают либо кашу, либо минус лимиты.

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

спецификация → план → маленькие итерации → тесты/ревью → фиксация изменений (git)

Ниже - тот самый “скелет”, который можно повторить почти для любого проекта.

Оптимизация кода. Что быстрее: циклы vs стрелочные функции. Простая задача с собеседования. Разбор простых итераций с примерами кода

Когда я был разработчиком я задавался вопросами: как разделить код на классы? какие модули выделить?

Когда я стал архитектором я задавался вопросами: зачем же мы наплодили 200 микросервисов? стоит ли выделять новый или пора объединять?

Когда я стал руководителем я задавался вопросами: как разделить людей на команды разработки? стоит ли создавать новый отдел или расширить ответственность старого?

И всё это хотелось сделать оптимальным эффективным образом.

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