Обычное событие для разработчика 👨‍💻

Представьте, что вы разрабатываете функцию, и вы находитесь прямо в той точке, где вы хотите поместить код в свой репозиторий кода, а затем в рабочую среду. Падение микрофона? Нет.

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

У вас может быть некоторая неуверенность в своем коде. Итак, вы начинаете задавать себе некоторые вопросы, например:

  • Сломает ли мой код производственный код? Что если, а что нет? 😓

Поздравляем! Вы только что разблокировали часть синдрома самозванца. 🎉 😒

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

Синдром самозванца затрагивает всех разработчиков разного уровня, от самых младших до старших.

Существует 5️ типов синдрома самозванца:

  1. Перфекционист

2. Суперженщина/мужчина

3. Природный гений

4. Солист

5. Эксперт

По крайней мере, вы можете оказаться в одном из этих типов, кхм.

Назад к истории… 🔽

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

Как бы вы добились ясности и безопасности в своем коде? 🤔

Тест. Твой. Код. 🙂

Тестируемый код обычно оценивается по надежности, качеству и эффективности программного обеспечения. Неудивительно, что качество кода часто приводит к большему количеству довольных клиентов.

Таким образом, один из подходов к достижению ясности и преодолению синдрома самозванца — это тестирование кода.

Теперь, что может быть хорошей практикой, если я хочу протестировать свой код? TDD в помощь. 💡

Разработка через тестирование (TDD) — это практика разработки программного обеспечения, которая фокусируется на создании сценариев модульного тестирования перед разработкой фактического кода. Это итеративный подход, сочетающий в себе программирование, создание модульных тестов и рефакторинг.

Три столпа разработки через тестирование (TDD):

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

Помимо столбов, есть еще одна форма руководства, которая действует по кругу. Цикл TDD: красный-зеленый-рефакторинг

Заключение

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

Хотя статья не рекламирует специально рекламируемые функции TDD, она может помочь в наблюдении за повседневной работой. 🙌