初心者プログラマが犯すよくある間違いの分析、pt. 1

こんにちは世界！知っておくべきことをすべて学び、最終的にインターンまたはジュニア開発者として働くことができたら、おそらくリラックスできるでしょう? いいえ。あなたにとってすべてが始まったばかりです...あなたは新しくて理解できないものに囲まれています。どうすれば最初から台無しにならないでしょうか？今日はそれについて話します。この記事では、新人のよくある間違いを分析し、それを回避する方法について、私自身の経験に基づいてアドバイスしたいと思います。 それでは、さっそく始めましょう。

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

私たちは皆人間です。私たちは皆、特に新しく経験豊富な同僚の目に愚かに見えることを恐れています。開発者が初めての仕事に就くとき、多くの場合、この恐怖に導かれ、重く聞こえて自分の中に引きこもり、すべてを自分たちで理解しようとします。さらに、経験豊富な同僚に囲まれることで、その人を最も有望な方向に導くことができ、さらなる間違いや不必要な「頭をぶつける」ことを避けることができます。ですから、質問することを恐れないでください。あなたは初心者であり、誰もがこれを完全に理解しています。あなたが尋ねたとき、誰もあなたを棒で殴るつもりはありません。もしかしたら、その逆のことさえ起こるかもしれません。同僚とより早く友達になり、より積極的なコミュニケーションを楽しむようになるでしょう。私' さらに言えば、さまざまな技術的な問題について質問したり議論したりすればするほど、より早く初心者の皮を脱いで、その分野の専門家に成長することができます。そして、もう一つアドバイス。見知らぬ人にならないでくださいスタックオーバーフロー。特に、このリソースに関する質問について話しています。一方で、あなたの質問に対する答えを得るには時間がかかります。しかしその一方で、問題を解決するための複数のアプローチをすぐに学び、少し異なる角度から問題を見ることもできます。また、他の開発者からの StackOverflow の質問に対してコメント/回答を書いたり、明確な質問を書いたりすることには、実際的な利点があることにも注意したいと思います。カルマの向上は言うまでもなく、議論して問題を深く掘り下げる機会が得られます。

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

この間違いは、前の間違いの裏返しと考えることができます。ここで私が言いたいのは、遭遇したあらゆる問題や問題について同僚や知人を困らせ始めたときのことです。質問するのは良いことですが、過度に質問しないでください。そうしないと、人々はあなたのことを単に迷惑だと思うかもしれません。何かについて混乱した場合、最初にすべきことは、最高の検索エンジンである Google で検索スキルを発揮することです。理解できないエラーやその他の問題の圧倒的多数に、すでに誰かが遭遇しています。そして、あなたの質問を Google で検索すると、同様の問題に精通しており、自分の仕事に適用できる徹底的な回答をすでに受け取っている人の数を確認すると、非常に驚​​くでしょう。同僚が「Google で調べてください」と答えるのをよく聞くのはそのためです。ドン' この答えに腹を立てないでください。同僚は、あなたの仕事分野の微妙な点をすべて伝えなければならないあなたの個人教師ではありません。無限に広がるインターネットがあなたのメンターとなるでしょう。プログラマーは、次のように呼ばれることもあります。Google 検索で黒帯を持っている人。したがって、「しゃっくり」が発生した場合は、まずその問題をグーグルで検索します。解決策が見つからない場合 (これはまれですが、実際に起こります)、そのときになって初めて、同僚に質問し始めます。即時の質問は、速度の上昇や理解できないエラー メッセージに遭遇したときにどのような対処をするかよりも、問題を解決するためにどのアプローチを選択する必要があるかについてアドバイスを求めるためのものです。結局のところ、彼らはあなたの好みのアプローチを超えて、特定のアプローチが長期的にどこにつながるかを即座に予測できるかもしれません。

3. やみくもにコピー＆ペーストする

しかし、問題とその解決策をグーグルで検索することには落とし穴があります。たとえば、やみくもにコピーして貼り付けるなどです。これは通常、StackOverflow などで同様の問題 (ただし、まったく同じではない可能性があります) と関連する解決策を見つけたときに発生します。このソリューションを取得して、詳細を詳しく調べることなく、コピーして貼り付けます。そして、あなたまたはあなたの同僚は、コード内の奇妙なバグや不正な動作を発見します。そして、彼らがどこから来たのかをすぐに推測できる人は誰もいません。もちろん、最終的にはコードがコピーされた場所が見つかることになりますが、その解決策は間違いなく賞賛されません。したがって、StackOverflow (または他の場所) で既製のソリューションを見つけた場合は、まず、何を、どのように、そしてなぜするのかを徹底的に理解する必要があります。おそらく、Google で関連する機能を検索し、そのドキュメントを読んでください。それが完了した後でのみ、それをプロジェクトに追加する必要があります。

