Можно ли писать код без багов?

Сразу после прочтения этого поста: https://korshakov.com/posts/no-bugs захотелось написать свой пост на пост)
Потом появился неплохой комментарий https://t.me/rybakalexey/190 и кажется - что тут добавить?
Прошло время, и я понял, что именно)

Вкратце содержимое предыдущих серий:
1) писать без багов, ладно с минимальным количеством багов, можно
2) для этого нужно начать заставлять себя постоянно улучшать код до тех пор, пока это не станет привычкой
3) первое время это замедлит разработку, потом скорость вернется в норму

Ключевое слово - фокус на том, чтобы всегда делать код лучше. Под кодом я понимаю в т.ч. и архитектуру, тесты, ....

Я бы хотел добавить немного практики - на что можно обратить внимание.

0) нулевой пункт - потому что очевидный. Следование практиками чистого кода. Ключевой момент - понятные наименования и читаемость. Нет читаемости - нет понимания, как код работает, легче допустить ошибку при модификации.

0.5) еще один нулевой пункт - модульные тесты. Тесты - это основная страховка при рефакторинге и серьезных изменениях в архитектуре. Без тестов проект сразу становится legacy.

1) TDD. Какая связь с багами? Через тесты, конечно. Если тесты пишутся после кода - всегда есть риск, что из-за сдвинувшихся сроков на тебя надавят и заставят отдать фичу на тестирование как есть. А это баги и вообще говоря еще больший сдвиг сроков. Но объяснить это менеджеру сложно. Если же тесты пишутся до кода - гнать в ПРОМ фичу без части функционала никто не будет. Хотя может быть и стоило рассмотреть именно такой вариант)

2) Управление техдолгом. Он возникает, когда вот прямо сейчас сделать все красиво не получается - https://t.me/javaKotlinDevOps/312
Ключевая мысль - техдолг нужно оцифровывать. Как TODO, как таски, как TODO превращенные роботом в таски - не важно. Главное, что техдолг записан, после чего потерять его станет сложнее. Улучшится прозрачность, появится артефакт для обсуждения с командой и планирования исправления техдолга. Голова разработчика - хорошо, но нет) Опять же: есть бизнес, у него есть новые фичи, меняются люди - в итоге благие намерения ими и остались, техдолг забыт, архитектура и код медленно превращается в "большой ком грязи".

3) Интеграционные тесты разработки (не путать с тестами тестировщиков!). Суть простая - модульные тесты не дают ответа на вопрос: "Работает ли приложение в целом?" Потому что они модульные, они тестируют какой-то небольшой кусочек, а не "костюм в сборе". Поэтому хотя бы парочка таких тестов нужна, чтобы отловить потенциальные баги раньше. Не слишком много, иначе время отладки затянется.

4) Качественное ручное и автоматическое код-ревью. Некачественное - это замечания типа добавь комментарий к конструктору в SonarQube или скоростное код-ревью за 5 секунд от коллеги. Ни первая, ни вторая практика не найдут всех ошибок. Может даже и половины не найдут. Но какие-то найдут, и это в итоге сделает код лучше. Поэтому профиль SonarQube или другого анализатора нужно настраивать "под себя", все найденные им баги править. О ручном код-ревью договариваться с коллегами, PO или ИТ лидом чтобы на это выделялось время. Ну и соблюдать рекомендации по pull requests https://t.me/javaKotlinDevOps/148

5) внимание к вопросам сопровождения, понимание их болей. Идеально конечно было бы you build it - you run it, но не везде это возможно. Сопровождение - по крайней мере там, где я это видел - работа достаточно стрессовая. Поэтому система должна быть максимально простой в плане сопровождения. Это значит: инструкция по внедрению, понятные и актуальные наименования, необходимый минимум настроек, логи без мусора, метрики и трейсы, наличие рубильников ("feature toggle"), rate limiters, быстрое время старта пода. Иначе - баги и инциденты ПРОМа.

6) время на уборку мусора. GC тут не поможет, речь о мусоре в проекте. Это могут быть настройки https://t.me/javaKotlinDevOps/328, это может быть неиспользуемый функционал или просто лишние библиотеки. Про это часто, даже откровенно говоря почти всегда, забывают

Пока все, думаю еще со временем накину)

#no_bugs

Писать код без багов - продолжение

Важное дополнение по интеграционным тестам, спасибо Женя!
Интеграционный тест разработки - это с большой вероятностью аналог некого тест-кейса тестировщика. Поэтому если возникают вопросы: "Какие интеграционные тесты нужны?" - можно спросить у тестировщика. А в некоторых компаниях такая практика включена в релизный цикл - тестировщик контролирует набор интеграционных тестов разработки. Они могут при этом называться системными (СТ), но названия разных видов тестов - это отдельная больная тема)

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

