クリーンアプローチによってコードがより明確でシンプルになり、強力になる理由

この記事は、プログラマー必読の書籍の 1 つとされる「Clean Code」の第 1 章から抜粋したものです。しかし、良い本はツールやテクニックを教えてくれるだけでなく、もっと重要なのは、禅や真理に近い思考プロセスについて教えてくれることです。この本はまさにこの定義に当てはまります。この章には技術的な要素が最も少なく、あらゆる分野の人が読むのに適しています。

この本を読む理由は 2 つあります。1 つ目は、あなたがプログラマーであるということ。2 つ目は、より優れたプログラマーになりたいということです。とても良い。より優秀なプログラマーが必要です。

これは良いプログラムの書き方に関する本です。コードがいっぱい詰まっています。これらのコードをあらゆる方向から調べる必要があります。上から下へ、下から上へ、内側から外側へ。これを読めば、コードについて多くのことが分かるでしょう。さらに、良いコードと悪いコードの違いもわかります。良いコードの書き方を学びます。悪いコードを良いコードに変更する方法も学びます。

1.1 コードが必要です

コードに関する本は時代遅れだと考える人もいるかもしれません。もはやコードは問題ではなく、モデルと要件に重点を置くべきです。実際、コードの終焉に近づいていると言われています。すぐに、コードは自動的に生成され、手動で記述する必要がなくなります。ビジネスマンは仕様から直接プログラムを生成できるため、プログラマーはまったく役に立たない。

ナンセンスです! コードは要件の詳細を示しているため、コードを削除することは決してできません。あるレベルでは、これらの詳細は無視したり抽象化したりすることはできず、明示的にする必要があります。プログラミングとは、機械が実行できる詳細レベルで要件を指定することです。そして、この仕様がコードです。

言語の抽象化レベルは今後も上昇し続けると予想しています。ドメイン固有言語も今後も増えていくと予想しています。それは良いことだろう。しかし、それでコードは終わりではありません。実際、より高レベルのドメイン固有言語で記述された仕様もコードになります。機械が理解して実行できるように、厳密で正確、標準化され、詳細である必要があります。

コードが最終的には消滅すると考える人は、ルールのない数学を発見することを望む数学者のようなものです。彼らは、いつの日か、私たちが口を開けなくても望むことを実行できる機械を開発できるようになることを望んでいます。機械は私たちを完全に理解できなければなりません。こうして初めて、機械は漠然とした要件を完全に実行可能なプログラムに変換し、ニーズを正確に満たすことができます。

そんなことは絶対に起こりません。人間は、その直感力と創造力をもってしても、顧客の漠然とした感情を満たすシステムをうまく作り出すことはできません。要件仕様の原則から学んだことは、適切に形成された要件はコードと同じくらい形式的であり、そのコードの実行可能なテストとして機能できるということです。

覚えておいてください、コードは実際に私たちが要件を表現するために最終的に使用する言語です。ニーズに近いさまざまな言語を作成できます。要件を解析して正式な構造に整理するのに役立つツールを作成できます。しかし、必要な精度を放棄することはできないので、コードは存続します。

1.2 悪いコード

最近、Kent Beck 著の「Implementation Patterns」という本の序文を読んでいます。彼はこう書いています。「...この本は、良いコードは重要であるという不安定な前提に基づいています...」不安定な前提? 私は反対です! これは、この分野で最も強力で、最も支持され、最も強調されている前提だと思います (そして、Kent もそれを知っていると思います)。良質なコードが重要であることは、その不足が長い間私たちを悩ませてきたことからもわかります。

1980 年代後半、ある企業がキラー アプリを開発し、それが人気を博し、多くの専門家に購入されました。その後、リリースサイクルが長くなり始めました。欠陥は必ずしも修正できるとは限りません。読み込み時間はどんどん長くなり、クラッシュする可能性が高まっています。ある日イライラしてプログラムを閉じ、二度と使わなかったことを今でも覚えています。その後すぐに同社は閉鎖された。

