5有名なプログラミングの引用、説明

プログラマであることは、一定の学習の生活のために自分自身をサインアップすることです。 新しい機能、新しい言語、新しいツール、新しいフレームワークの泉は、決して噴出を止めることはありません。 しかし、コンピュータサイエンスは驚くほど伝統的な分野でもあり、時の試練を経た原則に基づいています。 オブジェクト指向プログラミング、最新のハードウェア、人工知能を追加しました。 しかし、これらの変化にもかかわらず、一世代前に最初に明確に表現された洞察の多くは、今日でも真実を保持しています。

この記事では、私はコンピュータサイエンスについての私のお気に入りの引用のいくつかを解剖しました。 私が設定した唯一の条件は、各引用符が少なくとも20歳でなければならないということです。 古い技術はすぐに役に立たなくなりますが、私たちのプログラミングの祖先の古代の戒めは、より多くの滞在力を持ってい

“コンピュータ科学のすべての問題は、別のレベルの間接参照によって解決することができます。”-David Wheeler

ここでは、いくつかの開発者が説明したいと思う頻繁に繰り返されるcompsciの引用です。 それはコーディングがすべてに約あるものの中心に打つので、しかし、それは、一つの私の好きなプログラミングの真実です。

間接について考える最も簡単な方法は、レイヤーを想像することです。 たとえば、コンポーネントAをコンポーネントBに適合させる必要がある小さなプロジェクトがあるとします:

両方のコンポーネントが標準化されているので、それらを開いて壊したり、動作方法を変更することはできません。 まったく新しいコンポーネント（PlugTwoProngVariant）を構築することはできますが、それは多くの作業と不必要な重複です。 両方のコンポーネントに適合し、それらの間に変換アダプタ—より良いアプローチは、二つの部分の間にレイヤーを追加することです。

今、間接参照が互換性のない部分を一緒に収まるように新しいレイヤーを追加するだけであれば、それはいいですが、狭く便利です。 しかし、それらの周りに構築することによって問題を解決するという考えは、コンピューティングの下から上に伸びる概念です。 新しいデータモデルを古いユーザーインターフェイスに適合させようとしているときに表示されます。 従来のアプリケーションを新しいwebサービスバックエンドに適合させようとしているときに表示されます。 ログやキャッシュなどの高レベルの機能を使用したり、メッセージングやトランザクションなどの高レベルのサービスを調整したりする必要があ そして、ピラミッドの上部には、機械学習のような希少なトピックがあります（必要な動作をコード化できない場合は、それを理解する別のコード層を書

多くの人々は、コーディングは馬鹿なコンピュータでさえ理解できる言語で明示的な命令を書くことであるとあなたに言うでしょう。 しかし、David Wheelerの引用は、より良い洞察を明らかにしています。 良いプログラミングは、最も一般的な解決策に到達するために抽象化のはしごを登ることです。

ボーナス関連の引用：

間接参照は強力ですが、複雑さにはコストがあります。 人々は非常にまれに間接参照についてウィーラーの即時のフォローオン発言を引用します:

“しかし、それは通常、別の問題を作成します。”-David Wheeler

その真実は、それ以来、プログラマをビジネスに保ってきました。

“シンプルさは信頼性のための前提条件です。”-Edsger Dijkstra

コードを過度に複雑にしないように警告する賢明なプログラマの不足はありません。 しかし、オランダのコンピュータサイエンスの先駆者Edsger Dijkstraよりも複雑さのコストを明確にする人はほとんどいません。

ここに洞察があります：あなたは未来への贈り物としてシンプルさを選択しません。 コードを再利用する機会を期待しているため、またはコードレビューをよりきれいに見せたいため、または変更を容易にしたいために、これを行いません。 （これらの利点はすべて貴重ですが！）シンプルさが前提条件であるため、あなたはそれを行います。 シンプルさがなければ、ビジネスを実行したり、データを処理したりするために信頼できる信頼できるコードを持つことはできません。