4. 間違った解決策に固執する

ソリューションを作成していると、ソリューションがどんどん複雑になり、最終的には行き止まりに達してしまうことがあります。そして、別のより適切な代替案を探すのではなく、なんとか機能させるために、ソリューションをさらに複雑にしようとします。もしかしたら、あなたは多くの時間と労力を費やしたので、何があっても諦めず、既存のアプローチで問題を解決しようと決心したと感じているかもしれません。これはまったく正しい態度ではありません。少なくともプログラミングにおいては。別のアプローチを早く試すほど、最終的にはより多くの時間を節約できます。したがって、現在のアプローチにどれだけの時間を費やしたかに関係なく、他のアプローチを試して実験することを恐れないでください。さらに、複数のアプローチを試し、その主題をより深く掘り下げることで、

5. 現在の任務について質問することへの恐怖

ソフトウェア開発プロジェクトでの作業は、通常、特定のタスクを実行することに要約されます。たとえば、 Jiraでは。これらのタスクは、必ずしも明確かつ詳細に概要が説明されているわけではありません。タスクの説明は通常、単なる人間であるチーム リーダーによって書かれます。彼らは何かを追加することを忘れたり、あなたがあれこれの機能に精通していないという事実を説明できない可能性があります。または、プロジェクトへのアクセス権 (データベース、ログ サーバーなどへのアクセス権など) がない可能性があります。そして今、あなたはタスクを受け取り、数時間以上勉強しましたが、まだそこに座って、困惑して画面を見つめています。これを理解しようとして失敗し続けるのではなく、タスクを作成した人に説明や指導を求め始めるべきです。たとえば、チームがコミュニケーションに使用するアプリ (Microsoft Teams など) では、タスクに関して質問したり、直接コメントしたりすることがあります。一方、個人的なメッセージに質問を書いた場合、相手はあなたの質問をすぐに見ることができるため、おそらくより早く回答が得られるでしょう。一方、Jira で質問すると、何かを行っている、つまり問題を分析しているという証拠が確立されます。このプロセスを加速する方法があります。Jira のコメントで質問してから DM で質問し、コメントへのリンクをドロップして見てもらうよう依頼します。

6. チームリーダーに非現実的に高い期待を寄せる

繰り返しますが、これは前のポイントの裏返しです。チーム リードは開発チームの責任者です。通常、チーム リーダーは、さまざまな種類のコミュニケーションにほとんどの時間を費やします。それでも、プログラミングに関するすべてを忘れないようにコードも書きます。ご存知のとおり、チームリーダーの生活は非常に忙しいです。くしゃみをするたびにチームリーダーの袖を引っ張るのは、明らかに気分の良いものではありません。チームのメンバー全員がリーダーに大量の質問をぶつけているところを想像してみてください。それは誰でも気が狂う可能性がありますよね？そして、たくさんの質問が積み重なると、チームリーダーはあなたに答えるために多くの時間を費やす必要があります。チームリーダーに対する質問の数を減らすために何ができるか:

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

あるいは、IDE の注釈を参照して、特定の行のコードが最後に変更されたのは誰なのか、いつ変更されたのかを確認することもできます。そうすることで、あなたの質問に最も適した人を見つけることができるのです。おそらくすでにお気づきかと思いますが、チーム リーダーに質問する場合は、同僚に質問する場合と同じように、満足のいく媒体を見つけるように努める必要があります。質問することを恐れてはなりませんが、質問しすぎないように注意してください。そのうちの。

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