20年後、私はその会社の初期の従業員に会い、何が起こったのか尋ねました。彼の答えは私にさらに大きな恐怖を与えた。結局、彼らは製品の発売を急いでいたため、コードがめちゃくちゃになっていたことが判明しました。機能が増えるにつれて、コードはどんどん悪くなり、最終的にはコードを管理できなくなりました。この会社を破滅させたのは悪いコードでした。

悪いコードに深く悩まされたことはありませんか? ある程度の経験を持つプログラマーであれば、このジレンマに何度も遭遇したことがあるはずです。これには「ウェーディング」という言葉があります。私たちはコードの海を渡ります。私たちは、茂みが生い茂り、隠れた滝がある沼地を歩きました。私たちは、何が起こっているのかを解明する手がかりを求めて、必死に脱出方法を見つけようとしましたが、目に映るのはますます生気のないコードばかりでした。

確かに、あなたは悪いコードに悩まされたことがあるでしょう。では、なぜ悪いコードを書くのでしょうか?

早く終わらせたいですか？急いでいますか？おそらくそうです。良い仕事をするには時間が足りないと感じるかもしれません。コードの整理に時間を費やしたら上司に怒られてしまうかもしれません。おそらく、あなたはそのプロセスに疲れていて、すぐに終わらせたいと思っているだけなのでしょう。おそらく、自分がやろうと約束した他の事柄を振り返ってみると、次のタスクに進むためには、今やっていることを終わらせる必要があることに気づくでしょう。私たちは皆これをやったことがあります。

私たちは皆、自分たちが引き起こした混乱を一目見て、それを忘れて次の日に進むことを決意しました。私たちは皆、自分たちのひどいプログラムが機能するのを見て、機能するひどいプログラムでも何もしないよりはましだと結論付けました。いつかまた掃除を再開するとみんな言っていました。もちろん、当時は「後では決して起こらない」というルブランの法則については聞いたことがありませんでした。

1.3 混乱のコスト

2、3 年以上プログラミングを続けていると、誰かの書いた悪いコードにつまづいたことがあるかもしれません。プログラミングを 2、3 年以上続けていると、このようなコードに悩まされることがあるかもしれません。進捗の遅れは深刻となるでしょう。チームによっては、プロジェクトの開始時に急速に進歩するものの、その後 1 ～ 2 年は進歩が鈍化するケースがあります。コードを変更するたびに、他の 2 か所または 3 か所に影響が及びます。些細な変更は一切ありません。コードを追加または変更するたびに、棒の山を追跡して、さらに棒を投げ入れる必要があります。混乱はどんどん大きくなり、もはや整理することができなくなり、ついには私たちには何もできなくなってしまいました。

混乱が増すにつれて、チームの生産性は低下し続け、ゼロに近づきます。生産性が低下した場合、経営陣ができることはただ一つ、生産性の向上を期待してプロジェクトに人員を追加することだけです。しかし、新参者はシステムの設計に精通していません。どのような変更が設計意図に沿っているのか、またどのような変更が設計意図に反しているのかを判断できません。さらに、彼らとチームの他のメンバーは、生産性を高めるために多大なプレッシャーにさらされています。そのため、さらなる混乱が生じ、生産性はゼロに向かってどんどん低下していきます。

1.3.1 ゴージャスな新デザイン

最終的に、開発チームは反乱を起こし、経営陣に対して、この不快なコードベースでの開発はこれ以上できないと伝えました。彼らは全く新しいデザインを要求しました。経営陣は完全な再起動にリソースを投入することに消極的でしたが、生産性がひどく低いことは否定できませんでした。彼らは開発者の要求に同意するしかなく、見た目が美しい豪華な新しいデザインを作ることを許可しました。

そこで新たな軍隊が結成されました。このチームは白紙の状態なので、誰もが参加したがります。彼らは最初からやり直して、本当に美しいものを思いつくことができるでしょう。しかし、選ばれるのは最も優秀で聡明な人だけです。残りのスタッフは引き続き既存のシステムを維持します。

