null — это не «мелкий баг», а архитектурный долг, который до сих пор сидит в продуктах, SDK и логах.

null — это не «мелкий баг», а архитектурный долг, который до сих пор сидит в продуктах, SDK и логах.

История короткая: в 1965 году Чарльз Хоар добавил null в язык как удобный способ обозначить «нет значения». Тогда это казалось аккуратным решением. Проблема в том, что дальше идея разошлась по индустрии без ограничений: nullable-поля, пустые ссылки, неожиданные исключения, падения в проде.

Что в итоге:
- null превращает ошибку данных в ошибку выполнения
- ломает контракт между сервисами
- усложняет тесты и валидацию
- делает код дороже в сопровождении

Почему это до сих пор болит? Потому что null не виден на этапе чтения схемы. Он проявляется только в момент, когда система уже что-то делает. И тогда начинается классика: NPE, ретраи, откаты, ручной разбор инцидента.

Хорошая практика для PR/коммс-команд, которые работают с продуктом:
1. Где можно — не использовать nullable-значения
2. Явно описывать, что считается пустым состоянием
3. Проверять API-контракты до релиза
4. Логировать не «упало», а какое поле было пустым и где

Мораль простая: одна строка кода может стать отраслевым налогом на десятилетия.