誰も教えてくれないプログラミングの原則

日本語العربيةDeutschEnglishEspañolFrançaisहिन्दीBahasa Indonesia한국어PortuguêsРусский中文
TThe Coding Koala
Computing/SoftwareManagement

Transcript

00:00:00なぜ多くの人が、長年この分野で働いているにもかかわらず
00:00:04成長できないのでしょうか？それには様々な要因があります。その理由の一つは
00:00:09プログラミングの根本的な原則を理解していないことです。これらは一度学んで
00:00:14忘れてしまうような単なる理論ではなく、開発者として実際に成長するために不可欠なものです。
00:00:19まず第一の原則、「ボーイスカウト・ルール」から始めましょう。これはアメリカのボーイスカウトから来ています。
00:00:25彼らには「キャンプ場を訪れた時よりも綺麗にして去る」というシンプルなルールがあります。
00:00:31「アンクル・ボブ」を知っている人はどれくらいいるかわかりませんが、彼がこの概念を
00:00:36プログラミングコミュニティに広めました。つまり、コードを触る前よりも少し綺麗にしてから去るという習慣です。
00:00:41既存のコードベースに変更を加えると、しばしばコード品質が低下し、
00:00:47技術的負債が増えることがあります。この技術的負債は、どんなに小さなことであっても
00:00:52継続的な改善によって減らすことができます。例えば、ある関数に
00:00:57変更を加えるタスクを割り当てられたとします。変更は完了しましたが、変数の名前が十分に
00:01:03分かりにくいことに気づきました。多くの開発者のように、それを無視して割り当てられた変更だけをコミットすることもできます。
00:01:08しかし、この原則に従うなら、変数名をより分かりやすいものに
00:01:12修正するはずです。これは単なる例ですが、変数名に限らず、改善できる箇所があれば
00:01:18修正してください。この小さな心がけが、コードベースにとって非常に価値のあるものになります。
00:01:24第二の原則、「早期最適化を避ける」です。これは、コードを
00:01:30実際に速くする必要が生じる前に、速くしようとすべきではないという意味です。まず動くものを作り、必要ならその後に最適化してください。
00:01:36ドナルド・クヌースの有名な名言に「早期最適化は諸悪の根源」という言葉があります。
00:01:42これは真実です。なぜならプログラマーは、プログラムの重要でない部分の速度を心配することに
00:01:47多くの時間を浪費してしまうからです。何でもかんでも最適化したがる傾向があるからです。
00:01:51この原則は、コードベースの最適化を否定するものではありません。何を最適化すべきか、
00:01:57そして最も重要な「いつ」最適化すべきかを理解することについてです。多くの開発者の弱点だと思いますが、
00:02:03ユーザーが100人しかいないのにマイクロサービスを使ったり、全く不要な場所にキャッシュを追加したりする人を見かけます。
00:02:08第三の原則、「メンテナンスする人のためにコードを書く」です。これは単純に、あなたが書くコードを
00:02:14将来メンテナンスする開発者が、理解や管理に苦労しないような書き方をすべきだという意味です。
00:02:19あなたが今日書くコードは、将来の他の開発者や、あなた自身によってメンテナンスされます。
00:02:23もし単に動くことだけを優先して明快さを無視すれば、将来そのコードに戻ったとき、
00:02:29何が起きているのか理解するのに苦労するでしょう。例えば、
00:02:35この例を見てください。どちらも同じ機能を実現しますが、自分のコードベースで
00:02:39どちらを見たいですか？教訓は、自分でコードを書く時もAIで生成する時も、
00:02:45コミットする前に、必ず理解しやすくメンテナンス可能なコードであることを確認するということです。
00:02:50第四の原則は「YAGNI」です。「You Aren't Gonna Need It（それは必要にならない）」の略です。
00:02:55これは、「将来必要になるかもしれない」という理由だけで、実際に必要ではないものを作るべきではない、
00:03:01という意味です。多くの開発者は将来何を必要とするか予測する癖がありますが、
00:03:06結局それらのほとんどは使われず、プロジェクトに不要な複雑さを加えるだけだからです。
00:03:10常にこれを忘れないでください。今必要ではない将来の機能に時間を割いているということは、現在必要な機能に時間を割けていないということです。
00:03:16第五の原則、「最も単純な解決策を選ぶ」です。
00:03:21これは、問題に直面したとき、実際に機能する中で最もシンプルな解決策を選ぶべきだという意味です。
00:03:27考えすぎたり、過剰なエンジニアリングをしたりしないでください。「今これを解決する最もシンプルな方法は何か？」と自問してください。
00:03:32この考え方はエクストリーム・プログラミングから来ています。まずはシンプルなものを構築し、
00:03:38それをリファクタリングしてより良いものにするよう教えています。ほとんどの開発者は気づいていませんが、
00:03:43最初から完璧なソリューションを構築しようとして、結果的に解決策を過度に複雑にしてしまっています。
00:03:48この原則に従えば、より早く動くコードを手に入れられます。後で変更が必要になったとしても、
00:03:53間違った複雑な設計を修正するよりも通常は簡単です。そして、
00:03:59自分が過剰な設計をしていると気づくことは、開発者として非常に重要です。
00:04:04以上が、今すぐ実践すべき5つのプログラミング原則です。
00:04:10これら以外にも、この動画ではカバーしていない原則が他にもあります。
00:04:14もしこれが役に立ったならコメントで教えてください。第2弾を作成します。
00:04:19今回はここまでです。応援のほどよろしくお願いします。それではまた次回お会いしましょう。
00:04:24（エンディングの挨拶）

