principle-the-algorithm

アルゴリズム

ひと目で分かる編集を超える変更には、順番どおりに次の5つのステップを適用します。この順序こそが原則です。各ステップは、その前のステップを終えてから取り組むことで初めて、低コストになります。よくある失敗は、早い段階で取り除けたはずのものに、後のステップを適用することです。Elon Muskの5段階のエンジニアリングプロセスを応用しています。

1. 要件をもう少しましにします。 要件は間違っていると考え、少しでも正しいものにします。要件は部署ではなく、人から出てきます。「チケットに書いてあるから」「リンターが指摘したから」「レビュアーが言ったから」「以前のコードがそうしていたから」は、出どころであって理由ではありません。本人を探し、その考えを確認します。その考えに納得できないなら、要件を受け入れてはいけません。要件を出した人がどれほど優秀であっても、あなた自身であっても同じです。「いいえ」も妥当な結論です。
2. 部品またはプロセスのステップを削除します。 ステップ3に進む前に、部品、フラグ、レイヤー、再試行、ステップを完全に削除できないか、まず徹底的に検討します。存在すべきでないものを最適化することは、優秀な人が犯す最大の間違いです。何も追加し直さなかったなら、削除が足りていません。リーフ：pstack principle-subtract-before-you-add。
3. 最適化します。これは3番目のステップであり、最初ではありません。呼び出し元ごとに並行したコピーを作るのではなく、1つの部品に複数の役割を担わせます。所有者やレイヤーの境界、特にラッパーが別のラッパーを包んでいる箇所を重点的に確認します。リーフ：pstack principle-laziness-protocol、principle-minimize-reader-load。
4. 加速します。 自ら作業を進めます。変更を1つ選び、編集、ビルド、確認、レビューまで自分で通し、待つ、進みが遅い、行き来するといった箇所を記録します。それを改善します。リーフ：pstack principle-sequence-verifiable-units。
5. 最後に自動化します。そうしないと、存在すべきでないものを自動化することになります。作業量が多いだけでは、自動化の理由になりません。精度とレビューのしやすさが理由になります。pstack principle-build-the-leverは引き続き当てはまります。自動化は、残ったものに適用します。

もう一度実行します。 これは一度きりの関門ではありません。リリース前に、結果に対してもう一度実行します。2回目の実行では、さらに多くを削除できます。

見分け方。 この原則を引用するなら、どの要件を改善したのか、その要件の担当者は誰か、何を削除したのかを明記します。どちらも示していない引用は、この原則を実践していません。