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

В середине 90‑х я получил первый домашний компьютер — IBM‑совместимую машинку на процессоре Intel 286. Установка Windows требовала кучу дискет, а жёсткий диск вмещал «весь» 20‑30 МБ. Информация тогда хранилась в бумажных книгах и в полках библиотек.

Сейчас, спустя почти три десятилетия, обучение программированию выглядит совершенно иначе. Ниже я расскажу, как менялись возможности обучения, и почему сейчас Large Language Models (LLM) могут стать вашим личным наставником.

Есть ощущение, что мы сейчас живём в странный период: LLM-агенты уже умеют “делать работу”, но ещё не умеют быть предсказуемыми.

На демке всё выглядит идеально:

• один агент пишет код,
• второй — тесты,
• третий — делает ревью,
• четвёртый — собирает артефакты и отчёт,
• пятый — «оператор», который всё это оркестрирует.

Первые пару запусков ты сидишь и думаешь: «Ну всё. Завтра индустрия будет другой». На третьем запуске агент уверенно сообщает: «Я исправил проблему», и одновременно:

Последние месяцы я вижу одну и ту же сцену.

Кто-то начинает активно применять нейросети в разработке — и первые недели ощущение кайфовое:
код появляется быстрее, задач закрывается больше, “как будто полетели”.

А потом начинаются знакомые фразы:

Последние месяцы я полностью пересобрал свой подход к разработке. Раньше я писал код сам. Теперь я стратегически управляю нейросетями.

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

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

View Transitions API: полное руководство по плавным переходам в браузере

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

Программист часто копирует и вставляет, переименовывает и рефакторит. Выделил (подсветил) мышкой переменную или функцию и вот бы сразу видеть их количество в статусной строке. Увы, стандартный поиск (Ctrl+F) требует лишние клики.

Мой небольшой Python-скрипт для Notepad++ по дабл-клику
отображает в Status-Bar количество вхождений,
частичных или полных, с учетом регистра и без.

Эта статья — не критика Agile или Kanban как подходов и не попытка доказать, что в IT «всё делают неправильно». Я делюсь наблюдениями из собственного опыта работы с качеством в промышленности, энергетике, а затем — в IT‑продуктах.

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

Если у вас уже выстроена работа и всё стабильно — это отлично. Если нет — возможно, некоторые наблюдения покажутся полезными.

У нас в компании был один проект, с которым я не справился.

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

Оказалось, что плохо вообще всё.

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

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

Короче, вот она — анти-статья, собранная из того проекта. А где мне не хватало примеров, я брал код из Django, потому что он вообще полностью собран на антипаттернах.

Разработка программного обеспечения не стоит на месте: меняется технологический стек, совершенствуются подходы к созданию ПО. Вместе с тем уточняются и требования к ПО и процессу разработки в целом. Все больше людей узнает о понятии SSDLC (Secure Software Development Life Cycle) или безопасный жизненный цикл разработки ПО. Как же построить такой цикл в команде? Как сформировать качественную стратегию построения безопасной разработки? Давайте разбираться!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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