コードレビューこれは、コードを共通のアプリケーション (マスターまたは開発などの共有ブランチ) に送信する前に行われる段階です。このチェックは、タスクに関与していない開発者によって実行されます。開発者の新鮮な目で、最初にコードを作成したときに気付かなかったコード スタイルのエラー、不正確さ、または欠陥を検出できます。批判がある場合は、コードの特定の部分にコメントとして残されます。この場合、コードを書いた開発者は、レビューで特定されたエラーを修正する必要があります (または、自分の決定についてレビュー担当者と話し合って、場合によってはその決定が正しいことを納得してもらう必要があります)。その後、レビュー担当者からコメントがなくなるまで、コードは何度もレビューのために送信されます。レビューワは、コードがコミットされる前の「ゲートウェイ」として機能します。課題は、多くの初心者プログラマーがコードレビューを批判や非難として認識していることです。彼らはコードレビューを評価せず、コードレビューを恐れています。そうすべきではありません。コードレビューはまさにコードを改善するためのものです。結局のところ、私たちは自分たちが間違っていることや注意を払う価値があることについての重要な情報を受け取ります。各コード レビューは学習曲線の一部であり、上達に役立つものであると考える必要があります。誰かがあなたのコードにコメントするとき、その人は経験やベストプラクティスをあなたと共有していることになります。私は個人的に、コードレビューを受けずに優れたプログラマーになれるとは信じていません。なぜなら、自分のコードの品質や、経験豊富な部外者が間違いを指摘するかどうかさえわかっていないからです。コードレビューを評価せず、恐れています。そうすべきではありません。コードレビューはまさにコードを改善するためのものです。結局のところ、私たちは自分たちが間違っていることや注意を払う価値があることについての重要な情報を受け取ります。各コード レビューは学習曲線の一部であり、上達に役立つものであると考える必要があります。誰かがあなたのコードにコメントするとき、その人は経験やベストプラクティスをあなたと共有していることになります。私は個人的に、コードレビューを受けずに優れたプログラマーになれるとは信じていません。なぜなら、自分のコードの品質や、経験豊富な部外者が間違いを指摘するかどうかさえわかっていないからです。コードレビューを評価せず、恐れています。そうすべきではありません。コードレビューはまさにコードを改善するためのものです。結局のところ、私たちは自分たちが間違っていることや注意を払う価値があることについての重要な情報を受け取ります。各コード レビューは学習曲線の一部であり、上達に役立つものであると考える必要があります。誰かがあなたのコードにコメントするとき、その人は経験やベストプラクティスをあなたと共有していることになります。私は個人的に、コードレビューを受けずに優れたプログラマーになれるとは信じていません。なぜなら、自分のコードの品質や、経験豊富な部外者が間違いを指摘するかどうかさえわかっていないからです。間違ったことをしているのか、注意を払う価値があるのか​​。各コード レビューは学習曲線の一部であり、上達に役立つものであると考える必要があります。誰かがあなたのコードにコメントするとき、その人は経験やベストプラクティスをあなたと共有していることになります。私は個人的に、コードレビューを受けずに優れたプログラマーになれるとは信じていません。なぜなら、自分のコードの品質や、経験豊富な部外者が間違いを指摘するかどうかさえわかっていないからです。間違ったことをしているのか、注意を払う価値があるのか​​。各コード レビューは学習曲線の一部であり、上達に役立つものであると考える必要があります。誰かがあなたのコードにコメントするとき、その人は経験やベストプラクティスをあなたと共有していることになります。私は個人的に、コードレビューを受けずに優れたプログラマーになれるとは信じていません。なぜなら、自分のコードの品質や、経験豊富な部外者が間違いを指摘するかどうかさえわかっていないからです。

8. 難解な決断をする傾向

さまざまなタスクや問題には、複数の異なる解決策があることがよくあります。そして、利用可能なすべての解決策の中で、初心者は最も複雑で難解な解決策を使用する傾向があります。それは当然のことです。初心者のプログラマーは、つい昨日、さまざまなアルゴリズム、パターン、データ構造を学習したばかりなので、それらのいくつかを実装したくてうずうずしているのです。信じてください、私もそうだったので、私が何を言っているのかわかります:) 私は、長い間、いくつかの機能を実装していた状況にありました。それは非常に非常に複雑であることが判明しました。その後、上級開発者が私のコードを書き直しました。もちろん、私は彼が何をどのように変えたかを見ることに非常に興味がありました。私は彼の実装を見て、それが非常に単純であることに驚きました。そして、コードは 3 分の 1 に減りました。また驚くべきことに、この機能の自動テストは削除または変更されていませんでした。言い換えれば、一般的なロジックは同じままでした。このことから、私は次のような結論に達しました最も独創的な解決策は常にシンプルです。このことに気づいてから、コーディングがはるかに簡単になり、コードの品質が大幅に高いレベルに上がりました。では、デザイン パターンや派手なアルゴリズムを適用する価値があるのはいつですか? それらを適用すると、最もシンプルでコンパクトなソリューションになります。

9. 車輪の再発明

ホイールは、ずっと前に発明された耐久性のあるソリューションです。このアンチパターンでは、開発者は、すでに解決されている問題に対して独自の解決策を実装します。場合によっては、これらの既存のソリューションの方が、プログラマーが思いついたものよりも優れていることがあります。一般に、車輪の再発明は時間のロスと生産性の低下につながります。これは、見つけた解決策が最善とは程遠いか、まったく見つからない可能性があるためです。そうは言っても、独自の独立したソリューションを作成する可能性を排除することはできません。作成した場合、残るのはコピー アンド ペーストのプログラミングだけです。プログラマは、既製のソリューションを使用するか、カスタム ソリューションを作成するかにかかわらず、発生する特定のプログラミング タスクを適切かつ迅速に解決するために、適切にガイドされる必要があります。一方では、大学やオンラインコースでは、車輪の再発明を助けるように設計されたと思われるさまざまな種類のタスクが私たちに浴びせられます。ただし、これは一見しただけです。ここでの本当の目的は、アルゴリズム的思考を開発し、言語構文をより深く習得することです。このようなタスクは、アルゴリズムやデータ構造をより深く理解するのにも役立ち、必要に応じて、より高度な対応物を実装するスキルを身につけることもできます (これは必要な場合もありますが、非常にまれです)。実際には、ニーズを満たすホイールは昔から存在しているため、ほとんどの場合、独自のホイールを発明する必要はありません。おそらく、経験が浅いため、必要な機能の実装の存在を知ることができません。ここで、この記事の最初のポイントで与えられたアドバイスを採用する必要があります。経験豊富な同僚に助けを求めてください。彼らはあなたをガイドしたり (たとえば、Google 検索で正しい方向を示したり)、特定の実装 (たとえば、ライブラリ) を提案したりできます。

