Чтобы стать лучше, учитесь на своих ошибках и прекращайте совершать невынужденные ошибки
Недавно я увлекся идеей «игры победителя» и «игры проигравшего». Есть несколько замечательных статей, которые подробно объясняют эту идею, но вот краткое изложение:
В 1973 году Саймон Рамо сделал наблюдение, что в любительском и профессиональном теннисе выигрывается большая разница.
Когда играют два соперника-любителя, игра часто выигрывается не из-за большого мастерства победителя, а из-за ошибок проигравшего. Проигравший часто совершает невынужденные ошибки, выбивая мяч за пределы игровой площадки, пропуская легкие удары или совершая двойную ошибку. Другими словами, проигравший бьет сам себя. Очки «теряются» проигравшим больше, чем «выигрываются» победителем. Это «игра проигравших».
Когда играют два профессиональных соперника, игра выигрывается в первую очередь благодаря мастерству победителя. Ни один из игроков не совершает много невынужденных ошибок. Победитель удачно размещает свои удары и превосходит своего противника, чтобы победить его. Очки в такой игре «набираются» победителем больше, чем «теряются» проигравшим. Это «игра победителя».
Итак, если вы играете в игру проигравшего, выигрышная стратегия - просто попытаться избежать ошибок и позволить оппоненту победить себя.
(Если вы когда-либо раньше играли в теннис или пинг-понг, я надеюсь, что в этот момент вы киваете в знак признания. Как заядлый игрок в пинг-понг, я видел, как этот сценарий разыгрывался в офисе на работе ежедневно основы.)
Применение этого наблюдения состоит в том, что вы должны попытаться понять, является ли какое-либо конкретное действие, в котором вы участвуете, игрой победителя или игрой проигравшего. Обретение этого понимания научит вас тому, как вы должны играть в игру.
Вы можете прочитать больше об этих идеях в этой статье Чарльза Эллиса, этой статье из блога FS или этой статье Бена Хоскинга.
Параллели с программной инженерией
А что, если мы считаем разработку программного обеспечения игрой для проигравших? То есть мы часто побеждаем себя, совершая невынужденные ошибки и совершая ошибки. Если мы, так сказать, любители, как мы можем держать мяч в игре, а не забивать его в сетку?
Сказать просто: «Если хочешь быть хорошим, просто перестань ошибаться». Но это несколько бесполезно. Это все равно, что сказать бедным: «Почему бы тебе просто не перестать быть бедным?»
Также бесполезно зайти слишком далеко в этой аналогии. Если конечной целью разработки программного обеспечения является предотвращение ошибок, то является ли лучший инженер-программист тем, кто не пишет кода или ничего не делает? Очевидно, нет. Программным инженерам платят за написание кода, который поможет воплотить в жизнь какой-либо продукт, чтобы достичь определенного видения (заработать деньги для бизнеса, решить реальную проблему, упростить задачу и т. Д.), Так что это должно быть реальной конечной целью.
Таким образом, похоже, что мы должны сбалансировать получение ценной продукции с недопущением ошибок. Это приводит к интересному мысленному эксперименту: как мы побеждаем самих себя и как мы можем избежать этих любительских ошибок?
Невыполненные ошибки
Вот список возможных невынужденных ошибок, которые мы совершаем. Я уверен, что вы также сможете добавить больше в этот список.
- Непонимание проблемы, прежде чем пытаться закодировать решение
- Непонимание инструментов или языков программирования, которые мы используем
- Отсутствие тщательной проверки нашего собственного кода перед запросом проверки кода
- Отсутствие ручного тестирования собственного кода перед запросом проверки кода
- Не писать модульные тесты
- Несоблюдение согласованных стандартов компании
Решение этих невынужденных ошибок
Теперь, когда мы определили несколько потенциальных невынужденных ошибок, как нам их избежать?
Во-первых, мы можем принять меры, которые помогут нам выявлять и исправлять наши ошибки, прежде чем они станут слишком дорогостоящими. Все репозитории кода должны быть настроены с помощью анализаторов кода, средств форматирования кода и набора автоматических тестов. Эти меры безопасности могут быть запущены как часть конвейера CI до того, как разрешить слияние любого кода.
Мы также можем более внимательно относиться к деталям при написании кода. После создания мерж-реквеста мы всегда должны проводить самопроверку кода, прежде чем просить других проверить наш код. Мы также всегда должны вручную проверять наши изменения.
Для рецензента кода нет ничего более неприятного, чем просмотр чужого кода, который явно не выполнял эти проверки самостоятельно. Это напрасно тратит время обозревателя кода, когда ему приходится вылавливать простые ошибки, такие как закомментированный код, неправильное форматирование, сбои модульных тестов или нарушение функциональности кода. Все эти ошибки может легко обнаружить автор кода или конвейер CI.
Когда запросы на слияние часто содержат ошибки, это превращает процесс проверки кода в процесс контроля, в котором несколько более старших инженеров служат привратниками. Это неблагоприятный сценарий, который создает узкие места и снижает скорость работы команды. Это также отвлекает от более высокой цели проверки кода, а именно от обмена знаниями.
Мы можем использовать контрольные списки и шаблоны мерж-реквестов, чтобы напоминать себе о том, что нужно перепроверить. Вы проверяли свой собственный код? Вы писали модульные тесты? Вы обновляли документацию по мере необходимости? Что касается внешнего интерфейса, проверяли ли вы свои изменения в каждом браузере, поддерживаемом вашей компанией? Обеспечили ли вы перевод всего текста, ориентированного на пользователя? Удостоверились ли вы, что пользовательский интерфейс соответствует стандартам и рекомендациям по обеспечению доступности?
Выполняя эти проверки самостоятельно с помощью автоматизированных инструментов, мы демонстрируем дополнительный профессионализм и уважение к нашим коллегам. Доверие будет расти, и скорость увеличится. Главное - быть прилежными и дисциплинированными.
Заключение
Программная инженерия - игра проигравших. Так что давайте научимся играть в эту игру и перестанем проигрывать себе.
