Обычное событие для разработчика 👨💻
Представьте, что вы разрабатываете функцию, и вы находитесь прямо в той точке, где вы хотите поместить код в свой репозиторий кода, а затем в рабочую среду. Падение микрофона? Нет.
В этот самый момент вы можете спросить себя, будет ли ваш фрагмент кода работать безупречно, то есть без прерывания производства или возникновения ошибок.
У вас может быть некоторая неуверенность в своем коде. Итак, вы начинаете задавать себе некоторые вопросы, например:
- Сломает ли мой код производственный код? Что если, а что нет? 😓
Поздравляем! Вы только что разблокировали часть синдрома самозванца. 🎉 😒
Синдром самозванца затрагивает всех разработчиков разного уровня, от самых младших до старших.
Существует 5️ типов синдрома самозванца:
- Перфекционист
2. Суперженщина/мужчина
3. Природный гений
4. Солист
5. Эксперт
По крайней мере, вы можете оказаться в одном из этих типов, кхм.
Назад к истории… 🔽
Что вам действительно сейчас нужно, так это ясность и безопасность вашего кода, а не просто одобрение или похвала от вашего коллеги.
Как бы вы добились ясности и безопасности в своем коде? 🤔
Тест. Твой. Код. 🙂
Тестируемый код обычно оценивается по надежности, качеству и эффективности программного обеспечения. Неудивительно, что качество кода часто приводит к большему количеству довольных клиентов.
Таким образом, один из подходов к достижению ясности и преодолению синдрома самозванца — это тестирование кода.
Теперь, что может быть хорошей практикой, если я хочу протестировать свой код? TDD в помощь. 💡
Три столпа разработки через тестирование (TDD):
- Пишите производственный код только для того, чтобы пройти неудачный модульный тест.
- Пишите не больше модульного теста, чем достаточно для отказа (сбои компиляции — это сбои).
- Пишите не больше производственного кода, чем необходимо для прохождения одного неудачного модульного теста.
Помимо столбов, есть еще одна форма руководства, которая действует по кругу. Цикл TDD: красный-зеленый-рефакторинг
Заключение
В статье основное внимание уделяется предоставлению примера распространенной ситуации и одного из многих подходов для разработчиков, позволяющих избежать ненадежности при разработке.
Хотя статья не рекламирует специально рекламируемые функции TDD, она может помочь в наблюдении за повседневной работой. 🙌