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

Сразу после прочтения этого поста: 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