初心者プログラマーの典型的な間違いの分析: パート 1

こんにちは世界！ 必要なことをすべて学び、最終的にインターンまたはジュニアとして採用された後は、おそらくリラックスできるでしょう? たとえそれがどんなものであっても！すべては始まったばかりです... あなたの周りには新しくて理解できないことがたくさんありますが、最初からこのように失敗しないようにするにはどうすればよいでしょうか？今日はそれについて話します。この記事では、初心者が犯しやすい間違いを取り上げ、それを回避する方法について私自身の経験からいくつかのヒントを提供したいと思います。それでは、さっそく始めましょう。

1. 経験豊富な同僚に助けを求めることへの恐怖

私たちは皆人間であり、特に新しく入社した経験豊富な同僚の目に愚かに見えることを恐れています。開発者は、最初の仕事に就くと、この恐怖に負けて、どうしようもなく自分の中に引きこもり、すべてを自分たちで解決しようとすることがよくあります。同時に、人はより経験豊富な同僚に囲まれ、その結果、最初は最も正しい道に沿って彼を導くことができ、さらなる間違いや不必要な「衝突」を避けるのに役立ちます。したがって、覚えておいてください。質問することを恐れないでください。あなたは初心者であり、誰もがこれを完全に理解しています。あなたが尋ねるとき、誰もあなたを棒で殴ることはありません。もしかしたらその逆かもしれません。同僚とより早く友達になり、より積極的にコミュニケーションをとるようになります。もっと言いますが、さまざまな技術的な問題について質問し、議論すればするほど、より早く初心者から脱却して、その分野の専門家に成長することができます。そして、もう一つアドバイス。StackOverFlow を無視しないでください。この文脈では、このリソースについて質問することを意味します。一方で、あなたの質問に対する答えを得るには時間がかかります。しかしその一方で、現在の問題を解決するためのいくつかのアプローチをすぐに学び、それを少し異なる視点から見ることができるかもしれません。また、コメントと回答を書き、StackOverFlow 上で他の開発者からの質問を明確にすることには、カルマのプラスに加えて、実際的な利点があることにも注意したいと思います。つまり、この問題についてより深く議論し、理解する機会が得られるということです。

2. 自分で情報を探そうとしない

おそらく、このエラーは前のエラーの裏側であると思われます。つまり、あらゆる問題や問題について同僚や知人を引っ張り始めたときのことです。質問するのは良いことですが、質問しすぎないでください。そうしないと、退屈してしまう可能性があります。理解できない点が生じた場合に最初にすべきことは、最高の検索エンジンである Google で検索スキルを応用することです。理解できないエラーやその他の問題の大部分には、すでに誰かが遭遇しています。Google で検索すると、同様の問題に精通しており、仕事で使用するのに適した包括的な回答をすでに受け取っている人がたくさんいることに驚くでしょう。これに基づいて、同僚が質問に「グーグルで調べてください」と答えるのをよく耳にします。結局のところ、あなたの同僚はあなたの仕事分野のすべての複雑さを伝えるべき個人教師ではないので、この答えに腹を立てる必要はありません。インターネットの無限の広がりは、そのような指導に役立ちます。プログラマーは、Google 検索の黒帯を持つ人と呼ばれることもあります。したがって、行き詰まったときは、まず Google で問題を検索し、解決策が見つからない場合は (めったにありませんが、それはあります)、同僚に質問し始めます。何らかの不具合や理解できないエラーが発生したときではなく、問題を解決するためのアプローチを選択するときに、すぐに質問する価値があります。結局のところ、彼らはあなたの考えを超えて見ることができ、これまたはそのアプローチが長期的にどうなるかをすぐに知ることができます。

3. ブラインドコピー＆ペースト