10. テストの作成に失敗する

すべての初心者はテストを書くのが嫌いです。しかし、なぜここで初心者だけを取り上げる必要があるのでしょうか? 経験豊富な開発者もテストを書くことは好きではありませんが、なぜテストが必要なのかについてはよく理解しています。完全に青信号のときは、なぜそれらを書く必要があるのか​​疑問に思います。すべてが機能するので、間違いはあり得ません。しかし、変更によってシステム内の他の部分が破壊されないようにするにはどうすればよいでしょうか? 利益よりも害をもたらすような変更を押し込むと、同僚は感謝しません。ここでテストが役に立ちます。アプリケーションのコードがテストでカバーされる範囲が多ければ多いほど、より良い結果が得られます (これをコード カバレッジまたはテスト カバレッジと呼びます)。アプリケーションのテスト カバレッジが良好であれば、すべてのテストを実行して、コードによって破損する箇所を見つけることができます。そして、上の例で述べたように、上級開発者がコードをリファクタリングしたとき、テストは失敗しませんでした。大まかなロジックが変わっていないからだ。テストを使用して、特定の機能のロジックが変更されたかどうかを実証します。したがって、テストを書くのが好きではないとしても、テストは間違いなく便利であり、時間を費やす価値は十分にあります。

11. 過剰なコメント

多くの開発者は完璧主義に悩まされており、初心者も例外ではありません。彼らは、あらゆる人やあらゆるものについてコメントし始めるときに、この性向の一面だけを明らかにすることがあります。コードは非常に明白であるため、不必要なコメントを作成することさえできます。

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

すべての初心者プログラマが、コードのコメント化が常に良いとは限らないことをすぐに理解しているわけではありません。余分なコメントによってコードが乱雑になり、読みにくくなるからです。コードが変更されても古いコメントが更新されない場合はどうなるでしょうか? そうすれば、彼らは私たちを誤解させ、混乱させるだけです。では、そもそもなぜそのようなコメントをするのでしょうか？通常、コード内のすべてがすでに明白で読みやすいため、適切に記述されたコードにはコメントを付ける必要はありません。コメントを書く必要がある場合は、すでにコードの可読性が損なわれており、その状況を何とか改善しようとしていることになります。最善のアプローチは、最初から読みやすいコード、つまりコメントを必要としないコードを作成することです。また、メソッド、変数、クラスの正しい命名規則に従う必要性についても触れずにはいられません。私のルールは次のとおりです。 最良のコメントは、コメントなし、またはアプリケーションの機能を明確に説明する正しい名前のいずれかです。

12. 不適切なネーミング

初心者は、クラス、変数、メソッドなどの命名に関して、素早く、大雑把に考えます。たとえば、その目的をまったく説明していない名前のクラスを作成することです。または、 xのような短い名前で変数を宣言します。さらに 2 つの変数nとyを追加すると、が作成されると、x が何を担当するかを思い出すのが非常に困難になります。このような状況に直面すると、何が起こっているのかを単純に理解するために、コードについて注意深く考え、顕微鏡で分析し (おそらくデバッガーを使用して)、機能を研究する必要があります。ここで、上で述べた正しい命名規則が役に立ちます。名前が正しいとコードの読みやすさが向上し、その結果、コードを理解するのに必要な時間が短縮されます。名前がその機能をほぼ説明していると、メソッドの使用がはるかに簡単になるためです。コード内のすべては名前 (変数、メソッド、クラス、オブジェクト、ファイルなど) で構成されているため、正しくクリーンなコードを作成する場合、この点が非常に重要になります。名前は、変数が存在する理由、その機能などの意味を伝える必要があることを覚えておく必要があります。そしてそれがどのように使用されるか。変数に対する最良のコメントは、変数に適切な名前を付けることであることを何度も指摘します。コメントと正しい名前付けについてさらに深く学ぶには、時代を超越した古典を読むことをお勧めします。『クリーン コード: アジャイル ソフトウェア クラフトマンシップのハンドブック』 Robert Martin 著。ということで、この記事の前半部分（私の感想）は終わりました。つづく...