優れたプログラマーに関するトーバルズの言葉
偶然にも、Linus Torvaldsによる次の引用に遭遇しました。
「悪いプログラマーはコードを心配します。良いプログラマーはデータ構造とそれらの関係を心配します。」
私は過去数日間それについて考えました、そして私はまだ混乱しています（それはおそらく良い兆候ではありません）、それゆえ私は以下について議論したかったです：
- これのどのような解釈が可能/意味がありますか？
- そこから何を適用/学習できますか？
Torvaldsがその直前に言ったことを検討すると役立つ場合があります。
gitは実際にはシンプルな設計で、安定しており、十分に文書化されたデータ構造を備えています。実際、私はデータを中心にコードを設計するのではなく、データを中心にコードを設計することを大いに支持しています。それがgitがかなり成功した理由の1つだと思います[…]実際、違いを主張します悪いプログラマーと良いプログラマーの間の違いは、彼が自分のコードと彼のデータ構造のどちらをより重要と考えるかです。
彼が言っていることは、優れたデータ構造はコードの設計と保守を非常に簡単にするのに対し、最高のコードは不十分なデータ構造を補うことができないということです。
Gitの例について不思議に思っている場合、多くのバージョン管理システムは、新機能をサポートするために、比較的定期的にデータ形式を変更しています。新しい機能を取得するためにアップグレードする場合、データベースを変換するために、ある種のツールを実行しなければならないことがよくあります。
たとえば、DVCSが最初に人気になったとき、多くの人々は、分散型モデルがマージを一元化されたバージョン管理よりもはるかにきれいにしたことを理解できませんでした。分散データ構造hadを除いて、答えはまったく何もありません。それ以来、集中型マージアルゴリズムは追いついてきたと思いますが、古いデータ構造では使用できるアルゴリズムの種類が制限され、新しいデータ構造では既存のコードの多くが壊れたため、かなり時間がかかりました。
対照的に、gitの機能が急増しているにもかかわらず、その基礎となるデータ構造はほとんど変更されていません。最初にデータ構造を心配すれば、コードは当然よりクリーンになります。
コードは、アルゴリズムとデータ構造をexpressする方法にすぎません。
この引用は、トーバルズがLinuxの作成者であることの強みである "The Art of Unix Programming"のルールの1つに非常に精通しています。本はオンラインにあります ここ
本から、トーバルズが言っていることを説明する以下の引用です。
表現の規則：プログラムロジックが愚かで堅牢になるように、知識をデータに組み込みます。
最も単純な手続き型ロジックでさえ、人間が確認するのは困難ですが、非常に複雑なデータ構造は、モデル化して推論するのがかなり簡単です。これを確認するには、50ノードポインターツリーの（たとえば）図の表現力と説明力を、50行プログラムのフローチャートと比較してください。または、変換テーブルを表す配列初期化子を同等のswitchステートメントと比較します。透明度と透明度の違いは劇的です。ロブ・パイクのルール5を参照してください。
データはプログラムロジックより扱いやすいです。したがって、データ構造の複雑さとコードの複雑さのどちらかを選択する場合は、前者を選択してください。詳細：設計の進化において、複雑さをコードからデータにシフトする方法を積極的に模索する必要があります。
Unixコミュニティはこの洞察を生み出しませんでしたが、多くのUnixコードがその影響を示しています。特に、ポインタを操作するC言語の機能は、カーネルから上向きのコーディングのすべてのレベルで動的に変更された参照構造の使用を奨励しています。そのような構造の単純なポインタ追跡は、他の言語での実装が代わりに、より複雑な手順で具体化しなければならない義務を頻繁に行います。
コードは簡単で、コードの背後にあるロジックが複雑です。
コードについて心配している場合は、その基本をまだ理解しておらず、複合システム（データ構造とその関係）で失われている可能性があります。
Morons 'answer を少し拡張すると、アイデアは、コードの詳細（構文、そしてそれほどではないものの、構造/レイアウト）を理解することは、それを実行できるツールを構築するのに十分簡単であるということです。 。コンパイラーは、コードを機能するプログラム/ライブラリーにするために、コードについて知る必要があるすべてのものを理解できます。しかし、コンパイラが実際にプログラマが行う問題を解決することはできません。
引数をさらに一歩進めて「コードを生成するプログラムはあります」と言うこともできますが、生成されるコードはほとんど常に手作業で作成されるある種の入力に基づいています。
したがって、コードを取得するためにどのようなルートをとっても、ツールを介してコードを生成する何らかの構成またはその他の入力を介して、または最初からコードを作成する場合、問題になるのはコードではありません。重要なのは、そのコードに到達するために必要なすべての要素を批判的に考えることです。 Linusの世界では、それは主にデータ構造と関係ですが、他のドメインでは他の部分である場合があります。しかし、この文脈では、Linusは「コードを書くことができるかどうかは気にしない。私が扱っている問題を解決するものを理解できるように気にする」と言っているだけです。
Linusはこれを意味します：
フローチャート[コード]を見せて、テーブル[スキーマ]を隠してください。テーブル[スキーマ]を見せてください。通常はフローチャート[コード]は必要ありません。
-フレッドブルックス、「The Mythical Man Month」、9章。
全体的な高レベルの設計（データ構造とその関係）は、実装の詳細（コード）よりもはるかに重要であると彼は言っていると思います。彼は、システムの詳細にのみ焦点を当てることができるプログラマーよりも、システムを設計できるプログラマーを高く評価していると思います。
どちらも重要ですが、全体像を把握して詳細に問題がある方が一般的には逆の方法よりもはるかに優れていることに同意します。これは、私が表現しようとしていたものと密接に関連しています 大きな関数を小さな関数に分割する 。
ええと、私は完全に同意することはできません。あなたはそれすべてを心配しなければならないからです。さらに言えば、プログラミングについて私が気に入っている点の1つは、さまざまなレベルの抽象化とサイズを切り替えて、ナノ秒のことから数か月のことを考えたり、戻ったりすることです。
ただし、高いものほど重要です。
不適切な動作を引き起こす問題の2、3行に欠陥がある場合、おそらく修正するのはそれほど難しくありません。パフォーマンスが低下している場合は、おそらく問題になりません。
サブシステムのデータ構造の選択に欠陥があり、それが不適切な動作を引き起こす場合、それははるかに大きな問題であり、修正が困難です。それがパフォーマンスの低下を引き起こしている場合、それは非常に深刻であるか、または耐えられる場合でも、ライバルのアプローチよりもかなり劣っています。
アプリケーションの最も重要なデータ構造間の関係に欠陥があり、それが不適切な動作を引き起こす場合、目の前で大規模な再設計を行いました。パフォーマンスが低下している場合は、非常に悪い可能性があるため、動作に問題があった場合はほとんど問題ありません。
およびそれは、それらの低レベルの問題を見つけることを困難にするものになります（低レベルのバグを修正することは通常簡単で、難しい場合があることを見つけることです）。
低レベルのものisは重要であり、その残りの重要性はしばしば真剣に控えめに表現されますが、大きなものに比べると見劣りします。
データがどのように流れるかを知ることはすべて重要です。フローを知るには、適切なデータ構造を設計する必要があります。
20年前に戻ると、これは、Smalltalk、C++、またはJavaを使用したオブジェクト指向アプローチの大きなセールスポイントの1つでした。大きなピッチは、少なくともC++でそれが最初に学んだことなので、クラスとメソッドを設計することでした。
Linusは間違いなく広い意味で話していましたが、設計が不十分なデータ構造は、コードの追加の再作業を必要とすることが多く、それが他の問題につながることもあります。
コードを知っている人は「木」を見ます。しかし、データ構造を理解している人には「森」が見えます。したがって、優れたプログラマーは、コードよりもデータ構造に重点を置きます。
そこから何を適用/学習できますか？
もしそうなら、ここ数週間の私の経験。上記の議論は私の質問への答えを明確にしました：「私は何を学びましたか？」
私はコードを書き直し、何度も見た結果を振り返り、「構造、構造...」と言って、このような劇的な違いがありました。今では、すべての違いを生み出したのはData構造でした。そして、私はallを意味します。
私の元の配信をテストすると、ビジネスアナリストはそれが機能していないと私に言った。 「30日追加」と言いましたが、「1か月追加する」という意味でした（結果の日付のdayは変わりません）。個別の年、月、日を追加します。たとえば、18か月で540日ではありません。
修正：データ構造で、単一の整数を複数の整数を含むクラスに置き換え、その構造の変更は1つのメソッドに限定されていました。実際の日付算術ステートメントを変更します-それらの2つすべて。
ペイオフ
- 新しい実装にはより多くの機能がありましたが、アルゴリズムコードは短く、明らかに単純でした。
コードの動作/結果の修正：
- アルゴリズムではなく、データ構造を変更しました。
- コードのどこにも制御ロジックはありませんでした。
- APIは変更されていません。
- データ構造ファクトリクラスはまったく変更されていません。
Linusにはこれ以上同意できません。データに焦点を合わせると、特定の問題に対するシンプルで柔軟なソリューションを大幅に抽出するのに役立ちます。 Git自体は実証済みの例です。長年の開発でサポートされている非常に多くの機能を提供し、コアデータ構造はほとんど変更されていません。それは魔法です！ --2c
100万冊のランダムで素晴らしい本を備えた美しく作られた図書館にいる司書たちの非常に賢いチームを想像したいのですが、それはかなり愚かなことでしょう。
データベーススキーマに新しい列やテーブルを追加するよりも、新しい関数を書いたり、既存の関数を更新したりすることがよくあります。これはおそらく、適切に設計されたすべてのシステムに当てはまります。コードを変更する必要があるたびにスキーマを変更する必要がある場合、非常に悪い開発者であるという明確な兆候があります。
コード品質インジケータ= [コード変更]/[データベーススキーマ変更]
「あなたのフローチャートを見せて、テーブルを隠してください。そうすれば、私は神秘化され続けます。テーブルを見せてください。そうすれば、通常、フローチャートは必要なくなります。それらは明白です。」 （フレッド・ブルックス）
私はこれが多くの領域であることを見てきました。
ビジネス分析について考えてみましょう... Colgateのような消費者製品会社でマーケティングをサポートするための最良の方法を分析しているとしましょう。凝ったウィンドウ、または最新のテクノロジから始める場合、最初にビジネスのデータニーズを検討し、次にプレゼンテーションについて心配するほど、ビジネスを支援することはできません。データモデルはプレゼンテーションソフトウェアよりも長持ちします。
Webページの作成を検討してください。最初に何を表示したいか（HTML）について考え、その後スタイル（CSS）とスクリプト（ツールを選択する）について心配することをお勧めします。
これは、コーディングも重要ではないということではありません。最終的に必要なものを取得するには、プログラミングのスキルが必要です。データが基盤であるということです。貧弱なデータモデルは、過度に複雑な、または考えられていないビジネスモデルを反映しています。