Key Takeaway

プログラミングにおいて、早期最適化や不要な機能の先取りを避け、常に現在必要とされる最もシンプルな実装を維持することが、長期的な開発効率とメンテナンス性を高める。

Highlights

  • ボーイスカウト・ルールに従い、コードを触る際は前回よりも綺麗にしてから去ることで技術的負債を削減できる。

  • 最適化は、実際に速度低下が問題になるまで行わないことで、不要な作業時間を排除できる。

  • 将来のメンテナンス担当者や自分自身が理解できるコードを書くことが、中長期的な管理コストを低減させる。

  • YAGNI（You Aren't Gonna Need It）の原則を適用し、現在必要のない機能の構築に時間を割かない。

  • 問題解決時は最初から完璧を求めず、最もシンプルな実装から始めてリファクタリングを行う。

Timeline

ボーイスカウト・ルールと技術的負債の解消

  • コードベースに触れる際は、作業前よりもコードを綺麗な状態にして終了する。
  • 変数の命名改善など、些細な修正の積み重ねが技術的負債の増加を防ぐ。

キャンプ場を訪れた時よりも綺麗にして去るというボーイスカウトの概念を適用する。機能を変更する際にコードの質を落とすのではなく、少しでも改善できる箇所を見つけて修正する習慣が、長期的なコードベースの価値を決定する。

早期最適化の弊害

  • 実際に速度が必要になるまではコードを最適化しない。
  • 不要なキャッシュや過剰なマイクロサービスの導入は時間を浪費する原因となる。

プログラムの重要でない部分の最適化に時間を割くことは避ける。何を最適化すべきかだけでなく、ユーザー数が少ない段階で過剰な設計を行わないという『いつ』最適化すべきかを見極める判断力が重要である。

保守性と将来を見据えたコード作成

  • 将来そのコードを修正する開発者が理解しやすいコードを書く。
  • コードの明快さを優先させ、理解困難な実装をコミットしない。

今日書いたコードは、自分自身を含めた将来の開発者によってメンテナンスされることを意識する。動くことだけを優先して明快さを無視すると、後に理解するコストが大幅に増大する。

YAGNIと最もシンプルな解決策

  • 将来必要になるかもしれないという理由だけで機能を追加しない。
  • 問題解決の際は、過剰なエンジニアリングを避け、現在機能する最もシンプルな手法を選ぶ。

予測に基づいて機能を構築すると、プロジェクトが不要に複雑化する。将来の機能に時間を割くことは、現在必要な機能を開発する時間を奪うことになる。まずはシンプルに構築し、その後にリファクタリングで洗練させることが、過剰設計を防ぐ最良の戦略である。

Community Posts

No posts yet. Be the first to write about this video!

Write about this video