Как хорошие тесты могут улучшить качество решений

Заявление об ограничении ответственности: хотя эта статья является сатирической, поднятые вопросы все же в некоторой степени актуальны!

Вы тратите больше времени на проверку кода, чем на его написание? Вы заметили, что смотрите на файл 126 из 500 и не помните, как попали туда? Вы не раз сталкивались с гневом разработчиков в комментариях? Если вы ответили утвердительно, возможно, вы страдаете от усталости от связей с общественностью.

Усталость от PR - основная причина смерти стартапов. Это также фактор риска номер один для разработчиков, которым наплевать.

Если вы или ваш любимый человек страдаете от усталости от пиара, эта статья может вам помочь.

Люди плохо пишут код. Говорят, что люди записывают нечеткое описание того, что они хотят делать, а машины приходят и очищают это. Учитывая постоянно расширяющийся список инструментов статического анализа кода на рынке, с этим утверждением трудно поспорить. AWS CodeGuru - это последняя попытка помешать людям испортить свой код, и она была встречена с некоторым энтузиазмом. Но ни один из этих инструментов не может доказать, что код действительно выполняет то, для чего он предназначен, и ничего больше. Это проблема более сложная, чем могут решить современные машины.

К счастью, инженеры-программисты действительно хороши в решении сложных проблем и их создании (разве это великий парадокс программной инженерии?). Одна из самых сложных задач, которую может решить инженер, - это формальная проверка. Но программисты тоже ленивы. Если мы позволим симбиозу быть нашим руководством, мы быстро поймем, что машины должны писать большую часть кода, а ленивые люди, переедающие кофеин, должны писать большую часть тестов. Если мы применим эту теорию к проверке PR, мы можем утверждать, что инженеры должны проверять тест, а машины должны проверять код!

Но как же ленивым людям, пьющим Redbull, писать хорошие тесты? Что ж, к счастью, у Google есть инженеры, которые всегда требуют хороших тестов. Если мы вернемся к 2015 году, Винтерс и Райт придумали структуру, которая по-прежнему актуальна сегодня, как и тогда. Они определяют пять столпов хороших тестов как:

  1. Правильность
  2. Читаемость
  3. Полнота
  4. Демонстративность
  5. Устойчивость

Они даже видео сняли, потому что знают, какие мы ленивые!

Новый процесс

  1. Разбивайте сложные функции на более мелкие результаты. Обратитесь к опытному старшему инженеру, чтобы помочь вам в этом. Планирование в покере - отличное место!
  2. Открыть черновик PR
  3. Полностью опишите, что должен делать код в PR
  4. Напишите свои тесты. Это ваша возможность подумать и определить наблюдаемый интерфейс. Всегда помните Закон Хайрама: При достаточном количестве пользователей API не имеет значения, что вы обещаете в контракте: все наблюдаемое поведение вашей системы будет кем-то зависеть.
  5. Создайте свой код.
  6. Когда ваши тесты пройдут успешно, отправьте свой PR на рассмотрение.
  7. Рецензенты должны оценивать ваши тесты и ничего больше. Если вы заметили утечку заметного аспекта вашего интерфейса, устраните утечку и докажите это в своем тесте.

Вывод

Усталость от PR - серьезная проблема. Это влияет на все демографические группы и приводит к серьезной нехватке кофеина. Если мировые запасы кофеина истощатся, мы столкнемся с критической нехваткой функциональных инженеров. Пожалуйста, внесите свой вклад, чтобы помочь сообществу бороться с этой новой глобальной угрозой. Спасибо.

Больше контента на plainenglish.io