Работали ли вы по Scrum (спринтами) или по Kanban?

Ну, вот смотри, бывает же такая хуйня — пишешь код, вроде всё правильно, а оно не работает. И ты сидишь, ебёшь мозг, час, два, а потом находишь ошибку, и она такая тупая, что самому стыдно становится. Прямо как в этой истории.

Вот, например, классика жанра — Uncaught TypeError: Cannot read properties of undefined. Это пиздец какой-то универсальный пиздюк от JavaScript. Ситуация: ты обращаешься к свойству объекта, который, оказывается, нихуя не существует. В рот меня чих-пых!

Представь, у тебя есть объект user, и ты хочешь получить его имя.

const user = null;
console.log(user.name); // Uncaught TypeError: Cannot read properties of null (reading 'name')

Вот и всё. Ты ожидаешь объект, а тебе прилетает null или undefined. И твой код, такой красивый и умный, падает как подкошенный. А причина-то — в каком-нибудь другом месте, где этот user не проинициализировали или асинхронная хуйня не успела его подгрузить.

Или вот ещё прикол — опечатка в названии свойства. Объект есть, а свойства с таким именем — нет.

const person = { firstName: 'Вася' };
console.log(person.firstname); // undefined
// А потом где-то ниже: undefined.toUpperCase() — и опять пиздец!

Чувак, это же элементарно! Но нет, глаз замыливается, ищешь сложную причину, а она, блядь, в одной букве. Чёрта в душу!

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

console.log(user?.name); // undefined, но без ошибки

И используй строгие проверки. Не if (user), а if (user && user.name), а лучше if (user?.name). Потому что иначе можно нарваться на хуй с горы, когда user — это пустая строка или ноль, который тоже в if даст false, но потом вызовет тот же пиздец.

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