コーディング中にインテリセンスとドキュメンテーションに大きく依存していると、プログラマーは下手になりますか？
プログラマーはすべての構文を学習して記憶する必要がありますか、それともいくつかのドキュメントを手元に置いても問題ありませんか？
それはマネージャーがコーダーを見る方法に影響しますか？
インテリセンス、オートコンプリート技術、およびPDFドキュメントに依存することの欠点は何ですか？
まったく正常です。すべてのPHPまたはJavaクラス、関数、またはフレームワーク）の構文を知っていると誰もが言うことはほとんどできません。
あなたの脳は、物事を記憶するよりも問題解決によく使われます。
当然、日常的に使用するものを記憶する傾向がありますが、その特定のことを行わずに数か月が経過すると、構文を忘れてしまいます。
構文を覚えることが開発の鍵だったとしたら、コンピューターはすでにその分野の人間に取って代わっていただろう。
抽象化、想像力、問題解決、パターン認識に脳を使用することは非常に貴重です。それ以外には、マスターカードがあります。（1）
（1）または、この場合、ドキュメント、オートコンプリートなど。
絶対にすべきではないことは、何かの構文を覚えていないときはいつも同僚に尋ねることです。それは怠惰でしょう。
暗記に関しては、あなたの言語のコアsyntaxについての確かな知識を持つことはかなり重要だと思います。 notは、コアlibrariesを記憶する必要があることを意味します。 JavaはJSCLです。C＃/ VBは.NETです。PHPだと...
とにかく、重要なのは構文を知っていることですが、必ずしもすべてのクラス、関数、メソッドを知っている必要はありません。構文を理解することは、英語の文法を理解することに似ています。つまり、文がどのように形成されるかを知っています。ライブラリーを知ることは、語彙に似ています。単語がわからない場合は、簡単に調べることができます。あなたは完璧な言葉を見つけられないかもしれませんが、あなたは適切なものを見つけるでしょう。文法がわからないと、メッセージを明確かつ正確に伝えるのが非常に難しくなり、必要なときに必要なものを探すのが非常に難しくなります。
話をしましょう。
1999年5月30日頃まで John CarmackはOpenGLでシザーテストがデフォルトで有効になっていないことを知りませんでした 。
次はちょっとおかしいです。私は、OpenGLドライバーの多くが、ステータスバーの3Dアイコンの深度バッファー全体を、はさみ領域に限定するのではなく、クリアしているのではないかと疑っていました。ドライバーのクリア領域を明示的にトリミングするコードをg200ドライバーに追加しましたが、実行されませんでした。もう少し調査したところ、私は何年もの間不適切な仮定をしていたことがわかりました。デフォルトでは、はさみは有効になっていません。どー。
これを見つけることは、何か他のことをしている状況で、偶然に彼に完全に気付き、彼のコードにかなり素晴らしいパフォーマンスの向上をもたらしました（パフォーマンスが非常に重要な領域で彼が働いている場合、これは注目に値します）：
今、私はこの3年間それについてバカになっていたことを知っています...シザーを有効にすると、ほとんどのカードが数パーセント速くなりました。
ここで彼の自己認識に注目することも価値があります。「私はこの3年間、それについてばかだった」.
ここで、彼が ドキュメント （ "テストは最初は無効になっています"）を読んだ場合、はさみテストがデフォルトで無効になっていることを知っていたでしょうそして、その間違いはしなかったでしょう。
ドキュメンテーションを読むことがジョン・カーマックを悪いプログラマーにしたであろうケースですか？ドキュメンテーションを読まないことがジョン・カーマックをより良いプログラマーにしたのはこれですか？これらの質問に答える必要はないと思います。
インテリセンスに関しては、インテリセンスがあなたの時間を節約するように設計された生産性ツールであることを認識することが重要です。 「。」と入力します。または「->」と入力すると、メンバーのリストがポップアップ表示され、必要なメンバーの最初の数文字を入力して、ちょっとだけプレストします。それはあなたの貴重な時間であり、あなたがまだコーヒーを持っていなかったのであなたが作ったその疑わしいタイプミスのおかげでビルドを壊すことを節約したかもしれません、そしてあなたは今コードを細かくするのではなく、生産的なことを行う。
Intellisenseはではなく悪いプログラマーのための松葉杖として設計されています。これは Fred Brooks が「鋭いツール」と呼ぶものの例です。
インテリセンスを却下するのと同じ論理により、プログラマーの生産性を高めるように設計されたツールはどれも、悪いプログラマーになる可能性があるという結論に至る。次はコンパイラとデバッガを拒否するため、これは危険な考え方です。
私が前世紀に大学に戻ったとき、講師の一人が「最高のプログラマーは怠惰である」と私たちに言った。それは非常に意地悪であり、彼が意味したことは、最高のプログラマーが生産時間を最大化し、ロバの作業に費やす時間を最小化する方法を見つけることでした。今日でもそれは良いアドバイスだと思います。
ありえない;逆に、それは生産性ツールであるため、より優れたプログラマーになり、それらを使用するプログラマーはプログラムをより速く/より良くします。プログラマーの目的は、ライブラリーまたはフレームワークがいくつかのメソッドまたはクラスを呼び出す方法を知らないようにすることです。
プログラマーは必ずしも言語の構文を知っている必要はありません。しかし、現代のIDEは何かが間違っているとすぐに彼/彼女に警告するので、どういうわけかそれを知ることが義務付けられたので、彼/彼女は間違いなくIDEエラーメッセージが表示されます。問題を解決する前に、一部の単語の下に赤い下線を付けてプログラミングしている人は、本当に想像できません。それを使用する方法を見つけます。
コード補完は、プログラマーが特定のライブラリーの新しい機能を見つけるのに本当に役立つと言えます。優れたライブラリはすべて抽象化に基づいています-インターフェース。ソートのロジックを実行することになっているインターフェースSortがあるとします。現在、このロジックはいくつかの方法で実行できますが、プログラマーとして、私は与えられたライブラリーが実際にそれで何ができるかを知りません。だから私はSort sort = Ctrl+Space そしてすぐに、可能なすべての実装が表示されます（このようにして、多くのライブラリーについて新しいことを実際に発見しました）。実装の中にはQuickSortが表示されますが、私はそれについてあまりよく知りません（私のIDE-Intellij）で私は Ctrl+Q そして、私はすぐにクラスのドキュメントを見て、それがどのように使用されるかを見ます。 QuickSortの実装方法に興味があるので、状況はさらに進みます。 Ctrl+B Mavenリポジトリから実装をダウンロードすることを選択すると、すぐに実装コードが表示されます。
プログラマーはすべての構文を学習して記憶する必要がありますか、それともいくつかのドキュメントを手元に置いても問題ありませんか？
いいえ、はい。ドキュメンテーションから新しいことを学ぶことができないプログラマーは不自由です。彼らは新しい問題を解決することはできません。彼らができることは、他の誰かが書いたカットアンドペーストのコードだけです。ドキュメントを読むプログラマは、既存のライブラリ関数を再発明しないことを十分に理解しているため、私は好みます。採用にあたっては、候補者が現在の実装言語での経験があるかどうかはほとんど気にしません。私たちはいつか新しい言語を使い始めるかもしれないので、多言語で仕事をして喜んでくれる人が欲しいです。
それはマネージャーがコーダーを見る方法に影響しますか？
いいえ、メジャーゼロのサブセットを除きます。