Писать код — это «игра проигравших». Как теннис может изменить взгляд на программирование

Разработчик Тайлер Хокинс написал пост, в котором высказал свое мнение об ошибках, которые допускают специалисты, как от них избавиться и стоит ли вообще это делать. Свою основную позицию автор выразил, опираясь на наблюдения известного бизнесмена, которую тот сформулировал, наблюдая за игрой в теннис. Что из этого вышло и как отреагировали пользователи — читайте далее.

Вот что он написал.

«Игра проигравших» и «игра победителей»

Недавно меня увлекла идея, которую в 1973 году описал бизнесмен Саймон Рамо. За много лет наблюдений он понял, что теннис — это не одна игра, а две. В одну играют профессионалы и одаренные любители, а в другую — все остальные.

Разница в том, что профессионалы выигрывают очки, а любители их теряют. Профессионалы играют скучно и редко допускают ошибки, а любители — эффектно, но с массой ошибок. Профессионал выигрывает потому, что оппонент делает больше ошибок, чем он. Другими словами, проигравший побеждает сам себя. Это «игра проигравшего».

Когда играют два профессионала, игра выигрывается в основном за счет мастерства победителя. Ни один из игроков не совершает много ошибок. Победитель делает более точные удары и превосходит своего соперника. Очки в такой игре «выигрываются» победителем чаще, чем «проигрываются» проигравшим. Это «игра победителя». 

Поэтому если вы играете в «игру проигравших», ваша задача — просто стараться избегать ошибок и позволить противнику победить самого себя.

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

Параллель с разработкой программного обеспечения

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

Легко сказать: «Если хочешь быть хорошим специалистом, просто перестань делать ошибки». Но это все равно, что сказать тем, кто живет в бедности: «Почему бы вам просто не перестать быть бедными?».

Если главная цель — не избегать ошибок, то считается ли лучшим программистом тот, кто не пишет код и ничего не делает? Очевидно, что нет. Разработчикам ПО платят за написание кода, чтобы они создали продукт, который будет решать ту или иную задачу. Это и есть главная цель разработки.

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

Какие ошибки допускают разработчики

Вот список ошибок, которые мы совершаем. Скорее всего, вы с легкостью можете дополнить этот перечень:

• Не разбираемся в проблеме, прежде чем пытаемся решить ее;
• Не понимаем инструменты или языки программирования, которые используем;
• Не проверяем и не тестируем код вручную, прежде чем отправить его на код-ревью;
• Не пишем модульные тесты;
• Не соблюдаем стандарты компании.

Работа над ошибками

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

Также можно быть более внимательным к деталям при написании кода. После создания мердж-реквеста разработчик всегда должен проводить самостоятельную проверку кода, прежде чем просить других проверить его.

Для рецензента кода нет ничего хуже, чем проверять код, который разработчик ранее не проверил самостоятельно. Рецензент теряет время, ведь ему приходится вылавливать такие простые ошибки, как, например, закомментированный код, плохое форматирование, неудачные модульные тесты или неработающие функции в коде. Все эти ошибки могут быть легко отловлены автором кода или CI-конвейером.

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

Мы можем использовать чек-листы и шаблоны запросов на слияние, чтобы не забыть, что нужно перепроверить. Вот несколько вопросов, на которые нужно ответить, чтобы избежать ошибок.

• Проверяли ли вы свой собственный код?
• Написали ли вы модульные тесты?
• Обновляли ли вы документацию по мере необходимости?
• Что касается кода фронтенда, проверили ли вы изменения в каждом браузере, который поддерживает ваша компания?
• Обеспечили ли вы перевод всего текста, обращенного к пользователю?
• Убедились ли вы, что пользовательский интерфейс соответствует стандартам и рекомендациям по доступности?

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

Разработка — это не теннис!

Не все согласны с мнением автора. Так, разработчик Бенджамин Делеспьер придерживается кардинально другого мнения. Он считает, что специалисты должны совершать ошибки. Вот, что он советует разработчикам: 

Пишите код. Напишите что угодно, пусть даже несуразное, и запустите это в продакшн. Почувствуйте боль от того, что ваш проект разваливается на части, когда первые пользователи вводят неожиданные данные или используют его очень глупым образом. Затем разберитесь, что не так и исправьте это. Сделайте ваше приложение лучше — более эргономичным, чтобы люди использовали его правильно без ваших подсказок. Повторите описанные действия несколько раз, так вы накопите необходимый опыт

Бенджамин Делеспьер уверен, что разработка — это не теннис, а искусство. В нем нет прямых «делать» или «не делать». Но есть куча принципов и рекомендаций. Если программирование — это не более чем разговор с машиной, то разработка — это общение, танец между машинами, людьми, предприятиями, структурами, инфраструктурами. Вряд ли можно найти аксиоматическую истину о том, что делает программное обеспечение хорошим. Это все равно, что пытаться раз и навсегда определить, что такое хороший танец.

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