しかし、問題をグーグルで調べ、それに応じてその解決策を調べると落とし穴があります。たとえば、ブラインドコピーアンドペーストなどです。これは通常、同様の問題 (ただし、まったく同じではない可能性があります) が見つかり、その下に、たとえば StackOverFlow で解決策がある場合に発生します。この解決策を自分でコピーして貼り付けますが、あまり詳しく説明する必要はありません。そして、あなたやプロジェクトの同僚が、機能の奇妙なバグや誤った動作を発見します。そして、足がどこから来ているのか、すぐには誰も分かりません。そうすれば、当然、このコードを持つ場所が見つかりますが、この決定は間違いなく賞賛されません。したがって、StackOverFlow (または他の場所) で既製のソリューションを見つけたら、まずそれが何なのか、どのように、そしてなぜなのかを詳細に分析する必要があります。おそらくこの機能については Google で調べてドキュメントを参照してください。その後、それをプロジェクトに実装してください。

4. 間違った解決策を投げる

ソリューションを作成していると、ますます複雑になり、最終的には行き止まりに達することがあります。そして、より実行可能な別の代替案を探す代わりに、このアプローチを使ってこの問題を何とか解決しようとして、問題をますます複雑にしようとしています。もしかしたら、単に自分が費やしたエネルギーと時間を残念に思って、何があっても諦めずにこの方法で問題を解決しようと決心したのかもしれません。これは完全に正しいアプローチではありません。少なくともプログラミングにおいては。別のアプローチを早く試すほど、最終的にはより多くの時間を節約できます。したがって、このアプローチに費やした時間にもかかわらず、他のアプローチを実験したり試したりすることを恐れないでください。さらに、いくつかのアプローチを試してこの分野をよりよく研究するため、これらは経験のポイントになります。

5. 現在のタスクについて質問することへの恐怖

プロジェクトでの作業は通常、いくつかのタスク (タスク) を完了することになります。たとえば、Jiraの場合。そして、これらのタスクは必ずしも詳細かつ明確に説明されているわけではありません。それらは通常、チームのリーダーによって書かれますが、その場合、彼らもまた人間です。また、何かを追加するのを忘れたり、あなたがその機能にあまり慣れていないことを考慮に入れていない可能性もあります。あるいは、プロジェクトへのアクセス権 (データベースやログ サーバーなどへのアクセス権など) がありません。そして今、課題を受け取り、数時間以上勉強した後、あなたはまだ座って当惑して画面を見つめています。そして、これを無駄に解決し続けるのではなく、このタスクの作成者に先導的/明確な質問をし始める必要があります。たとえば、チーム内のコミュニケーションに使用するアプリケーション (Microsoft Teams など) で、またはこのタスクのコメントとして直接使用するとします。一方で、個人的なメッセージに質問を書いた場合、相手はすぐに質問を見ることができるため、回答が早くなる可能性が高くなります。一方、Jira で質問すると、何かを行っている、つまり問題を分析しているという証拠が得られます。このプロセスを高速化する方法があります。Jira でコメントとして質問し、このコメントへのリンクを参照リクエストとともにプライベート メッセージで送信します。

6. チームリーダーに期待しすぎる

繰り返しますが、これは前のポイントの裏返しです。チーム リードとは、開発チームの責任者です。一般に、そのようなチームメンバーの時間のほとんどは、さまざまな種類のコミュニケーションに費やされます。そして同時に、それが何であるかを忘れないようにコードも書きます。まあ、ご存知のとおり、これは非常に忙しいキャラクターです。そして、くしゃみのたびに過度にけいれんすることは明らかに彼を満足させません。チームメンバー全員が彼に大量の質問を浴びせた場合を想像してみてください。だから、夢中になっても大丈夫ですよね？そして、あなたの側から多くの質問があると、彼が長い間あなたに答えるであろうことは驚くべきことではありません。チームリーダーへの質問の数を減らすために何ができるか:

• 盲点の数を減らすために、このプロジェクトのドキュメントをさらに詳しく調べてください。
• 他のチームメンバーに質問してください。彼らのうちの 1 人がその機能を作成した可能性が高いため、彼らはリーダーと同じくらい、あるいはそれ以上にこの機能に精通している可能性が十分にあります。

あるいは、IDE では、特定の行のコードを誰が、いつ最後に変更したかなどの注釈を確認できます。こうすることで、誰がこの質問をするのが最も正しいかを知ることができます。おそらくすでに理解されていると思いますが、チーム リーダーに質問するときも、同僚に質問するときも、黄金の中庸を保つよう努める必要があります。質問することを恐れず、また過剰な数で質問することも避けてください。