Dijkstraのポイントを受け入れるには、”良いコード”が何を意味するのかを再定義する必要があります。 それは最短のコードではありません。 それは必ずしも最速のコードではありません。 それは間違いなく賢いコードではありません。 信頼できるコードです。

ボーナス関連の引用：

コードを単純に保つための最良の方法の一つは、より少ないことがより多くであることを覚えておくことです。 Dijkstraは、私たちがそれを念頭に置いておくのに役立つ指標を提供しています:

“コードの行を数えたい場合は、それらを’生産された行’ではなく’使用された行’とみなすべきです。'”-Edsger Dijkstra

可読性と書き換えについて

“コードを書くよりもコードを読むのが難しいです。”-Joel Spolsky

一見すると、ソフトウェアの伝説とStackOverflowの共同作成者Joel Spolskyによるこの引用は真実ですが、一見浅いようです。 はい、コードは密で、簡潔で、退屈な長さにすることができます。 そして、それは他の人のコードだけではありません。 あなたは一年前から自分の仕事を見れば、あなたはおそらくあなたがかつて密接に知っていたロジックをソートするためにいくつかの時間が必要

しかし、スポルスキーの洞察力はひねりを加えたものです。 あなたが読むことができないコードの危険性は明白なだけではありません（それを変更して改善するのは難しいです）。 代わりに、複雑なコードが実際よりも悪化しているように見えることが大きな危険です。 実際、他の誰かがすでに書かれているコードを理解しようとする負担は非常に大きいので、Spolskyが最悪の間違いと呼ぶものを作りたくなるかもしれません。

書き換えがシステムのアーキテクチャを改善できないわけではありません。 彼らは間違いなくできます。 しかし、これらの改善は大きな費用がかかります。 彼らはテストとバグ修正、単なるコーディングよりもはるかに時間がかかる二つの活動に時計をリセットします。 書き換えは、ソフトウェア開発で最も一般的なバイアスの一つで遊ぶので魅力的です：私たちは概念的に単純なことをする努力を控えめにします。 それはプロジェクトの最終的な5%が時間の50%をなぜ取るかである。 簡単なことは驚くほど時間がかかることができます！ そして、あなたがすでに解決した問題を解決するよりも簡単なことは何もありません。

だから、あなたはそれを完璧にするためにすべてを書き換えるべきではない場合は、より良い解決策は何ですか？ その答えは、すべての開発者を一定の一口サイズのリファクタリングに関与させることです。 これにより、小規模で継続的なコード改善が可能になり、リスクを最小限に抑えた本当の報酬が得られます。 途中で読みやすさを向上させることができます。

ボーナス関連の引用：

読みやすさの重要性についてまだ疑問がある場合、Martin Fowlerはそれを視点に置くのに役立ちます:

“どの愚か者でも、コンピュータが理解できるコードを書くことができます。 優れたプログラマは、人間が理解できるコードを書きます。”-Martin Fowler

言い換えれば、プログラマの仕事は物事を機能させるだけではなく、物事を理にかなったものにすることです。

“自分を繰り返すな 知識のすべての部分は、システム内の単一の、明確な、権威のある表現を持っている必要があります。-Andy HuntとDave Thomas

すべての自尊心のあるプログラマは、繰り返しが多くの悪の心であることを知っています。 同じことを別の場所で書いている場合は、書き込み、テスト、デバッグを余分に行うことになります。 さらに悪いことに、コードの一部が更新されても、他の同様のルーチンが合意されていない場合など、不整合の可能性が導入されています。 矛盾したプログラムはあなたが信頼できないプログラムであり、あなたが信頼できないプログラムはもはや実行可能な解決策ではありません。

しかし、繰り返しが大混乱を引き起こす場所はコードだけではありません。 有名な「don’t repeat yourself」（DRY）ルールのこのバージョンでは、矛盾が隠れる可能性のある他の場所をカバーするために重複しない原則が拡張されています。 私たちはもはやコードの重複について話していません。 私たちはまた、システム内の繰り返しについて話しています—そして、システムは知識を符号化する多くの異なる方法を持っています。 それらは含んでいます:

