Clean Code: 10 Principles That Make You a Better Developer — cod-ai.com

私は、50,000行のコードベースを引き継いだ日を今でも覚えています。それは私のキャリア選択に疑問を投げかけるものでした。2015年のことで、私はフィンテックスタートアップのシニア開発者として3年目で、私たちのリードエンジニアがドキュメントなしで去ったばかりでした。コードはなんとか動いていましたが、読むのはまるで未来の開発者を積極的に嫌っている誰かによって書かれた古代のヒエログリフを解読するようなものでした。その経験は、私にクリーンコードについて、どんな教科書よりも多くのことを教えてくれました。

9年が過ぎ、私は今、1日に200万件以上のトランザクションを処理するシステムを管理する会社でプリンシパルエンジニアとして働いています。何千ものプルリクエストをレビューし、数十人の開発者をメンターし、認めたくないほど多くのレガシーコードをリファクタリングしてきました。そのすべてを通じて、良いコードと素晴らしいコードを分けるものを、私の仕事だけでなく、私が指導したすべての開発者の仕事を変革させた10の基本原則にまとめました。

クリーンコードは、ペダンティックであったり、ルールのためにルールに従うことではありません。それは、尊重、未来の自分、チームメイト、そして午前2時にあなたの仕事を維持する次の人に対する尊重についてのものです。私が学んだことを共有させてください。

汚れたコードの真のコスト

原則に入る前に、なぜこれが重要なのかを話しましょう。現在の役割で、私たちはエンジニアリングチームの生産性を追跡する内部調査を行いました。私たちは、開発者が既存のコードを読むことと理解することに平均して65％の時間を費やしているのに対し、実際に新しいコードを書くのはわずか35％であることを発見しました。その比率は、悪く書かれたコードではさらに悪化し、私たちのレガシーシステムでは80/20に跳ね上がります。

ここでのポイントは、あいまいな変数名が理由で私たちのチームに四半期あたり約127時間のコストをかけていると計算したことです。それは、x、temp、またはdata2が実際に何を表しているのかを理解するのに費やす3週間以上です。それを40人のエンジニアのチーム全体に掛けると、悪い命名規則のような単純なことで六桁の年間コストが発生します。

プロジェクトが失敗するのを見てきましたが、それは技術的不可能性によるものではなく、コードベースがあまりにも複雑になったため、単純な変更ですら数週間かかるようになったからです。私がコンサルタントをしていたあるeコマースクライアントは、決済システムが脆弱すぎて新しい支払い方法を追加するのに3か月の開発サイクルが必要だったため、推定50,000ドルの収益を毎日失っていました。クリーンコードの原則を適用して6週間のリファクタリングスプリントを行った後、その同じ変更は4日で完了しました。

ビジネス上の理由は明確です：クリーンコードは、あなたの利益、チームの士気、そして革新する能力に直接影響を与えます。さあ、それを実現する方法を探ってみましょう。

原則1: 意味のある名前が最初のドキュメントとなる

かつて、短い変数名がコードを速く入力することを主張する開発者と一緒に働いたことがあります。彼は、let u = getUserData()やconst p = calculatePrice()のようなことを書いていました。3か月後に彼のコードを説明してもらったところ、彼はできませんでした。彼は自分の略語システムを忘れてしまっていたのです。

あなたの変数、関数、クラス名は物語を語るべきです。それらは、コメントを必要とせずに意図を明らかにする必要があります。これらの2つの例を比較してみましょう：

悪い： const d = 86400;

良い： const SECONDS_PER_DAY = 86400;

その違いは一見些細に思えますが、真夜中にデバッグして計算がなぜ間違っているのかを理解しようとしているときには重要です。2番目のバージョンは、その魔法の数字が何を表すのかをすぐに教えてくれます。

私が毎回のジュニア開発者に共有する命名チェックリストは次のとおりです：

• 発音できる名前を使用する—コードレビューで言えない名前はあまりにも暗号的です
• 検索可能な名前を使用する—単一文字変数はCtrl+Fで見つけるのが不可能です
• メンタルマッピングを避ける—読者に略語を翻訳させないでください
• 概念ごとに1つの言葉を選ぶ—fetch、retrieve、およびgetを同じ操作に混ぜないでください
• ソリューションドメイン名を使用する—他のプログラマーはあなたのコードを読むので、AccountVisitorやJobQueueは理にかなっています

実践では、名前を考えるのに30秒余分にかけることで、後での混乱の平均15分を節約することが分かりました。これは30倍の投資リターンです。それをプロジェクト内の数百の変数に掛け合わせると、時間の節約は非常に大きくなります。

私が使用する一つの技術は、変数の機能を1つの明確な文で説明できない場合、その名前は十分ではないということです。自分でも試してみてください—何かの名前を決めるのに苦労している場合、それはしばしばそのものがやりすぎていて、分解する必要があることを示すサインです。

原則2: 関数は1つのことを行い、それをうまく実行すべきである

単一責任の原則は、学術的な理論ではなく、生き残りの戦略です。私は、入力を検証し、税金を計算し、在庫を更新し、メールを送信し、分析を記録し、支払い処理を行うという400行の関数processOrderをデバッグしているときにこれを辛い方法で学びました。税金計算のバグを見つけることは、無関係なメールテンプレートコードをかき分けることを意味しました。