コーディングは簡単、自転車に乗るのと同じだとよく言われます。しかし、プログラミングは実際にはバイクのようなもので、非常にパワフルで高速です。コーディングでは、自転車に乗るのと同じように、責任感と意識を持ってサドルから外れないようにする必要があります。そして、勝者になるにはその倍の努力が必要です。実際、ライダーとプログラマーは同じ初心者のミスを犯します。初心者は、高速で強力なツールと革新的なトリックに重点を置き、それだけが真のマスターを定義すると信じがちです。この考え方は、初心者が自分の職業の複雑さと重要性を理解できない「ダニング・クルーガー効果」によるところが大きいです。幸いなことに、経験を積むと、最も熱心な初心者でも、プログラミングの技術には最適なアルゴリズムを選択する以上のことが含まれることに気づきます。この記事では、プログラマーにとって本当に重要なことと、新人開発者と熟練開発者の両方がソフトウェアを作成し、コードを記述する際に覚えておくべきことについての私の考えを共有したいと思います。 読みやすさはパフォーマンスよりも重要ですが、必ずしもそうとは限りません 典型的な初心者のバイク乗りは何から始めるのでしょうか? 数字とガジェットです。パワー、トルク、1/4マイルで理論上のミリ秒を稼ぐためのパフォーマンスパーツ...まるでMotoGPのスターティンググリッドに着くかのようです。その間、彼らの主な仕事は安全に乗る方法を学ぶことです。同じように、初心者の開発者は、不必要なコードパフォーマンスに固執することがよくあります。Pythonでは`dict()`と`{}`のどちらがより効率的かを議論する記事や、パフォーマンスを低下させる可能性があるにもかかわらずフレームワークを使用することの長所と短所を議論する記事は、この執着に火をつけます。プログラミング言語の複雑さを理解することは有益であり、飛行機、株取引ロボット、医療機器などのソフトウェアでは時には不可欠ですが、私たちが毎日作成するプログラムの大多数にとって必ずしも重要ではありません。パフォーマンスが重要なソフトウェアに取り組んでいる場合でも、コードのどの部分に高いパフォーマンスが必要で、どの部分がそうでないかを把握することが不可欠です。 しかし、常に重要なのはコードの読みやすさです。多くの研究や調査により、開発者はコードを書くよりも読んで理解することに多くの時間を費やしていることが確認されています。例えば、 IDEで費やされる時間のうち、コードの編集に使われるのはわずか4%であることがわかりました。 250,000 人以上の開発者を対象にした調査によると、回答者が 1 日にコードを積極的に書くのに費やしている時間はわずか 52 分程度であることが明らかになりました。残りの時間はプロジェクトの議論や計画に費やされ、IDE でのコードやプロジェクト ドキュメントの読み取りには約 41 分が費やされています。 「あなたが去年の夏に何をしたか知っています - 開発者が時間をどのように過ごしたかの調査」 グローバルコードタイムレポート ほとんどの場合、私たちの目標は、複雑なサポートを必要とせず、競争の激しい環境で成功する保守可能な製品を作成することです。これは、パフォーマンスを完全に無視できるという意味ではありません。保守性とパフォーマンスが共存するバランスを見つける必要があります。高パフォーマンスのコードが必要な場合は、プロジェクトの立ち上げ後に遅いセクションを最適化できます。 また、コンパイラとインタープリタは進化しますが、コードは変わらないということも覚えておいてください。あるコンパイラ バージョン用に書かれた、超最適化された魔法のコード スニペットが、別のコンパイラ バージョンでは意味のない役に立たないコードになることがあります。さらに、将来の開発者 (あるいはあなた自身) も、そのコードで作業する必要があります。では、パフォーマンスのために読みやすさを犠牲にすべきなのはいつでしょうか。 読みやすさよりもパフォーマンスを優先するタイミングを特定するには、アプリケーションのボトルネックを正確に特定する必要があります。 : プロファイリングによって、特定の重要なコード セクションがパフォーマンスに大きな影響を与えることが判明した場合、これらのフラグメントを最適化することで、読みやすさを低下させることが正当化される可能性があります。 アプリケーションのプロファイリング : 高負荷をシミュレートすると、実際の問題になる前にパフォーマンスのボトルネックを特定するのに役立ちます。 負荷テスト : ユーザーからのフィードバックを収集すると、パフォーマンスが低い領域が明らかになります。 ユーザー フィードバック分析 : 実行ログとメトリックを分析すると、アプリケーションの実際の操作中に問題のある領域を特定できます。この段階では、パフォーマンスの問題を引き起こす不適切な API の使用など、予期しない問題が明らかになる可能性があります。 ログ記録と監視 : 一部のツールは、コードレビュー中にパフォーマンスの改善を提案できます。タスクレビュー中にこれらのツールを自動的に実行することは良い習慣です。 静的コード分析ツール これらのヒントは、アプリケーションの弱点を特定し、必要な最適化に集中するのに役立ちます。私の個人的な経験に基づくと、これらの最適化には特殊な言語構造が含まれる可能性は低く、データベースのやり取りや外部 API の使用の最適化が含まれる可能性が高くなります。 文書化することで、行われた作業を理解するのに役立ちます 道路に出ているとき、安全に関する重要なスキルの 1 つは、予測可能であることと、同様に他人の意図を読み取ることです。コーディングでは、自転車に乗るときと同様に、他人の心を直接読むことはできません。2 輪車では、微妙な動きに気づき、次の瞬間に他人が何をするかを予測する必要があります。プログラマーは、テレパシーに代わる強力なツールを持っています (ただし、常に使用しているわけではありません)。それは書類です。ほとんどの開発者は、ドキュメントがプロジェクトにとって重要であることに同意しています。これは、次のような調査からも明らかです。 では、回答者の90.36%が技術文書を定期的に使用しています。しかし、そこですべての答えを見つけることができず、代わりにStack Overflow (82.56%) やさまざまなブログ (76.69%) に頼ることがよくあります。別の調査では、 によると、開発者は 1 日の 1 ～ 2% をドキュメント作成に費やしており、回答者の 10.3% が書類の質の悪さや古さのせいで多くの時間を失っています。 Stack Overflow 開発者アンケート 2023 Microsoft Research: ソフトウェア開発者の日常生活 ドキュメントには、Confluence などのシステムでの詳細なプロジェクトの説明から、コード コメント、自動または半自動で生成されるプロジェクトの説明 Web サイトまで、さまざまな形式があります。プロジェクトのルート ディレクトリにある README ファイルのようにシンプルなものでもかまいません。形式に関係なく、ドキュメントを作成するプロセスは、製品の動作に関する情報を伝えるだけにとどまりません。このプロセス 、API や全体的なアーキテクチャの改善につながることがよくあります。作成した機能をドキュメント化すると、操作が難しい可能性があることに気付くことが多く、それを修正する方法を見つけました。 により、これまでに行ったことを再考することになり ドキュメントの維持には、常に多大な労力が必要であることを覚えておくことが重要です。特に、プロジェクトが頻繁に変更される段階にある場合はなおさらです。このような場合は、すべてのリスクを検討し、どのロジックをドキュメント化するかを慎重に検討する必要があります。プロジェクトが成熟した状態に達している場合は、優れたドキュメント化によって、課題よりもメリットの方が多くなります。新しい開発者はより早くオンボーディングして勢いをつけることができ、長年の従業員は特定の機能の仕組みをすぐに理解できます。さらに、多くのチームがある大規模なプロジェクトでは、優れた検索機能を備えたドキュメントによって、機能の重複を防ぐことができます。 自分が何をしているかを他人に話すことは恥ずかしいことではない 方向指示器の使用は、予測可能なライダーになるための最も基本的な方法です。同様に、コードにコメントを付けることは、おそらく自分が何をしているかを他の人に伝える最も簡単で直接的な方法です。そして、ウィンカーの使用と同様に、コメントを付けてもクールさが損なわれることはありません。コードは自明であるべきなのでコメントは不要だという一般的な考えがあることは知っています。しかし、私はそれに完全には同意しません。質の高いコードは、変数や関数の適切な命名、明確な構造、クリーンなコード原則の順守により、直感的に理解できることがよくあります。ただし、そのような場合でも、よく考えられたコメントは貴重な情報を提供できます。 コメントは、理解するために追加のコンテキストを必要とする複雑なアルゴリズムやソリューションの場合に重要な役割を果たします。コメントは、コード自体からは必ずしも明らかではないアプローチの背後にある を説明できます。これは、コードがパフォーマンスのために最適化されているが、その意図とロジックがすぐには明らかでない場合に特に重要です。コメントは、選択したアルゴリズムが正しい方向に進んでいるかどうかを再検討するのにも役立ちます。 「理由」 コメントは、複雑なビジネス ロジックやプロジェクト固有の要件において、新しいチーム メンバーや長期プロジェクト サポートの場合には明らかでない可能性がある場合に、非常に役立ちます。コメントは、チーム内で知識を保持し、開発者間でプロジェクトを転送しやすくするのに役立ちます。 もちろん、コメントが明白なことを述べたり、古くなったりして誤解を招くようなコメントは避けることが重要です。コメントの目的は、コードを不必要な情報で混乱させることではなく、明確さを確保して理解しやすくすることです。 テスト: コードの理解と検証のためのツール さて、ようやくバイクの乗り方を学んだので、今度は実際のレース トラックで運試しをしてみようとします。実際のレースは、単に「ペダルを全開に」できるというだけではないことがすぐにわかります。トレーニングとテスト、そして自分の習慣やレース条件に合わせてマシンを微調整することが必要です。同じことがコードにも当てはまります。実際の走行に出す前に、徹底的に試し、テストし、必要に応じて修正する必要があります。したがって、最大限の責任を持ってコード テストに取り組むことが重要です。テストは、単にバグを見つけるツールと見なされることがよくありますが、その役割はもっと広範囲にわたります。 : テストにより、製品がユーザーに届く前にエラーや予期しない動作が特定され、品質が向上し、ユーザーの問題が軽減されます。 エラーと欠陥の検出 : テスト シナリオを作成するには、コードの構造と機能に関する深い理解が必要であり、プログラムのロジックと相互作用をより深く理解することが必要になります。 コードの理解 : テストは関数やメソッドの使用例として機能し、プロジェクトの機能に関する情報を見つけるのに役立ち、実際の使用例を提供することで新しいスペシャリストを支援します。 ドキュメント補足 効果的なテストは、高品質で信頼性が高く、理解しやすいコードを作成するために不可欠です。ただし、ドキュメント作成と同様に、テストは、特にプロジェクトの初期段階では、多くのリソースを消費する可能性があります。テストの必要性と、時間とリソースの制約とのバランスを取ることが重要です。 複雑なコードに対する完全なテスト カバレッジは、単純には達成不可能であることも明らかです。したがって、開発者は、終わりのないテスト サイクルを回避するために、いつ停止するかを把握しながら、主要な機能と重要なコード セクションのテストを優先する必要があります。 友達を愛するようにコードを愛し、大切にしましょう 最後に、適切なメンテナンスがなければ、バイクは信頼できません。ライディングのこの側面を無視する人は少なくありませんが、彼らは私たちが絶対に関わりたくない話（面白いものから怖いもの、悲しいものまで）を作り上げます。プログラミングの世界では、バイクと同じように、コードのメンテナンスは単なる推奨事項ではなく、特に長期プロジェクトでは必須です。メンテナンスと更新が不足すると、製品の陳腐化とセキュリティの脆弱性につながります。 コードが最新のコンパイラやインタープリタとの互換性のために更新されていない場合、更新はますます困難になる可能性があります (実際に困難になります)。デスクトップまたはモバイル アプリケーションを開発している場合、製品は新しい OS バージョンで動作しなくなる可能性があります。Web サイトの場合、ツールやテクノロジが古くなったために機能しなくなる可能性があります。最も単純な問題は、セキュリティ証明書の期限切れや、更新用のソフトウェアが古くなったことです。 定期的な更新とリファクタリングも、コードの可読性を維持するために重要です。これにより、プロジェクトが管理しやすくなり、将来の変更や機能の追加が簡単になります。 要するに、自分のコードを愛し、それに時間を費やすということです。ただし、やりすぎはいけません。そうしないと、「ゼロ定理」の主人公のようになってしまいます。頑張ってください!