現在、2つのチームが競争しています。新しいチームは、古いシステムのすべての機能を実行できる新しいシステムを構築する必要があります。さらに、レガシー システムへの継続的な変更にも対応します。新しいシステムが古いシステムと競争できるほど強力になるまで、経営陣は古いシステムを置き換えません。

コンテストは非常に長時間続く可能性があります。私はそれが10年も続くのを見てきました。それが完成する頃には、新チームの古いメンバーはとっくにいなくなっており、既存のメンバーは、このシステムが非常に悪いため、新しいシステムを設計するよう要求しました。

私が話していることのほんの一部でも経験したことがあるなら、時間をかけてコードをクリーンな状態に保つことは、効率の問題だけではなく、生き残るための問題でもあることが分かるでしょう。

1.3.2 態度

数時間で済むはずの作業に数週間もかかってしまうほどの深刻な混乱に遭遇したことはありませんか? 1 行の変更が何百ものモジュールに影響する状況を見たことがありますか? これは非常に頻繁に起こります。

なぜこのようなことが起こるのでしょうか? 良いコードがなぜこんなに早く悪いコードに変質してしまうのでしょうか? 理由はたくさんあります。要件の変更により当初の設計から逸脱してしまうことに不満を抱いています。厳しいスケジュールのせいで仕事が終わらないのは残念です。私たちは愚かなマネージャー、要求の多いユーザー、役に立たないマーケティング、そして携帯電話の消毒剤を非難します。しかし、親愛なるディルバート、私たちは自分自身を責めるべきなのです。私たちはとてもプロフェッショナルではありませんでした。

それはあまり聞き心地の良いものではありません。どうしてそれが彼ら自身のせいになるのでしょうか? 需要の問題ではなかったのでしょうか? スケジュールの問題ではなかったのでしょうか? 愚かなマネージャーと役に立たないマーケティング戦術の問題ではなかったのでしょうか? 彼らに責任があるべきではないのでしょうか?

いいえ。マネージャーやマーケティング担当者は、約束やコミットメントをする前に私たちに意見を求めます。たとえ彼らが求めなくても、私たちは自分の考えを共有することをためらうべきではありません。ユーザーは、要件がシステムに実装されていることを確認するために当社を頼ります。プロジェクトマネージャーは私たちがスケジュールを厳守することを期待しています。私たちはプロジェクトの計画に関与しており、その失敗に対して大きな責任を負っています。特に、失敗が不良コードに関連している場合はそうです。

「ちょっと待って！」とあなたは言います。 「上司の言うことを聞かなかったら、解雇されるよ。」おそらくそうではない。ほとんどのマネージャーは、たとえそれが気に入らないように見えても、真実を知りたいと思っています。ほとんどのマネージャーは、スケジュールに常にこだわりがあっても、優れたコードを望んでいます。彼らはスケジュールとニーズを守るために戦うだろう。それが彼らがすべきことだ。あなたも同じ情熱を持ってコードを守るべきです。

もっとわかりやすく言うと、もしあなたが医者で、患者が時間がかかりすぎるから手術の前に手を洗わないでほしいと頼んだら、あなたはそうしますか？ 最終決定権は患者にあるべきですが、医者は絶対に従わないべきです。なぜでしょうか? それは、医師は患者よりも病気や感染のリスクをよく理解しているからです。医師が患者の要求に従うのは、非専門的な態度（犯罪であることは言うまでもありません）です。

同様に、混乱のリスクを理解していないマネージャーの要望にプログラマーが従うのは、プロフェッショナルとしてふさわしくありません。

1.3.3 パズル

プログラマーは根本的な価値のパズルに直面します。数年の経験を持つ開発者は、以前の混乱が彼らの進歩を妨げたことを知っています。しかし、締め切りのプレッシャーに悩まされた開発者たちは、混乱を生むしか選択肢がなかった。つまり、彼らは自分自身をより速くするために時間をかけなかったのです。