7. コードレビューに対する恐怖

コード レビューまたはコード レビューは、コードを共通のアプリケーション (マスターや開発などの共通のブランチ) にアップロードする前の段階です。このチェックは、このタスクに関係のない開発者によって実行され、開発の初期段階では気付かなかったコード スタイルのエラー、不正確さ、または欠点を新鮮な視点で発見できます。コメントがある場合は、コードの特定のセクションへのコメントとして残されます。この場合、このタスクを実行した開発者は、レビューに従ってエラーを修正する必要があります (または、レビュー担当者と決定について話し合って、おそらく決定の正しさを納得してもらう必要があります)。その後、レビューのために返送するなど、レビュー担当者からコメントがなくなるまで繰り返します。レビュー担当者は、コードをアップロードする前の「フィルター」として機能します。そのため、多くの初心者プログラマーは、コードレビューを批判や非難として認識しています。彼らは彼女を評価せず、彼女を恐れていますが、それは間違っています。コードを改善できるのはコードレビューです。結局のところ、私たちは自分たちが間違っていることや注意すべきことについての重要な情報を受け取ります。学習の一環として各コード レビューを検討する必要があり、改善に役立ちます。誰かがあなたのコードにコメントを残すとき、その人は自分の経験やベストプラクティスをあなたと共有します。私にとって、コードレビューを受けなければ良いプログラマーになることはできません。なぜなら、経験豊富な外部の人の観点からは、自分のコードがどれほど優れているか、そこに間違いがあるかどうかはわかりません。

8. 解決策を難解にする傾向

多くの場合、さまざまなタスクや問題には、いくつかの異なる解決策が存在します。そして、利用可能なすべての解決策の中で、初心者は通常、最も複雑で「難解な」解決策を使用します。それは本当です。初心者のプログラマーが昨日、さまざまなアルゴリズム、パターン、データ構造を勉強したばかりだとすると、その中の 1 つを実装したくてうずうずしているのです。はい、そして私はいわば自分自身を宣言したいと思っています。信じてください、私自身もそうでしたし、自分が何を言っているのかわかります :) 私は、1 つの機能を書くのに長い時間を費やし、それが非常に非常に複雑であることが判明したという状況がありました。その後、シニア以上のレベルの開発者によって書き直されました。もちろん、私は彼が何をどのように変えたのかを見ることに興味がありました。私は彼の実装を見て、それが非常にシンプルになったことに驚きました。コードは 3 分の 1 に減りました。同時に、この機能のテストは変更されず、失敗しませんでした。つまり、一般的なロジックは変わりません。このことから、私は「最も独創的な解決策は常にシンプルである」という結論に達しました。このことに気づいてから、コードの記述がはるかに簡単になり、著しく高レベルになりました。では、パターンやアルゴリズムを使用する価値があるのはどのような場合ですか? そして、それらを使用するときは、最も簡単で最もコンパクトな方法になります。

9. 自転車の発明

この概念は車輪の発明としても知られています。その本質は、解決策がすでに存在し、プログラマが発明した解決策よりも何倍も優れている問題に対して、開発者が独自の解決策を実装するという事実にあります。一般に、独自の自転車を発明すると時間のロスが発生し、開発者の作業効率の低下につながります。最適とは程遠い解決策が見つからないか、まったく見つからない可能性があるためです。同時に、独立した決定の可能性も捨て去ることはできません。プログラマーは、既製のソリューションを使用するか、独自のソリューションを発明して、適切かつタイムリーにタスクを解決するために、目の前に現れる可能性のあるタスクを正しくナビゲートする必要があります。一方で、大学やコースでは、自転車を実際に作るために必要なさまざまな種類のタスクが降り注いでいます。しかし、これは一見しただけです。実際、この目的は、アルゴリズム的思考を開発し、言語の構文をより深く習得することです。そして、そのようなタスクは、アルゴリズム/構造をより深く理解するのにも役立ち、必要に応じて、高度な類似物を実装するスキルを与えることもできます (ただし、これが必要になることはほとんどありません)。実生活では、ほとんどの場合、私たちのニーズを満たす類似物が長い間存在しているため、独自の車輪を発明する必要はありません。おそらく、これまでの経験から、必要な機能の実装の存在を知らないかもしれません。ここで、この記事の最初のポイント、つまり経験豊富な同僚に助けを求める必要があります。彼らはあなたをガイドしたり（たとえば、Google にどの方向に進むかをアドバイスしたり）、特定の実装（特定のライブラリ）を提案したりできます。