• コードステートメント
• コードコメント
• 開発者またはクライアントのドキュメント
• データスキーマ(データベーステーブルなど)
• テスト計画、ワークフロードキュメン そして、彼らがそうするとき、彼らは同じ現実の異なるバージョンを導入する危険があります。 たとえば、ドキュメントにある作業方法が記述されていても、アプリケーションが別の作業方法に従っている場合はどうなりますか？ 誰が真実の所有権を持っていますか？ データベーステーブルがコード内のデータモデルと一致しない場合はどうなりますか？ または、コメントは実際の実装と一致しないアルゴリズムの操作を記述していますか？ すべてのシステムには、他のすべてが派生する単一の権威ある表現が必要です。

  ちなみに、真実の競合するバージョンは、小規模なプロジェクトや不十分に設計されたコードの問題だけではありません。 最良の例の一つは、XHTMLとHTML5の間の戦いで公衆に噴火しました。 ある陣営は、この仕様は公式の真実であり、ブラウザはそれに従うために修正する必要があると主張した。 他の派閥は、それが設計者がwebページを書いたときに念頭に置いていたものだから、ブラウザの動作は、事実上の標準であったと主張しました。 最終的には、真実のブラウザ版が勝った。 その時点から、HTML5はブラウザがしたことでした—彼らが許可したショートカットと彼らが受け入れたエラーを含みます。

  ボーナス関連相場:

  コードとコメントが互いに矛盾する可能性は、コメントが良いよりも害を及ぼすかどうかについて熱い議論を開いた。 極端なプログラミングの支持者は、オープン疑いでそれらを扱います:

  “コードは決して嘘ではありません。”-ロン-ジェフリーズ

  ハードな問題について

  “コンピュータサイエンスには、キャッシュの無効化と命名という二つの難しいことしかありません。-Phil Karlton

  一見すると、この引用は面白いが普通のプログラミングジョークのように思えます。 難しいと思われるもの（キャッシュの無効化）と無痛に聞こえるもの（物事の命名）とのコントラストは、即座に関連します。 すべてのプログラマは、間違った順序で渡されたパラメータのペアや矛盾した大文字の変数（JavaScriptのおかげで）のような、途方もなく些細な問題を修正する 人間が物事を成し遂げるために機械と提携する必要がある限り、プログラミングは高レベルのシステム計画と些細なタイプミスのマッシュアップ

  しかし、Phil Karltonの引用をもう一度見てみると、解凍する必要があります。 物事の命名は、プログラマの人生が定期的に小さな頭痛によって台無しにされているからといって難しいことではありません。 また、命名の問題は、実際にはすべてのプログラマの最も重要な仕事のエッジであるソフトウェア設計です。 言い換えれば、明確でクリーンで一貫性のあるコードをどのように書くのですか？

  名前を間違える方法はたくさんあります。 我々はすべてのデータ型にちなんで命名された変数を見てきました(myString, obj), 略語（製品カタログの場合はpc）、いくつかの些細な実装の詳細(swappable_name, formUserInput), または全く何もない(ret_value, tempArray). 変数に含まれているものではなく、その瞬間に何をしているのかに基づいて変数に名前を付けるという罠に陥るのは簡単です。 そして、ブール値は特にトリッキーです-progress進行状況が開始されたときに設定され、UIに進行状況情報を表示する必要があることを示していますか、まったく異

  

  しかし、変数名は始まりに過ぎません。 クラスの名前付けは、コードを独立した部分にどのように分割するかという問題を提起します。 パブリックメンバーに名前を付けることで、アプリケーションのある部分が別の部分と対話できるようにするインターフェイスをどのように表示するかが決まります。 これらの名前をロックすることは、コードの一部が何ができるかを記述するだけではなく、何をするかを決定します。

  ボーナス関連相場:

  “コンピュータサイエンスには、キャッシュの無効化、名前付け、オフバイワンエラーという二つの難しいことがあります。”-レオン-バンブリック