12 шагов к лучшему коду В 2000 году Джоэл Спольски написал чеклист — The Joel Test: 12 простых вопросов про вашу разработку. 1, Используете ли вы VCS? 2. Можете ли вы собрать проект одной (консольной) командой? 3. Есть ли у вас ежедневные билды? 4. Есть ли у вас бэклог багов? 5. Фиксите ли вы баги до того, как писать новый код? 6. Есть ли у вас план релизов? 7. Есть ли у вас спеки? 8. Есть ли у программистов возможность работать в тишине? 9. Используете ли вы лучшие инструменты, которые можно купить за деньги? 10. Есть ли у вас тестировщики? 11. Пишут ли кандидаты код на интервью? 12. Делаете ли вы «коридорные» юзабилити-тесты? Джоэл утверждал: если у вас 10 «да» или меньше то у вас проблемы (а если сильно меньше — то проблемы системные). Прошло 26 лет, и формулировки большинства пунктов устарели. Но сам подход — смотреть на разработку под разными углами, чтобы понять, почему и что «не летит» (и почему вы внезапно не можете нанимать сильных), — до сих пор актуален. Например: — «Ежедневные билды» сегодня — это не «ночью собираем артефакт», а нормальный CI/CD pipeline: тесты, статический анализ, сборка, деплой (хотя бы в staging), дэши и быстрый фидбек когда что-то идёт не так. — «Лучшие инструменты за деньги» сегодня — это не «купите IDE и Claude», а DX в широком смысле: — понятный и измеряемый lead time, — низкая когнитивная нагрузка (я писал про это тут) — разные окружения, A/B тесты, нормальные логи/трейсы, — и главное — чтобы команда не страдала от инструментов (страдать должны только от сложных задач, но это уже другая история). Если бы я писал Joel Test сегодня, я бы, наверное, добавил ещё несколько вопросов: — Есть ли автоматические тесты? — Есть ли code review как привычка? — Можно ли катить маленькими порциями (feature flags, canary)? — Есть ли observability и инцидентный процесс? Но глобально Joel Test всё ещё отличный «детектор дыма». Берёте список, прикладываете к команде — и быстро становится видно, где болит и почему. А что бы вы добавили в Joel Test 2026?