チェスゲームのルールを知っていても、その人がまだグランドマスターになっていません;プログラミング言語の知識があれば、その人はプログラマーになりません。 そして、両方の場合に欠けているものは何ですか？ 有名なマスターからの両方の質問への答えを探しており、私たち自身の例を使って説明しようとしています。
「そして、同志たちは何を考えているのですか？」 アイデア、仲間は、論理的なチェスの形をした人間の思考です。 取るに足らない力でも、ボード全体をマスターできます。 それはすべて個々の個人に依存します。 たとえば、3行目のブロンド。 彼が上手にプレイするとします...「ゲームのルール」（プログラミング言語、標準ライブラリ）を知っていても良いコードを書くことを保証しないという意味では、プログラミングはチェスのようなものです。 悲しいかな、これは、プログラミングのポジションで少なくとも数十のインタビューを行った人には明らかです。 Great Combinatorの証言（教育は何もない、主な経験）は常に機能するわけではありません-人はいくつかの形式で同じタイプの執筆経験を10年持つことができます（チェスプレーヤーはほとんど強くなく、同じゲームを10年間続けてプレイしました）。
3列目のブロンドはフラッシュしました。
「そして、そのブルネットはもっと悪いことです。」
誰もがブルネットを振り返って調べました。
「何が見えますか、仲間？」 ブロンドは上手く演じており、ブルネットは上手く演じていないことがわかります。 そして、各個人がチェッカーを常に訓練していなければ、この力の相関関係を変える講義はありません...つまり、チェスで...
I.イルフ、E。ペトロフ「12の椅子」
しかし、このアイデアに関するマエストロの言葉は私にとって重要なようです。 プログラムにとって、仲間とは、コードの形で具現化された人間の思考です。 したがって、品質コードは、品質思考（または少なくとも、少なくともいくつかの思考）の実施形態の結果として生じる。
プログラムの行の後ろ（または行の間）でこの非常に考えを見る方法と、そのような「ビジョン」が高品質のプログラムを書くのに役立つ理由を簡単な例で示します。 すぐに言います-説明されたテクニック（主にダイクストラとホアの名前に関連付けられています）は数十年前のものであり、残念ながら、それはプログラマー教育の主流になりませんでした。 しかし、希望は私にもう2つの説得力のあるアクセス可能な例を残しません-そして氷は壊れます...
プログラミングの紹介に関する珍しい本は、ハノイの塔のタスクを省きます。 次に、このようなプログラムの完全な「サイド」フラグメントをエンコードします。 ハノイタワーゲームの「フルバージョン」が何であるかを知る必要すらありません。プログラミング言語では、チームは2つしかありません。 だから。
与えられた。 3色のピンに3つのピン（1、2、3）が描かれ、最初のピンにリングが付けられます。
黒のピン、灰色のリング、白い背景。 次の2つのコマンドを使用できます。
ピン （ 番号 、 色 ）
リング （ 番号 、 色 ）
各チームは、対応する長方形を対応する色で塗りつぶします。 たとえば、説明した初期状態でRingコマンド（3、白）を指定すると、右側のピンから下部が消えます。
プログラムを書く必要があり、その結果、リングは中央のピンに移動します。 コマンドは即座に機能し、「アニメーション効果」は不可能であり、必要ありません。
希望するフラグメントを自分で書いてみてください。 明白すぎる？ はるかに良い。
このタスクは、トレーニングの程度が非常に異なる人々に提供されました。 誰もが対処し、次の3つのプログラムのいずれかを発行しました。
解決策
| A | B | C |
| リング（1、白）
ピン（1、黒） リング（2、グレー） | リング（2、グレー）
リング（1、白） ピン（1、黒） | リング（1、白）
リング（2、グレー） ピン（1、黒） |
ランダムな聴衆では、決定A、B、Cがほぼ等しい確率で発行されました。 しかし、強力なプログラマーはオプションAのみを書き、他のオプションがあることを知らされたとき驚き、オプションAが優れている理由を説明できませんでした。 それを理解してみましょう。 まず、プログラムAにコメントを提供します。
//ピン1を鳴らします
リング （1、白）
ピン （1、黒）
//すべてのピンは空です
リング （2、グレー）
//ピン2を鳴らします
すべてのコメントで、対応する実行段階で得られた画像のみを説明します。つまり、プログラムのアクションはコメントされませんが、対応するアクションの前後のシステムの状態が記述されます。
プログラムAが優れているのはなぜですか？ 彼女は、単純で、対称（ピン番号に関して）で、自然な（実際にはそうなる）中間状態を持っています。 最初のチームと2番目のチームの間の状態（破損した最初のピン）には簡単な説明がなく、現実に対応していません。 おそらくこれが、経験豊富なプログラマーが直感的に最初にこの疑わしい状態から脱出し、次に進むことを追求する理由です。
患者の読者であるオーケーは、著者の信念を尊重すると言いますが、抽象的な道徳に加えて、これらすべての実際的な意味は何ですか？ プログラムBとCは実際には悪化していますか？
同じトリックを使用してプログラムBを詳しく見てみましょう-システムの中間状態についてコメントします。
//ピン1を鳴らします
リング （2、グレー）
//ピン1と2で鳴る???
リング （1、白）
ピン （1、黒）
ご覧のとおり、ここでは中間状態の疑いについて説明できます。 そして、この説明は開発者に即座に警告を発するはずです-タスクの用語で言うと、リングは2つではなく1つだけです。 子どもたちの恐れはソフトウェアであるように思えます。 経験豊富なプログラマーがこの道を選ばないのはなぜですか？ おそらくそれは精神的な労力を節約するからです-プログラムAは現実から「消え去る」のです。それが、実際のピンの実際のリングを再配置する方法です。 プランAの一貫性と実現可能性は、ある意味で、本質的に保証されており、正式な保証を節約します。 プランBは一種の「仮想現実」を意味し、その一貫性には慎重な分析が必要です。 隣接するピンの2つのリング-そして、それらはそこに収まりますか？ このような質問の後、プログラムBの失敗したテストが明らかになります。
プログラムCはAとほぼ同じ順序で動作しますが、マイナーな欠陥の除去を後まで遅らせるだけです。 理解できる中間状態はありません。その結果、読者の注意が常に最初のピンから2番目のピンに、またはその逆にジャンプします。何が起こっているのかを理解するために、3つのコマンドすべてと画像の変更可能な部分全体に留意する必要があります おそらく、経験豊富なプログラマーは、精神的な労力を節約することから、この道を再び避けます。スターティングピンに関するすべての問題を迅速に解決し、それらを忘れる方が良いでしょう。
プログラムCの実際の問題は、ケースBほど明白ではありません。後で、プログラムの顧客がリングを任意のピンs（そこにあると仮定）から任意のピンdに転送したいと想像してください。 元のプログラムを変更する必要があります（リファクタリング、はい）。 どこでも定数1を変数sに、定数2を変数dに置き換えるのは自然な考えのようです。 プログラムAはこのようなリファクタリングに耐えることができますが、プログラムCはそうではありません-s = d（チェック！）では正しく動作しません。
観察。 適切なエンコーディングオプションを選択することは、他のオプションがどこで壊れるかを理解するよりもはるかに簡単です（もちろん、意識的にまたは直感的にプログラムを行間で読むことができる場合を除きます）。 私たちの意見では、プログラマーの資格は主に、プログラム内のエラーの場所を理解する能力ではなく、エラーの可能性が最小限になるようにプログラムを書く能力にあります。 機知に富んだ賢者についてのことわざを思い出してください。機知に富んだ人は困難な状況から抜け出す方法を知っており、賢明な人はそのような状況に陥らないでください。
結論として、同じプログラムの別のバージョンは、科学と産業の間の特定の隔たりを示しています。
リング （1、白）
リング （2、白）
リング （3、白）
ピン （1、白）
ピン （2、白）
ピン （3、白）
//純白の背景
ピン （1、黒）
ピン （2、黒）
ピン （3、黒）
// 3つの空のピン
リング （2、グレー）
//ピン2を鳴らします
このような決定は、大学のコースや面接ではほとんど適切ではありませんが、制作には適している場合があります。 プログラムの作者は、正しい「増分変化」を計算できなかったことを正直に認め、すべてをゼロから描きました。 プログラムBおよびCの作者とは異なり、彼はどうやら潜在的な困難を識別できたようですが、それらをより効果的に処理する時間も能力もありませんでした。 近い将来、独創的なコードを書く十分なプログラマーがいるという事実に頼るのは無意味です。 しかし、少なくともほとんどのコーダーにこのような「ダム」コードの書き方を教えることができるかもしれません。