「美しいコードを称賛すべきではない理由」
私たちは皆、これを見たことがあるでしょう。コードは非常に複雑で構造が純粋なので、保管庫ではなく博物館にあるものです。これは、デバッグが必要であることに気づくまで、しばらくの間、畏敬の念を持って見つめるようなコードです。そうなると、他の凡人同様、なぜ誰かが次の偉大なアメリカ小説を書くかのように JavaScript を書こうと決めたのか疑問に思うことになるでしょう。
はっきりさせましょう。美しいコードは、役に立つ場合にのみ美しいものとなります。あなたのチームに博士号が必要な場合は、難解な構文を使用して、機能がどのように機能するかを理解できます。おめでとうございます。誰もメンテナンスすることのない傑作が作成されました。
ここでは、あまりにも巧妙なコードを作成したいという衝動を抑えるべき理由と、その代わりに何をすべきかを説明します。バックルを締めてください。例は今後も登場します。
過剰に設計されたエレガンスの魅力
まず、開発者がこの種のコードを作成する理由を調べてみましょう。
例 1: 「WTF」ファクトリー関数
これは私が最近偶然見つけた宝石です:
const createMultiplier = (x) => (y) => (z) => x * y * z; const multiply = createMultiplier(2)(3); console.log(multiply(4)); // Outputs 24
美しい?もちろん。しかし、ここで何が起こっているのかを理解する必要があるジュニア開発者に幸運を祈ります。 3 つの数値を乗算する関数が 3 層ある?おめでとうございます。算数がオリンピック種目に採用されました。
これはやめてください。以下は人間向けに書かれた同じ機能です:
function multiplyThreeNumbers(x, y, z) { return x * y * z; } console.log(multiplyThreeNumbers(2, 3, 4)); // Outputs 24
読める。単純。全員の正気を保ちます。
例 2: シェイクスピアの約束の連鎖
次に、シェイクスピアによってゴーストライターで書かれたように見えるプロミスチェーンについて話しましょう:
fetch(url) .then((response) => response.json()) .then((data) => data.map((item) => item.isActive ? { ...item, status: "active" } : { ...item, status: "inactive" } ) ) .then((updatedData) => updatedData.reduce( (acc, curr) => curr.status === "active" ? { ...acc, active: [...acc.active, curr] } : { ...acc, inactive: [...acc.inactive, curr] }, { active: [], inactive: [] } ) ) .then((finalResult) => console.log(finalResult)) .catch((error) => console.error(error));
このコードは機能します。しかし、それを維持しなければならない人に対する犯罪でもあります。データ変換の各ステップがロシア人形のように次のステップの中に入れ子になっているのはなぜですか?
リファクタリングしましょう:
async function processData(url) { try { const response = await fetch(url); const data = await response.json(); const updatedData = data.map((item) => ({ ...item, status: item.isActive ? "active" : "inactive", })); const finalResult = updatedData.reduce( (acc, curr) => { if (curr.status === "active") { acc.active.push(curr); } else { acc.inactive.push(curr); } return acc; }, { active: [], inactive: [] } ); console.log(finalResult); } catch (error) { console.error(error); } } processData(url);
ロジックをステップに分割すると、コードが読みやすくなります。依然として同じことを行っていますが、各段階で何が起こっているかが明確になりました。
シンプルなほうが良い理由
ソフトウェアに関しては、この黄金律を思い出してください。コードは個人的な日記ではありません。それはコミュニケーションツールです。チームがそれを読めなければ、それを使って作業することはできません。そして、彼らがそれに取り組むことができなければ、ビジネスは前進できません。
シンプルさが勝つ理由は次のとおりです:
1 オンボーディングの迅速化: ジュニア開発者はコードを理解するために Rosetta Stone を必要としません。
2 デバッグが簡単: バグが発生したとき (そして今後も発生するでしょう)、明確なロジックによりバグの特定が容易になります。
より幸せな 3 チーム: バカにされるのが好きな人はいません。あまりに巧妙なコードはチームメイトを疎外します。
テイクアウト
ぐっすり眠った後の未来の自分に説明するようにコードを書きましょう。あなたの作品を読まなければならない次の開発者には親切にしてください。その開発者はあなたである可能性が高いからです。
美しいコードとは、見た目がどれだけ派手かということではありません。問題をどれだけ効果的に解決できるかが重要です。それ以下のものは単なる虚栄心の訓練にすぎません。
以上がリポジトリではなく博物館に属するコードの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。