アーキテクトのようにコードを書く

コードの作成と記事の作成にはある程度の関連性があり、ロジックと構造が必要であり、できるだけ簡潔にする必要があります。クリエイターのスケジュールとマネージャーのスケジュールは異なると前に述べましたが、コーディングと記事執筆はどちらも邪魔されない孤独な作業です。

同様に、建築家の最終製品が建物であれば、プログラマーやソフトウェア エンジニアの最終製品はソフトウェアです。実際の建設が始まる前に、建築家は建物のあらゆる詳細を設計図に示します。ただ、プログラマーやソフトウェアエンジニアはそんなことはしません。おそらくこれが、家が滅多に倒壊しないのに、ソフトウェアが頻繁にクラッシュする理由なのでしょうか?

ブループリントは、建築家が設計が実現可能であることを確認するのに役立ちます。 「実現可能」とは、単に倒壊しないという意味ではなく、建物が人々に役立つという本来の目的を達成できるという意味でもあります。クライアントや開発者は、設計者のアイデアや何を計画しているのかを理解するために青写真も使用します。

対照的に、多くのプログラマーはコードを書き始める前に大まかなフレームワークさえ持っていません。

ほとんどのプログラマーは、コードを直接生成しないものは無意味だと信じています。思考をそのままコードに変換することはできませんが、全体の枠組みが決まっていない状態で急いでコードを書き始めても意味がありません。プログラマはコードを書き始める前に、そのコードが最終的に何をするのかを十分に理解する必要があります。理解する過程には当然考えることが必要ですが、その思考過程を書き出すのはプログラマにとって非常に時間がかかる作業です。

しかし、漫画家のディック・ギンドンはかつてこう言いました。 書くことは、自分のアイデアがどれほどひどいかを発見する最良の方法です。

ブループリントは、建物のアーキテクチャを理解するのに役立ちます。同様に、コードを書き始める前に、同様の「ブループリント」、つまり「アノテーション」（仕様）も必要です。

「コメント」はコードを直接生成できないため、多くのプログラマによって無視されます。しかし、「注釈」なしで単に書くことは、設計者の図面なしで建設業者に直接戦闘に参加するよう依頼するようなものです。

プログラマとアーキテクトの類似は不合理だという人もいるかもしれない。なぜなら、壁を取り壊して再構築するのは難しいですが、削除したり書き直すのは比較的簡単なので、プログラマは最初にそれを書いて、満足できない場合は変更することができます。

この考えは間違っています。なぜ？ デバッグプロセスにも非常に時間がかかります からです。

また、最近いくつかのプログラムを改良しましたが、このプロセスではプログラムのアーキテクチャ自体を明確に理解する必要があります。プログラム全体の仕組みを理解するのに 1 日近くかかりましたが、コメントがあれば 5 分もかからなかったでしょう。

バグの混入を避けるために、小さな調整によって起こり得る結果を理解する必要があります。コメントがないので、各コードの意味と機能を理解するのに長い時間を費やす必要があります。特に数千行のコードの場合、最初にコードを読むのに非常に時間がかかります。特定の行を変更したい場合は、小さな調整が全体のアーキテクチャとロジックに与える影響を理解しなければなりません。結局、1 週間以上で変更したコードは 180 行だけでしたが、これは数千行あるプログラムとしては非常に小さな変更です。

デバッグはコード作成のほんの一部にすぎません。これらの数千行のコードの多くは、10 年前に私が書いたもので、まだ記憶が残っていますが、コメントがあると、コード全体を理解するだけでなく、コードを修正するプロセスもスムーズになります。最短時間で、フレームワークは変更したい部分を正確に見つけることもできます。

他の人のコードを変更するのはさらに困難です。考え方は人それぞれです。コメントがないと、小さな間違いを修正するだけで通常 2 倍以上の時間を費やす必要があります。

では、「メモ」とは何を意味するのでしょうか？ 「コメント」とは、コードに添付される正式な仕様テキストの一部を指します。ただし、区別する必要があるのは、ツール ルームを構築するだけの場合、超高層ビルの設計図の完全なセットは必要ないことです。同様に、小規模なアルゴリズムの場合、各コードに注釈を付ける必要はありません。

最近書かなければならないプログラムは高層ビルというより「バンガロー」に似ています。いくつかの非常に単純なアルゴリズムについては、通常 1 つか 2 つのコメントのみを挿入します。私には、私や他の人が私のプログラムを理解するのに役立つ非常に単純なルールがあります。コメントは、誰もが私のコードを理解して使用できるように、できるだけ効果的である必要があります。

コードの特定の行が何をするのかがわかれば、それを記述するプロセスは実際には非常にシンプルで簡単です。型破りなアルゴリズムの使用を必要とするプログラムもいくつかあります。この時点で、アルゴリズムの主なアイデアを書き留めて、その実現可能性をテストし、より効率的にデバッグできるようにします。

特に重要なコード部分を除いて、私のコメントは概して非公式です。過去 10 年間で、正確かつ正式なメモを書くことを求められた機会は数回しかありませんでした。しかし、非常に複雑なシステムでは、アノテーションの重要性は自明のことです。複雑なシステムを構築するときに、時間をかけて適切なコメントを書けるエンジニアはほとんどいません。コメントの書き方を教える学校もありますが、ほとんどの場合、良いコードの書き方を教えてくれます。それには練習が必要で、バンガローの設計図を描いたことがないのに、超高層ビルの設計図を描くのは難しいです。

良いコメントを書くための単純なルールはありませんが、コードを説明するためにコードを使用することは避けるべきです。人々が理解できない 2 つのことを使用して、一方を使用してもう一方を説明することはできないのと同じです。建築家はレンガでどんな家を建てたいかを直接伝えることはできません。

複雑なシステムを理解する最良の方法は、そのコアを単純な概念 に抽象化することです。中学校数学のいくつかの基本概念は、適切なコメントを書くのに役立ちます。たとえば、いくつかのセット、方程式、簡単なロジックを使用してコードを説明できます。一部の複雑なアルゴリズムについては、数学では見られない概念を導入して説明することもできます。一般に、注釈が抽象的な数学の基本概念から離れるほど、理解するのが難しくなります。
考えたからといって間違いを犯さないという保証はありませんが、考えなければ間違いは避けられません。コメントはエラーを最小限に抑えるのに役立ち、またエラー修正の効率を高めて時間を節約することもできます。