2月に、私たちはクールな記事の翻訳を公開しました。 「 学習がなぜプログラミングが難しいのですか？ 」、これを初心者に見せています。 はい、プログラミングを学ぶことは、感情的な浮き沈みを伴うさまざまな段階があり、長いストーリー全体です。 私たちは皆、これを経験しました（または、まだ進行中です-維持してください！）。
残念ながら、立ち上がって「勉強を終えて、今はプログラマーになった！」と言うことができる瞬間はありません。 すべての人生を研究し、未知の問題に遭遇し、完全に不可解な状況に直面し、長年の経験を持つプロのプログラマとしてさえ「一体何だ！」と尋ねるすべての人生を勉強しなければなりません。
今日、私たちは「なぜプログラミングがそんなに難しいのか」というメモの翻訳版を公開しています。 プログラミングと開発の基礎をまだ学んでいる人は、将来何が待っているのかを知ることは有用だと思うでしょう。 そして、経験豊富な開発者は、現実とうなずきを見て喜んでいます。
何年も前、プログラミングは簡単だと思っていましたが、何年も経ち、そうではないことに気付きました。 それはすべて、私がプログラミングと見なしたものと、プログラマーがどんな仕事をしているのかについての誤った認識によるものです。
最初は、プログラミングはコンピュータに何をすべきかを伝えるだけであると思いました。プロセスのこの部分は比較的簡単です。 20年以上の経験を経て、プログラミングのこの部分は非常に簡単であるという結論に至りました。
定義1 ：プログラムは、生データを結果に変換するものです。
プログラマーはプログラムを書く人であり、プログラミングはこのプログラムを書くプロセスです。
次に、プログラム定義にいくつかの条件を追加しましょう。
定義2 ：プログラムは、ソースデータを結果に変換するものであり、次の条件に依存します。
- プログラムの結果は素晴らしいです。
- 生データは優れています。
- プログラムは素晴らしいです。
- ソースデータは正確かつ正確に文書化されます。
- プログラム自体は定性的かつ明確に文書化されています。
- プログラムは十分にテストされ、正しく実行されます。
- 手元のタスクは明らかに詳細です。
- タスクは明らかに詳細です。
これらの追加条件により、プログラミングは非常に困難になります。 特定のタスクでは、これらの条件の一部を緩和できます。 いくつかの典型的なシナリオは、それ自体を示唆しています。
サポートする必要がないプログラム
結果のためだけにプログラムを作成することもあります。 この場合、ソースデータとプログラム自体は将来サポートを必要としないため、優れたものでも詳細なものでもない可能性があります。
Erlangに関する私の本は一例です。 本が出版されると、本を作成したソースデータとプログラムのサポートは必要なくなりました。 結果は素晴らしく見えますが、ソースデータは大量のXMLファイルと、メンテナンスの必要がない小さなテストプログラムです。
コピーで必要に応じて行われた入力ミスと修正により、ソースデータがわずかに変更されるだけです。 プログラムのソースデータが十分に文書化されていない場合でも、簡単に修正できます。
サポートが必要なプログラム
サポートされているプログラムの場合、すべてが最後のシナリオの反対です。 プログラムのソースデータとプログラム自体は、優れたものであり、十分に文書化されている必要があります。
最近、Webアプリケーションを開発する専門家と話をしました。 彼は、プログラムの結果が正しいように見える（つまり、Webサイトが正常に表示され、プログラムが機能する）とすぐに、顧客がプロジェクトの完了を決定し、プロジェクトマネージャーがそれを次のプロジェクトに割り当てると言いました。
彼らには、ウェブサイトをきれいにするだけでなく、それを形成するコードをクリーンアップし、次のプロジェクトを開始する前に文書化する必要があるという時間も理解もありません。 これは、将来サポートが必要なプロジェクト向けです。
他にプログラミングを複雑にするもの
プログラミングを困難にしているものが3つあります。
- まったくすべきではなかった問題の修正。
- 新しいことを学ぶ時間がない
- プログラミングの悪い雰囲気
これらの困難-本当の時間泥棒を見てみましょう。
まったくすべきではなかった問題の修正
多くの場合、特定の問題を解決するために、私が作成したソフトウェアではなく、特に理解していないソフトウェアを使用する必要があります。
最良の場合、使用するプログラムには便利な使用説明書があります。 しかし、多くの場合、プログラムにはまったく指示がないか、説明が不十分です。
ドキュメントに「XYZを実行してからPQRを取得」と書かれていて、「XYZ」を実行しても「PQR」が失敗した場合はどうなりますか？ 運が良く、プログラムを書いた人が近くにいる場合は、行くことができますが、うまくいかない場合は、Googleで答えを見つけるか、答えを探してコードを掘ります。
Googleルーレットを使用してバグを修正するのは非常に面倒です。 私は少しグーグルで検索しましたが、すぐに私のような不幸な人が私のものとまったく同じ問題に出くわした悲しい投稿を見つけました。 期待して胸がドキドキします。 震える指で、私は呪いを取り除く魔法の公式を導入します...そして何もありません。 問題はなくなりません。
修正が一部の人々には機能するが、私には機能しないことがあるのはどうしてですか。 私を見ている下劣な神のどこか、または物理学の法則が一時的に変更された宇宙の特定の場所にいますか？ いいえ、異なるデバイスの初期状態が異なるだけであるため、あるデバイスのバグを修正しても、別のデバイスのバグが修正されるとは限りません。
時々私たちはすべて同じプログラムイメージで開始するように、SmallTalkでプログラムしたいです。SmallTalkプログラマーは、これが起こり得ないような天国に住んでいる必要があります。 。
ちなみに、この問題は、私の最大時間を60-70％奪うものです。 壊れたLDAPサーバーに対処しようとして約1週間費やしたが（上司は自分のLDAPサーバーを使用することを禁じていた）、壊れたサーバーと戦った1週間後、Cで書かれた文書がひどく、メモリ障害が発生したため、上司が私に言ったことを忘れて、昼休み中に誤ってサーバーをErlangに最初からインストールしました。
実際には、完全なLDAPサーバーではありませんでしたが、完全なLDAPサーバーは必要ありませんでした。 いくつかのチームが働きたいと思っていましたが、簡単に修正できることがわかりました。
今では、古風で異常なプロトコルを使用する喜びはありませんが、多くの場合、何かを変更する最も簡単な方法は、それらをゼロから再インストールすることです。
新しい知識を得ることなく問題を解決する
私は残念です。 素晴らしい仕事をすることができます。 しかし、LaTeXでチャートを作成したいときは、391ページの指示を読みたくありません。 私は今あなたが怠accで私を非難し、私が道徳的にcorrupted落していることを知っています、そして私は最初に友好的な指示を読まなければならないことを知っていますが、私は391ページの指示を除いて10分間文書に図表を持ちたいです。
問題を解決するとき、私は迅速な修正方法に頼りますが、長い目で見れば災害です。
たとえば、ドキュメントの作成を考えてみましょう。 TeX / LaTeXとXSLT-FOと自分のErlgutenを選択できませんでした。
3年に1回程度、すべてのドキュメントをポストスクリプトで書きたいという強い願望がありますが、やるべきことは深呼吸をしてこの欲求が消えるまで待つことだけです。
Jambattista Bondoniは、1818年にManuale Tipograficoを作成したとき、1ページのレイアウトに数週間かかることを特に心配していなかったと思います。 しかし今では、マシンに退屈で危険な作業をさせることができるため、はるかに時間があります。質的に何かをする時間はありません。
上司に次のプレゼンテーションのために「かわいいスライド」が欲しいかと尋ねたところ、明日までにそれをやれば、彼は同意した。 しかし、TeXを勉強するのに十分な時間がありませんでした（そして1年ほどかかると思います）、独自のレイアウト言語を適用するには5年から10年かかりました。 PostScriptに直接書き込むため（1週間程度）。 だから、どうやら、PowerPoint ...
プログラミングの悪い雰囲気
ここまで読んでいただければ、プログラミングが複雑であることに気付くでしょう。 これが、プログラミングをさらに複雑にするジョブが設計されている理由です。 集中力を損なう騒がしい環境を提供するオープンタイプのオフィス、私たちを悩ませる携帯電話、そして気を散らすインターネット。
幸いなことに、気が散らないように行くことができる場所があります。 寝る 睡眠中に多くのソフトウェアの問題が解決されます。
2つの方法があります。
最初に、あなたは脳に問題をロードし、次に眠りに落ち、翌日あなたが目を覚ますと、問題のいくつかが解決されます。 簡単です。
2番目の方法 ：インターネットに問題を投稿するか、寝る前にそれについてツイートし、翌日誰かがメールで解決策を送信します。
優れたプログラマーになるには多くの時間がかかります。多くの情報を取得し、立ち往生している場合に誰に連絡するかを知る必要があります。
驚くべきが真実
この記事を終えたとき、つづりを確認したかったのです。 Emacs-Ispellモードはストライキを開始することにしました。 彼は、スペルチェックに使用するプログラムであるaspellを見つけることができませんでした。
私のemacsスペルチェッカーは、このデバイスで数年間忠実にその機能を実行しました。 そして今、私は自分の人生の半分を費やしていたはずのないバグを修正することに不満を言ったとき、emacsは故障することにしました。
私は下劣な神を信じていないし、物理学の法則が私がこのテキストを入力している私のリビングルームのソファの左隅で異なるという事実も、これがそうであるという間接的な証拠はあるが、信じていない。
スペルコントローラーが壊れる理由はありません。すべてが正常で、何も変更していません。 さて、最後にドキュメントのエラーをチェックした後、ErlangとJuliaの新しいバージョンをインストールし、いくつかの講義を書きました。
幸いなことに、Googleルーレットでの11分間が役に立ちました。 問題を解決する方法に関する2番目の投稿は機能しましたが、emacsがaspellを見つけられなかった理由はまだわかりません。
私たちは決して知らないことがあると思います。
翻訳：ナタリアベース/ Hexlet.io