優秀なプログラマーはデータ構造とその関係性に気を配る

Engineer’s Codex は、実際のソフトウェア エンジニアリングに関する出版物です。

最近、私が最近取り組んでいる問題を簡潔に説明した Linus Torvalds (Linux と Git の作成者) の引用文に出会いました。

「下手なプログラマーはコードを気にします。優秀なプログラマーはデータ構造とその関係を気にします。」

上記の引用の直前に、Linus はこう言っています。

git は実際にはシンプルな設計で、安定しており、十分に文書化されたデータ構造を備えています。実際、私はデータを中心にコードを設計することを強く支持しており、その逆は推奨しません。これが git がかなり成功している理由の 1 つだと思います。 […] 実際、私は、下手なプログラマーと優れたプログラマーの違いは、コードを重視するかデータ構造を重視するかにあると主張します。

優れたデータ構造により、コードの設計と保守が容易になります。ソフトウェアの信頼性が高まり、システムが理解しやすくなり、コードが読みやすくなります。ソフトウェアを設計する際、アプリケーション ロジックは多くの場合、データ モデルに従います。データ モデルを後回しにすると、後で作業が増えます。逆もまた真なりで、よく考えられたデータ モデルがあると、後で複雑なシステムへの移行や構築が容易になります。

この引用文を読んだとき、私は実際に過去にこのような例が無数にあったことに気付きました。私はかつて、複雑なアルゴリズムを最適化するのにかなりの時間を費やしたプロジェクトに携わりましたが、データを再構築することで、一連の問題をすべて排除できることに気付きました。500 行の関数を 50 行の関数と適切に設計されたデータ構造に置き換えました。新しいコードは高速になっただけでなく、理解しやすく、保守もはるかに簡単になりました。(もちろん、その後、問題は「スタックの下」に移り、既存のデータの再構築に労力の大部分が費やされました。)

ここで関連するもう一つの引用は Unixプログラミングの芸術:

表現のルール: 知識をデータに組み込むことで、プログラム ロジックが単純かつ堅牢になります。

最も単純な手続き型ロジックでさえ人間が検証するのは困難ですが、非常に複雑なデータ構造はモデル化して推論するのがかなり簡単です。これを確認するには、たとえば 50 ノードのポインタ ツリーの図の表現力と説明力を、50 行のプログラムのフローチャートと比較してください。または、変換テーブルを表す配列初期化子と同等の switch ステートメントを比較してください。透明性と明瞭性の違いは劇的です。Rob Pike の Rule 5 を参照してください。

データはプログラム ロジックよりも扱いやすいです。したがって、データ構造の複雑さとコードの複雑さのどちらかを選択する必要がある場合は、前者を選択します。さらに、設計を進化させる際には、コードからデータへ複雑さを移行する方法を積極的に模索する必要があります。

この洞察は Unix コミュニティが最初に生み出したものではありません。しかし、多くの Unix コードにその影響が見られます。特に、C 言語のポインター操作機能は、カーネルから上位のコーディングのすべてのレベルで動的に変更される参照構造の使用を促進しました。このような構造での単純なポインター追跡は、他の言語での実装ではより複雑な手順で実現しなければならないタスクを頻繁に実行します。

の ここで実行可能なヒントは、データから始めることです。 インターフェースやデータベースの型をより厳密にすることで、コードの複雑さを軽減するようにしてください。事前にデータ構造についてじっくり考える時間を取ってください。

それは、 コードは重要ではない明らかに、すべてが重要ですが、コード関連の詳細を深く掘り下げる前に、データがどのように流れ、さまざまなコンポーネントがどのように相互作用するかについて、強力な高レベルのアプローチを用意しておくと便利です。

それが、 シニアエンジニア（L5） 要件 (少なくとも FAANG の場合) には、通常、より複雑なシステムのための高レベルの設計ドキュメントの作成が含まれます (これには、チーム計画の推進と、中規模から大規模の機能のための適切なロードマップの構築が含まれます)。

から L5 が一般的に持つ高いレベルの影響力について、ここで素晴らしい記事を書きました:

から シニアエンジニアになる方法についての素晴らしい記事も書いています。