真のプロフェッショナルは、パズルの 2 番目の部分が間違っていることを理解しています。混乱を招いても期限を守ることはできません。混乱はすぐにあなたの作業を遅らせ、締め切りに間に合わなくなってしまいます。期限を守る唯一の方法、つまり期限を早く守る唯一の方法は、常にコードをできるだけクリーンな状態に保つことです。

1.3.4 クリーンコードの芸術

乱雑なコードが諸悪の根源であると信じ、物事を迅速に行う唯一の方法はコードをクリーンに保つことだと認めると仮定すると、あなたは自分自身に「どうすればクリーンなコードを書くことができるか」と問いかけているに違いありません。しかし、コードにおけるクリーンさの意味を理解していなければ、クリーンなコードを書こうとしても意味がありません。

残念なことに、きれいなコードを書くことは絵を描くことによく似ています。ほとんどの人は絵画が良いか悪いか知っています。しかし、良いものと悪いものを区別できるからといって、絵画を理解しているということにはなりません。クリーンなコードとダーティなコードを区別できるからといって、クリーンなコードを書けるというわけではありません。

クリーンなコードを書くには、多くの小さなコツに従い、苦労して得たクリーンな感覚を実装する必要があります。この「コードセンス」が鍵となります。生まれつきそういう性質の人もいます。それを手に入れるために一生懸命働かなければならない人もいます。これにより、コードの長所と短所を把握できるだけでなく、ルールの力を活用して短所を長所に変える戦略も得られます。

「コードセンス」が欠けているプログラマーは、混沌を混沌としか見ず、どこから始めればよいのか分かりません。 「コードセンス」を持つプログラマーは、混乱の中から他の可能性や変化を見出すことができます。 「Code Sense」は、プログラマーが最適なソリューションを選択するのを支援し、アクション プランを開発および変更し、指示に従うようにガイドします。

つまり、きれいなコードを書くプログラマーは、一連の変換を通じて白紙の状態からエレガントなコードのシステムに変換できるアーティストのようなものです。

1.3.5 クリーンコードとは何ですか?

プログラマーの数だけ定義が存在します。そこで、私は非常に有名で経験豊富なプログラマーだけに質問しました。

Bjarne Stroustrup は、C++ 言語の発明者であり、C++ プログラミング言語 (中国語訳: C++ プログラミング言語) の著者です。

私はエレガントで効率的なコードが好きです。コード ロジックは、欠陥が隠れにくいようにわかりやすくする必要があり、依存関係を最小限に抑えて保守しやすくし、階層化戦略に基づいてエラー処理コードを改善し、パフォーマンスを最適化して、他の人が無秩序な最適化を行って混乱を招かないようにする必要があります。クリーンなコードは 1 つのことだけをうまく行います。

ビャルネは「エレガント」という言葉を使いました。よく言った！私の MacBook の辞書には、次のような定義があります。「見た目や態度における心地よい優雅さと上品さ、心地よい洗練さとシンプルさ」。 「喜び」という言葉が強調されていることに注目してください。 Bjarne は、どうやらクリーンなコードは読むのが楽しいと考えているようです。このようなコードを読むと、美しく作られたオルゴールやよくデザインされた車を見るような気分になり、笑顔になります。

Bjarne 氏は効率性についても 2 回言及しました。 C++ の発明者からのこの発言は驚くべきことではないかもしれませんが、単に速度の追求ではないと思います。無駄な計算サイクルは見苦しく、不快です。 Bjarne が醜い結果をどのように説明しているかに注目してください。彼は「誘惑する」という言葉を使いました。これらの言葉はまさに真実です。悪いコードは混乱を招きます。誰かが悪いコードを変更すると、状況はさらに悪化する傾向があります。

