Разработка программного обеспечения — игра проигрывающих

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

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

Вам нужно знать, в какую игру вы играете, чтобы вы могли играть эффективно.

В творческом процессе написания кода нет ситуации “если код будет неправильным”, а есть “когда он будет неправильным” — это позволит исправить его самым простым способом.

Победитель и проигравшие

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

В профессиональном теннисе около 80% очков набирается выигрышем; в любительском теннисе около 80% очков проигрывается. Другими словами, профессиональный теннис — это игра победителя. Окончательный результат определяется действиями победителя. А любительский теннис — это игра проигравшего. Конечный результат определяется действиями проигравшего. Эти две игры по своей фундаментальной характеристике совсем разные. Они противоположности, — Чарльз Эллис.

Та же игра, но эффективная стратегия зависит от того, с кем вы играете.

Профессиональный теннис — это то, что я называю игрой победителя. Победа происходит из-за того, что кто-то набирает больше очков, чем противник. Не просто, как мы увидим позже, из-за получения большего количества очков, чем противник, а из-за того, что выигрывается большее количество очков. Любительский теннис, как выяснил Рамо, почти полностью отличается. Любитель редко обыгрывает своего противника, но все время обыгрывает самого себя. Победитель в этой игре получает больше очков, чем соперник, но он получает больше очков, потому что его противник теряет еще больше очков, — Чарльз Эллис.

Игра в разработку

Я занимаюсь разработкой программного обеспечения 20 лет, работал над многими проектами со многими разработчиками программного обеспечения. По моим оценкам, 80% разработчиков программного обеспечения — любители, а 20% — профессионалы.

Почему я это говорю?

Разработчикам-любителям не нравятся:

• Стандарты
• Модульное тестирование
• Паттерны проектирования/принципы SOLID
• Изучение и настройка DevOps и ALM (но нравится это использовать)
• Исправление сборок
• Code Review
• Анализ кода/проверка решения

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

«Чтобы избежать ошибок, нужно быть консервативным и держать мяч в игре, позволяя сопернику иметь достаточно места, чтобы ошибиться на пути к поражению, потому что он, будучи любителем (и, вероятно, не читая книгу Рамо), будет играть игру проигравшего и сам не знать этого», — Чарльз Эллис.

Большинство разработчиков недооценивают написание кода и переоценивают свои способности создавать работающее программное обеспечение. Их подход к написанию кода предполагает, что писать код легко, и он будет работать с первого раза.

Начинающие

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

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

Лучший способ быстро писать код — сосредоточиться на качестве и уменьшении количества ошибок, а не писать код быстрее.

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

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

Инвертируем

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

Примечательно, сколько долгосрочных преимуществ получили такие люди, как мы, постоянно стараясь не быть глупыми, вместо того, чтобы быть очень умными, — Чарли Мангер.

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

Стоимость ошибок

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

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

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

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

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

Или, цитируя Чарльза Эллиса, «профессионалы выигрывают очки, а любители их теряют».

Источник