8) НТ - нагрузочное тестирование. Если разработчик не интересуется этим вопросом, ведь есть специально обученные люди - команда НТ - то риски следующие. Во-первых НТ может показать, что архитектура системы неверная, и показать слишком поздно. Во-вторых, для НТ-шников ваш сервис - черный ящик. Не понимая внутренностей системы что они могут порекомендовать? Увеличить квоты по CPU и памяти в k8s. Индексы в БД добавить. Это рабочий вариант, но также эти и путь к неоптимальной системе. Результаты НТ нужно разбирать вместе. Причем все, а не только когда сервис не тянет нагрузку из бизнес-требований. А в идеале - проводить свои мини-НТ заранее с помощью того же JMeter.

Пока все)

P.S. Может показать, что я забыл самое главное - проектирование. Но про него хорошо написал автор исходного поста - https://korshakov.com/posts/no-bugs

#no_bugs

Традиционная рубрика - новости AI)

Github таки выкатил AI джуна https://github.blog/changelog/2025-05-19-github-copilot-coding-agent-in-public-preview
За 40 баксов в месяц можно просто назначить тикет на Copilot, после чего провести ревью полученного Pull Request. Выглядит экономия на ЗП джуна в 20+ раз. И даже работает https://t.me/yegor256news/1648
Всем джунам приготовится)))

Я писал в одном из предыдущих постов - режим размышления и веб-поиск становится мейнстримом. Проверил - да, в том или ином виде они появились у всех AI ассистентов, которые попали в мое первое сравнение https://gitverse.ru/javadev/ai-tools-comparision/content/master/README.md. Разве что у GigaChat не нашел поиска, а у GigaCode - ни поиска, ни режима размышлений( Из особенностей - у Gemini и Microsoft Copilot поиск доступен не в AI ассистенте, а собственно в поиске - Google и Bing.

Из интересного - Gemini\Google стал наиболее сильно банить пользователей из России, смотрит на данные аккаунта Google, одного VPN не хватает. Даже переключение на США не помогает. Ну и ладно, не очень то и хотелось)

Новый тренд - специализированные креативные режимы. Подготовить презентацию, нарисовать картинку....

И еще один интересный момент. В свое время Роберт Мартин поднял очень важный вопрос - читаемости и сопровождаемости кода - в своей книге Чистый код. Да, я видел критику конкретных примеров кода из книги, но идеи оттуда IMHO всегда будут актуальны. Так вот - если присмотреться к генерируемому AI коду - многие принципы он выполняет. Названия понятные, Single Responsibility старается соблюдать. Тренировали модели я подозреваю на открытых проектах GitHub. И видимо фильтровали проекты, т.к. на GitHub традиционно выкладываются проекты всех входящих в ИТ)

#ai #ai_digest

(Не) храните большие бинарные файлы в git

Есть такое общеизвестное правило - никогда не храните большие бинарные файлы в git. Почему?
Причин несколько:

1) большие файлы как правило бинарные, а при работе с бинарными файлами мы теряем значительную часто возможностей git - просмотр diff-ов, да процесс code review в целом

2) git начинает тормозить при разрастании репозитория, а учитывая, что хранится вся история изменений - с большими файлами выйти на этот предел (десятки и сотни Gb, вот тут есть пример от Microsoft https://t.me/javaKotlinDevOps/272) уже значительно проще.

И если с первой причиной что-то сделать сложно, то для второй решение есть. И называется оно Git LFS https://git-lfs.com/

Для начала небольшая справка. При git clone скачивается следующая информация:

1) метаданные
а) настройки git
б) список существующих веток и тэгов

2) история коммитов по всем веткам (.git)

3) актуальные версии файлов в текущей ветке

Суть решения:

1) большие файлы хранятся отдельно от текстовых, с текстовыми файлами хранятся только ссылки на них. Переиспользуем возможности файловой системы Linux

2) при клонировании репозитория большие файлы копируются только для текущей ветки, что ускоряет загрузку

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

Еще важный момент - для того, что Git LFS заработал, нужно:
1) проинсталлировать его на сервере
2) включить на репозитории
3) добавить в репозиторий по маске список файлов, которые надо считать большими.
4) существующие файлы в LFS не попадают, их нужно добавить заново или мигрировать

В целом LFS работает прозрачно, но команды git lfs clone и git lfs pull оптимизированы для работы с LFS и загружают данные быстрее.

Проект open source и поддерживаемый, был создан усилиями заинтересованных лиц - GitHub, Bitbucket.

#git

AI и leetcode

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

Что меняется с появлением AI?

1) видится, что пользоваться AI на таких собесах не разрешат, т.к. современные агенты не просто могут решить задачку, но и даже написать тесты, проверяющие ее решение. Т.е. с AI никакой проверки на собесе не будет

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

3) у противников данной практики основной аргумент усиливается. Если раньше можно было сказать - с вероятностью 90% мне это в реальной работе не понадобится, то сейчас цифра примерно равна 99%)

4) но возникает интересный момент. Вот решил кандидат за 1.5 часа 3 задачки. Даже 10 минут в резерве осталось. Появляется чувство: "А я хорош!)". Возникает мысль - интересно, а AI агент эти задачки решит. И агент решает их за 10 минут... И какие-то самые некрасивые мысли лезут ко мне в голову...

#ai #interview #algorithms