10. テストを書かない

すべての初心者はテストを書くのが好きではありません。初心者はどうでしょうか。初心者以外の人もテストを書くのは好きではありませんが、テストが必要な理由はよく理解しています。完全に青信号のときは、「なぜそれを書くのか?」と考えます。すべて正常に動作し、エラーは発生しません。しかし、変更によってシステムの別の部分が壊れていないことをどうやって確認できるのでしょうか? 利益よりも混乱をもたらすような変更を押し進めても、同僚は感謝しません。ここでテストが役に立ちます。アプリケーションがテストでカバーされる範囲が増えるほど、結果は良くなります (カバレッジ率とも呼ばれます)。アプリケーションがテストで十分にカバーされている場合、すべてのテストを実行すると、変更によって破損する可能性のある箇所が見つかる可能性があります。上の例で述べたように、機能をリファクタリングするときにテストが失敗しなかったのは、すべて一般的なロジックが変更されなかったためです。これは、テストでは特定の機能のロジックが変更されたかどうかも示すことができることを意味します。したがって、たとえテストを書くのが好きでなくても、テストには間違いなくメリットがあり、時間を費やす価値はあります。

11. 過剰なコメント

多くの開発者は完璧主義に悩まされており、初心者も例外ではありません。しかし、時々、この欲求の副作用として、あらゆる人やあらゆるものについてコメントし始めることがあります。必要のないものであっても、それは非常に明白であるため、

Cat cat = new Cat(); // cat Object

すべての初心者プログラマが、コードにコメントを付けることが必ずしも良いことではないことにすぐに気づくわけではありません。コードがさらに乱雑になり、読みにくくなるからです。コードが変更されたのにコメントがなかったらどうなるでしょうか? 彼は私たちを欺き、混乱させるだけであることがわかりました。ではなぜそのようなコメントがあるのでしょうか？通常、適切に記述されたコードには、コード内のすべてがすでに明白で読みやすいため、コメントする必要はありません。コメントを書いたということは、すでにコードの読みやすさを損なっているため、何とか状況を滑らかにしようとしているということになります。最善のアプローチは、最初にコメントを追加する必要のない読みやすいコードを作成することです。また、メソッド、変数、クラスの正しい命名についても言及せずにはいられませんでした。これは、私自身が遵守しているルールです。 最高のコメントは、コメントがないこと、その代わりに、これを明確に説明する正しい命名です。またはアプリケーションのその機能。

12. 不適切なネーミング

初心者はクラス、変数、メソッドなどの名前を偽ることがよくあります。たとえば、その目的をまったく説明していない名前のクラスを作成する場合です。あるいは、変数がxのような短い名前で作成され、さらにnとyという名前の 2 つの変数が作成されると、 x が何をするのかを思い出すのが非常に困難になります。このような場合、そこで何が起こっているかを単純に理解するために、コードについて注意深く考え、この機能を顕微鏡で (おそらくデバッガーを使用して) 研究する必要があります。ここで、上で述べたコード内の正しい名前付けが役に立ちます。名前が正しく機能を説明する方法を使用する方がはるかに簡単であるため、名前が正しいとコードの可読性が向上し、それに応じて慣れるまでの時間を節約できます。コードでは、すべては名前 (変数、メソッド、クラス、ファイル オブジェクトなど) で構成されます。この点は、正しくクリーンなコードを作成する場合に非常に重要になります。名前は、たとえば、変数が存在する理由、その機能、使用方法などの意味を伝える必要があることを覚えておく価値があります。そして、変数を説明するための最良のコメントは、その正しい名前であることを何度も指摘します。コメントと正しい名前付けについてさらに詳しく調べるには、時代を超えた古典である「クリーンなコード」を読むことをお勧めします。作成、分析、リファクタリング」、ロバート・マーティン。以上で、この記事の前半部分（考察）は終了となります。 つづく…