本記事は、Daan氏による「15 Mistakes Every Developer Has Made in Their
Life」（2020年11月16日公開）の和訳を、著者の許可を得て掲載しているものです。
すべての開発者が人生でおかした15の間違い
あなたもおそらく関係しているでしょう
Photo by Chris Ried on Unsplash
##はじめに
間違いをおかすのが人間であり、実はそれが私達を成長させるものなのです。間違いを恐れてはいけません。このリストにあるような多くの間違いをおかしているかもしれません。そうでないならそれは素晴らしいことです。自分で間違う必要がないように、他の開発者の間違いから学ぶようにしましょう。
####1. 寿命が長いコードをやっつけ仕事で修正すること
その問題点は、コードベースの品質を損なうことです。このような解決策は、不必要な技術的負債を増やす可能性があります。長期的には、やっつけ仕事の修正があなたを痛い目に遭わせるでしょう。そしておそらく将来的にリファクタリングすることになるでしょう。
####2. 実践不足
誰もが知っているように、実践すればするほど完璧になります。そのため開発者として成長したいのであれば、もっと実践を積む必要があります。あなたがおかし得る最大の間違いは、折々に新しいことを学ばないことです。プログラミング言語のような、何か新しいことを学びたいと思ったら、日常業務外で学ぶ必要があるかもしれません。それは自分自身への投資で、己の価値を維持するために必要です。
####3. 作業量を過少評価すること
作業量の見積は、ソフトウェア開発における最も難しいことの一つです。スクラムのリファインメントで「この機能は1ストーリーポイントで簡単に実行できる」という話を聞いたことがあるでしょうか？物事はそう簡単にはいかず、意図した解決策がうまくいかない可能性があります。見積は、テストなどにも時間を割くようにしましょう。これは開発者のためだけではありません。
####4. 分かり切ったコメントを書くこと
私達は皆、このようなコメントを見たことがあります。それは何も説明しておらず、コードがしていることに着目しているだけです（例えば、foreachループに「製品をループする」のようにコメントする）。そのような場合、コードが何をしているかではなく、なぜしているかに着目したコメントを書くようにしましょう。
####5. コードブロックをコメントアウトすること
私達は皆、複数の関数を含むコードブロック全体がコメントアウトされているのを見たことがあります。それがなぜまだ存在しているのか、まだ関連があるのかは誰にも分かりません。誰もそれを削除しない理由は、他の誰かが必要かもしれないと、誰もが想定しているからです。コメントアウトされたコードブロックを削除するだけで済みます。それがまだ必要だと判明した場合は、バージョン管理下に置きます。
####6. ハッピーパスのシナリオだけテストすること
テストを記述する場合は、ハッピーパスだけでなく、それ以上のことを考慮する必要があります。意図した通りに機能しないシナリオを考えてください。最悪のシナリオは何ですか？そのシナリオも必ずテストしてください。
####7. コードの乱雑なフォーマット
これは経験の浅い開発者が最もよくおかす間違いです。コードを読みにくくし、あなたのコードを読まなければならない他の開発者を苛立たせます。乱雑なコードの修正は、コードをフォーマットするリンターをインストールすることで可能です。
####8. 関連情報をログに記録しないこと
有益なログは、開発者にとって大きな助けになります。ログメッセージがあることで、コード内のどこで問題が発生したかについて、多くの洞察を得ることができ、デバッグ時間を大幅に節約することができます。優れたログメッセージは、特定のエラーが発生した時に、ユーザが何をしていたかというコンテキストを教えてくれます。
####9. 知識不足による再開発
この間違いは、フレームワークで既に利用可能なものを開発者が知らない場合に起こります。この知識不足の結果、利用可能なメソッドとほぼ同一のものを開発者が実装してしまいます。
####10. 解決策を知らずにコードを書き始めること
最初は、ワクワクするように見えるかもしれませんが、これはあなたを痛い目に遭わせます。コードの計画と整理は、コーディングの重要な部分です。無計画にコーディングを開始すべきではありません。途中で見つかり得る問題と、それに取り組む方法を考えましょう。そうすることで、コーディングの前に考えるべきことがたくさんあるという事実に気付くことができます。
####11. 悪いコミットメッセージを書く技術
これはおそらく誰もがおかしている間違いでしょう。「バグの修正」や「WIP」は良くありません。適切なコミットメッセージがあることは重要であり、時間をかけて良いものを書くべきです。優れたコミットメッセージは、変更箇所と理由について有益な情報を提供します。改訂履歴は、コードが実際に正常に機能しなくなった場合に間違っている箇所を素早く正確に見つけるための素晴らしいリソースです。
####12. コード内にマジックナンバーを含めること
マジックナンバーとは、意味が明らかではない一意の値や複数回出現する値のことで、名前付き定数で置換できます。マジックナンバーの問題は、理解できないことと、開発者にコンテキストが与えられないことです。その上、プログラム内の様々な場所で複数回使用されることが多く、エラーが発生しやすくなります。
####13. 1つの関数内で複数の処理を行うこと
1つの関数には1つの処理だけをさせるようにしてください。1つの関数にデータのフェッチ、処理、出力をさせないでください。それぞれを異なる関数に分割します。1つはフェッチ、1つは処理、1つは出力です。1つの関数を1つの処理に集中させることで、より堅牢なものになります。
####14. 自動テストを作成しないこと
最初は、自動テストを作成し始めると、手動テストより少し時間を要します。長期的には自動テストの作成に時間を割いたことを喜ぶことになるでしょう。すべてを手動でテストするのは退屈で時間がかかり、人的要因によるエラーが発生しやすくなります。
####15. 処理を不必要に複雑にすること（別名オーバーエンジニアリング）
特定のデザインパターンを実装することは、大多数の開発者が経験済みです。デザインパターンを実装する機会があるからといって、その必要があるとは限りません。これによりコードベースに技術的負債を増やすことになります。
##翻訳協力
Original Author: Daan
Original Article: 15 Mistakes Every Developer Has Made in Their Life
Thank you for letting us share your knowledge!
この記事は以下の方々のご協力により公開する事ができました。改めて感謝致します。
選定担当: @gracen
翻訳担当: @gracen
監査担当: Taki
公開担当: @gracen
##ご意見・ご感想をお待ちしております
今回の記事は、いかがだったでしょうか？
・こういう記事が読みたい
・こういうところが良かった
・こうした方が良いのではないか
などなど、率直なご意見を募集しております。
頂いたお声は、今後の記事の質向上に役立たせて頂きますので、お気軽に
コメント欄にてご投稿ください。Twitterでもご意見を受け付けております。
皆様のメッセージをお待ちしております。