実践的なデイブ・トーマスとアンディ・ハントは状況を別の観点から見ています。彼らは割れ窓理論について言及した。建物は窓が割れていて、まるで放置されているように見えました。だから誰も気にしなかった。彼らは窓が割れ続けるのを許した。結局、彼も破壊行為に加わり、外壁に落書きをしたり、ゴミを山積みにしたりした。割れた窓が建物の崩壊につながった。

Bjarne 氏はエラー処理コードの改善についても言及しました。もっと深く言えば、細部に注意を払うことを意味します。適切に記述されていないエラー処理コードは、プログラマーが細部に注意を払っていないことの一例にすぎません。メモリ リークや競合状態コードもあります。命名にも一貫性がありません。その結果、細部へのこだわりを強調したクリーンなコードが生まれます。

Bjarne は最後に「クリーンなコードは 1 つのことをうまく実行します」と述べています。言うまでもなく、ソフトウェア設計の多くの原則は、最終的にはこの警告に集約されます。多くの人が同様のコメントをしています。悪いコードは多くのことをやろうとしすぎていて、意図が混乱し、目的が不明確になっています。クリーンなコードは集中することを目指します。各関数、各クラス、各モジュールは、周囲の詳細によって中断されたり汚染されたりすることなく、1 つのことに完全に集中しています。

Grady Booch 氏、『Object Oriented Analysis and Design with Applications』(中国語訳) の著者。

クリーンなコードはシンプルでわかりやすいものです。きれいなコードは美しい散文のようなものです。クリーンなコードは設計者の意図を隠すことはなく、クリーンな抽象化とわかりやすい制御ステートメントでいっぱいです。

Grady 氏の見解は Bjarne 氏の見解と似ていますが、彼はそれを読みやすさの観点から定義しています。きれいなコードは美しい散文のようなものだという考え方が特に気に入っています。あなたが読んだ素晴らしい本について考えてみましょう。これらの言葉があなたの心の中でどのようにイメージを形成するかを思い出してください。まるで映画を見ているようですね。それだけではありません。登場人物も見え、声も聞こえ、喜び、悲しみ、怒り、幸せも体験します。

クリーンなコードを読むことは、『ロード・オブ・ザ・リング』を読むこととは確かに異なります。それでも、類似点はあります。優れた小説と同様に、クリーンなコードは解決する問題の緊張を明確に示す必要があります。緊張を極限まで高め、問題と緊張を明白な解決策で解決し、読者に「なるほど！ こうあるべきだ！」と叫ばせる必要があります。

個人的には、グレイディが「鮮明な抽象化」と呼んでいるものは、言葉の見事な矛盾であると思います。結局のところ、crisp は「concrete」とほぼ同義語です。私の MacBook の辞書では、crisp は「躊躇したり不必要な詳細を述べずに、決断力があり、要点を述べる」と定義されています。 2つの異なる定義があるにもかかわらず、この言葉には強力なメッセージが含まれています。コードは憶測を招くものではなく、事実を伝えるものであるべきです。必要なものだけを含める必要があります。読者は私たちの決断力を感じるはずです。

OTI の創設者であり、Eclipse 戦略のゴッドファーザーである「ボス」デイブ・トーマス。

クリーンなコードは、作成者以外の開発者が読み取り、追加できるものでなければなりません。ユニットテストと受け入れテストが必要です。意味のある名前を使用します。何かを行うための方法は 1 つだけであり、複数の方法は提供されません。依存関係はできる限り少なくし、クリーンで最小限の API を明確に定義して提供する必要があります。言語が異なると、コード自体では必要な情報がすべて明確に表現できない可能性があるため、コードは文字通りの意味を通じて意味を伝える必要があります。

Dave は読みやすさに関しては Grady に同意しますが、重要な違いが 1 つあります。 Dave は、クリーンなコードにより他の人がコードに追加しやすくなると主張しています。これは明白なことのように思えるかもしれませんが、強調しすぎることはありません。結局のところ、読みやすいコードと変更しやすいコードには違いがあります。

