By ベン・ホスキング
優れたコードはあなたを救わないが、悪いコードはあなたを葬る#HoskWisdom開発者が敗者だと言っているわけではありませんが、ほとんどのソフトウェア開発者はソフトウェア開発を打ち負かしておらず、ソフトウェア開発が彼らを打ち負かしています。
開発者が苦労している理由は、自分がどんなゲームをプレイしているのか、どんな戦術が最適なのか知らないからです。
ソフトウェア開発というゲームがどんなものかを知っていれば、効果的にプレイすることができます。
コードを書くという創造的なプロセスでは、コードが間違っているかどうかではなく、コードが間違っているときに、それをできるだけ簡単な方法で修正することが重要です。
勝者と敗者
チャールズ・エリスのエッセイ「敗者のゲーム」では、プロテニスは選手がポイントを獲得する勝者のゲームであると指摘しています。アマチュアのテニスは、ボールを生かして相手に自分を打ち負かすという別の戦略を使用して勝ちます。
「達人のテニスでは、約80%のポイントが獲得され、アマチュアのテニスでは、約80%のポイントが失われる。つまり、プロテニスは勝者の行動によって最終的な結果が決まる「勝者のゲーム」であり、アマチュアのテニスは敗者の行動によって最終的な結果が決まる「敗者のゲーム」である。この2つのゲームは、その基本的な特性において、まったく同じではない。両者は正反対である。」チャールズ・エリス同じゲームでも、相手によって有効な戦略は変わってきます。
「達人のテニスは、私が勝者のゲームと呼ぶものである。勝利とは、相手の獲得ポイントよりも多くのポイントを獲得することである。後ほど説明するが、単に相手よりも高いスコアを獲得するのではなく、ポイントを獲得することにで高いスコアを獲得するのだ。アマチュアのテニスは、ラモが発見したように、全く違うものである。アマチュアの下手な人はめったに相手に勝つことはないが、自分自身にはいつも勝っている。このテニスの勝者は、相手よりも高いスコアを得るが、その高いスコアを得るのは、相手がさらに多くのポイントを失っているためである。」チャールズ・エリスソフトウェア開発のゲーム
私は20年間ソフトウェア開発に携わり、多くのソフトウェア開発者と多くのプロジェクトを共にしてきました。ソフトウェア開発者の80%はアマチュアで、20%はプロだと私は推測しています。
なぜこのようなことを言うのでしょうか?
アマチュアのソフトウェア開発者は次のことが嫌いです。
- 標準規格
- 単体テスト
- デザインパターン/SOLIDの原則
- DevOpsとALMの学習と設定(彼らはそれを使用するのが好きです)
- ビルドの修正
- コードレビュー
- コード分析/ソリューションチェック
もし、あなたがほとんどの開発チームを妨害しようとしていたとしたら、チームのほとんどの開発者はプロではないため、上記のような手順はしないでしょう。
「ミスを避ける方法は、保守的になってボールをキープし、相手に余裕を持たせておくことだ。なぜなら、相手はアマチュアだから(そして、おそらくラモの本を読んでいない)、負けゲームをしても自分では気付かないからだ。」チャールズ・エリス
ほとんどの開発者は、コードを書くことを過小評価し、動作するソフトウェアを作成する能力を過大評価しています。彼らは、コードを書くことは簡単で、そのコードは最初から動作するものだと思ってコードを書くというアプローチをします。
アマチュア
開発者が大多数がアマチュアであるなら、ソフトウェア開発者を敗者復活戦として捉え、アマチュアが陥りやすいミスを減らすことに力を注ぐべきです。
アマチュア開発者の目的はコードを書くことであり、それ以外の活動はプロセスを遅らせることになります。上記の他のステップは、単純なコードを作成し、バグを早く見つけ、品質に集中することです。ALM/Devopsは、エラーのない迅速なデプロイを可能にし、迅速なフィードバックを可能にします。
コードを素早く書くための最善の方法は、コードを速く書くことではなく、品質に集中してバグを減らすことです。
バグ、エラー、ミスのコストは、プロジェクト/開発チームが大きくなるほど重要になります。大規模なチームでの問題は多くの人々を遅らせることになり、上記のリストの活動を実施することで止めることに重点を置くべきです。
私は、バグによって勢いが失われたプロジェクトに携わったことがあります。また、後期段階で見つかったバグはユーザの信頼を失い、本番稼働のリスクとなります。
逆にする
ソフトウェア開発を逆にすると、目標は動作するコードを書くことではなく、質の悪いコードやバグを書かないようにすることに時間を費やすことになります。
「私たちのような人たちは、非常に知的であろうとする代わりに、一貫して愚かではないように努めることで、長期的にどれほどの優位性を得てきたかは驚くべきことである。」— チャーリー・マンガー
アマチュア開発者は、コードを素早く書くことが、本番環境に対応したコードを作るための最速の方法だと信じています。大きなメソッドと複雑なコードは、コードベースを作李、コードが一行増えるごとに複雑さが増し、開発を困難にします。これは、1人か2人の開発者が取り組んでいる小さなプロジェクトでしか通用しないアプローチです。
バグのコスト
バグが書かれた時間から離れたところで発見すればするほど、修正には時間がかかります。例えば、本番環境でバグを見つけた場合は、それを理解し、再現し、開発者がコードを修正し、本番環境まで各環境でデプロイとテストを行わなければなりません。
単体テストで同じバグを見つけた場合は、より迅速に修正し、他の開発者やテスターへの影響を減らすことができます。
開発プロセスに簡単な手順を追加してバグを見つけることができます。バグに多くの時間が費やされ、顧客からの信頼を失うゲームでは、これが最も効果的なアプローチです。
開発チームのほとんどが、自分自身や開発チームを打ち負かしがちなアマチュアであることが分かっている場合、開発チームが、全員が優れたコードを作成するプロの開発者であると仮定するよりも、バグを阻止することに重点を置くのが理にかなっています。
開発における成功とは、最初からコードを正しく作ることではなく、様々な失敗を回避することなのです。
チャールズ・エリスの言葉を借りれば、
「プロはポイントを獲得するが、アマチュアはポイントを失う。」さらなる情報