デイブはテストよりも清潔さを重視しています。10 年前なら、これは目を見張るものだったでしょう。しかし、テスト駆動開発は業界に大きな影響を与え、基本的な手順の 1 つになりました。デイブは正しい。テストのないコードはクリーンではありません。どれほどエレガントで、どれほど読みやすく、理解しやすいものであっても、テストされていなければ、その不潔さは明らかです。

デイブは「できるだけ少なく」という言葉を2回使いました。明らかに、彼は小さなコードの塊を主張しています。実際、ソフトウェアが存在する限り、人々はこれを言い続けてきました。小さければ小さいほど良いです。

Dave 氏はまた、コードは文字通りその意味を伝えるべきだとも述べました。この見解は、Knuth の「リテラルプログラミング」に由来しています。結論としては、コードは人間が読める形式で記述する必要があるということです。

Michael Feathers 氏、『Working Effectively with Legacy Code』(中国語訳: The Art of Modifying Code) の著者。

私が気づいたクリーン コードの特徴をすべて挙げることもできますが、その中でも特に基本的な特徴が 1 つあります。きれいなコードは、常に誰かが気にかけて書いたように見えます。改善の余地はほとんどありません。コードの作成者はあらゆることを考えており、それを改善しようとすると、必ず出発点に戻って、誰かが残したコード、つまり完全にコミットした誰かが残したコードを賞賛することになります。

一言で言えば、ケアです。これがこの本の内容です。おそらく、サブタイトルは「コードを気にかける方法」にすべきでしょう。

マイケルはまさに的を射ていた。クリーンコードとは、作成者が細心の注意を払って作成したコードです。誰かが時間をかけて、それをシンプルかつ整理された状態に保ちました。彼らは細部にまで適切な注意を払いました。彼らは気にかけていた。

Ron Jeffries 氏は、『Extreme Programming Installed』および『Extreme Programming Adventures in C#』の著者です。

ロンは戦略空軍で Fortran プログラムの作成から始め、それ以来、あらゆる言語であらゆるマシン上でコードを書いてきました。彼の発言は熟考する価値がある。

近年、私はベイカーのシンプルなコーディング規則を研究し始め、ほぼ理解しました。重要度順に並べたシンプルなコード:

すべてのテストに合格する。

コードの重複なし。

すべての設計コンセプトをシステムに反映します。

クラス、メソッド、関数などのエンティティをできるだけ少なくします。

上記のすべての中で、私が最も懸念しているのはコードの重複です。同じコードが何度も現れる場合、それは特定のアイデアがコードにうまく反映されていないことを意味します。それが何なのかを見つけ出し、それをより明確に表現しようとします。

私にとって、意味のある名前を付けることは表現力を示す方法であり、名前を決める前に何度も修正することがよくあります。 Eclipse のような最新のコーディング ツールでは、名前の変更は非常に簡単なので、気になりません。しかし、表現力は名前にのみ反映されるわけではありません。オブジェクトまたはメソッドが過剰な処理を実行しようとしていないかどうかも確認します。オブジェクトの機能が多すぎる場合は、2 つ以上のオブジェクトに分割するのが最適です。メソッドが多すぎる場合は、常に「メソッドの抽出」を使用してメソッドを再構築し、メソッド自体の機能を明確に説明できるメソッドと、これらの機能を実現する方法を説明する他のいくつかのメソッドを取得します。

重複を排除し、表現力を高めることは、クリーンなコードについて私が最も学んだことであり、この 2 つのことを念頭に置くことで、ダーティなコードを改善するときに大きな違いを生み出すことができます。しかし、私がよく注目するもう一つのルールは、説明するのが簡単ではありません。

長年にわたり、私はすべてのプログラムが非常に類似した要素で構成されていることに気づきました。たとえば、「コレクション内の何かを見つける」などです。従業員レコードのデータベース、名前と値のペアのハッシュ テーブル、または何らかの項目の配列のいずれであっても、コレクション内の特定の項目を見つけたいと思うことがあります。このような場合、私は通常、実装をより抽象的なメソッドまたはクラスにカプセル化します。これを行うと多くの利点があります。

この機能を実装するには、ハッシュ テーブルなどの単純なものを使用することから始めることができます。検索関数への参照は小さな抽象化を指しているので、必要に応じて実装を変更できます。これにより、将来の変更の余地を残しながら、迅速に前進することができます。

さらに、コレクションの抽象化により、実際に何が起こっているかに注意を払い、本当に必要なのは単純な検索機能だけである場合に、任意のコレクション動作を実装しないようにすることがよく思い出されます。

コードの重複を減らし、表現力を向上させ、シンプルな抽象化を早期に構築します。これが私がきれいなコードを書く方法です。

ロンは本の全体の内容をわずか数段落で要約しています。コードを繰り返さず、1 つのことだけを行い、表現力を高め、抽象化を小さく保ちます。そこにあるものはすべてここにあります。

Ward Cunningham は、Wiki の発明者であり、eXtreme Programming の創始者の 1 人であり、Smalltalk 言語とオブジェクト指向プログラミングの思想的リーダーです。コードを気にするすべての人にとってのゴッドファーザー。

すべてのルーチンが満足のいくものであると感じられるなら、それはクリーンなコードです。コードによって、プログラミング言語がその問題を解決するために設計されたように見える場合、それは美しいコードと呼ぶことができます。

この発言はまさにウォードらしい。聞いた後にうなずき、その後も聞き続けることを教えてくれます。それはとても合理的でシンプルで、決して深遠であるかのように見せかけるものではありません。おそらく、これはまさにあなたが考えていることだと思われるでしょう。もっと近づいて見てください。

「…まさに私が望んでいたものです。」本当にピンとくるモジュールを最後に見たのはいつですか? モジュールはたいてい複雑ですよね? ルールはないのですか? システム全体に散らばっているスレッドを把握し、読んでいるモジュールに織り込むのに苦労したことはありませんか? コードを読んで、Ward の言ったことにうなずくかのようにうなずいたのはいつですか?

Ward 氏は、クリーンなコードに驚かされないことを望んでいます。あまり努力する必要はありません。そのコードはまさにあなたが望んでいるものです。明確でシンプル、そして強力です。各モジュールは次のモジュールの準備を行います。各モジュールでは、次のモジュールの内容が示されます。きちんとしたプログラムは、とても優れているので、気づかないほどです。デザイナーはそれを他のデザインと同じようにシンプルにしました。

ワードが美について語っていることについてはどうでしょうか? 私たちは皆、言語が本来解決すべき問題を解決するように設計されていないというジレンマに直面したことがあります。しかし、ウォードのコメントにより、ボールは私たちのコートに戻されました。彼は、美しいコードにより、プログラミング言語がその問題を解決するために特別に作成されたように見えると言いました。つまり、言語をシンプルにする責任は私たちにあります。注意してください、言語は頑固です。言語をシンプルに見せるのはプログラマーです。

1.8 要約

美術書は、読んだら必ずアーティストになれるという保証はなく、他のアーティストが使用するツール、テクニック、思考プロセスについて教えてくれるだけです。この本はあなたが優れたプログラマーになれることを保証するものでもありません。 「コードの意味」が理解できるかどうかは保証されません。この本でできることは、優秀なプログラマーの思考プロセスや、彼らが使用するヒント、テクニック、ツールを紹介することだけです。

アートブックと同様に、この本にも細部までこだわった内容が満載です。コードはたくさんあります。良いコードもあれば悪いコードもあります。悪いコードがどのように良いコードに変換されるかがわかります。インスピレーション、ルール、ヒントのリストが表示されます。次々と例が出てきます。しかし、最終的な結果はあなた次第です。

元のタイトル: クリーンなアプローチでコードをより明確でシンプル、そして強力にする方法

キーワード: きちんとした、方法、方法、コード、より明確、シンプル、強力、この記事、章の抜粋、抜粋、ウェブマスター、ウェブサイト、ウェブサイトのプロモーション、収益化