0
0

Clean Code の勉強会整理 - Chapter 1: きれいなコード

Last updated at Posted at 2024-08-03

現在、韓国でJavaバックエンド開発者として働いています。

将来的には日本で働きたいと思っており、会社で進めている勉強会の内容やSpringFrameworkの技術を日本語でまとめていこうと考えています。

その第一弾として Clean Code アジャイルソフトウェア達人の技 の内容を整理しようと思っていますが、すべての章を扱うのではなく、重要だと思う以下の部分だけをまとめようと思います。

  • Chapter 1: きれいなコード (Clean Code)
  • Chapter 2: 意味のある名前 (Meaningful Names)
  • Chapter 3: 関数 (Functions)
  • Chapter 5: フォーマットの整合性 (Formatting)
  • Chapter 7: エラーハンドリング (Error Handling)
  • Chapter 10: クラス (Classes)

日本ではどうか分かりませんが、韓国では開発者であれば必ず読むべき本の1位に挙げられている書籍ですので、私が整理した内容を共有したいと思います。

第1章 クリーンコード

第1章 クリーンコード

💡 クリーンコードの本を読んだ後に得られる能力
  1. 良いコードと悪いコードを区別する能力
  2. 良いコードを書く能力
  3. 悪いコードを良いコードにリファクタリングする能力

第1章の全体的な内容は、多くの優れた開発者の言葉を引用し、クリーンコードの重要性を強調する内容です。(ここから第1章の内容を詳しく見ていきます。)

1. コードは存在し続ける!

GPTのようなLLM(大規模言語モデル)が発達する前に、多くの人々が、要求仕様を実現するために開発者がコードを記述するのではなく、要求仕様を満たすプログラムを自動で生成できるようになると言っていました。

そんな馬鹿な!

この本の著者であり、世界中の人々から「コーディングの神」と称されるロバート・C・マーチン氏は、それがいかに馬鹿げたことであり、絶対にありえないことだと述べています。その理由は以下の通りです。

  1. 要求仕様を詳細に表現するためには、開発者のコードが必要である。
  2. コードの生成は単純な反復作業ではなく、創造性と直感を必要とする作業である。

2. 悪いコード

開発者たちは最初から良いコードを書いていたのでしょうか?

開発者たちが良いコードに関心を持つようになったきっかけは、長年にわたり、誰かが、または自分自身が書いた悪いコードに苦しんできたからです。

いくつかの会社は**「悪いコードのために最終的に破滅する」**こともあります。そのシナリオは次の通りです。

  1. 多くの人々が必要とするサービスを提供し、トラフィックが増え始める。
  2. この過程で、コードの品質よりも機能追加や迅速なリリースが優先される。
  3. 時間が経つにつれ、コードの複雑さが増し、保守が困難になり、あちこちで障害が発生し、最終的には手が付けられないレベルに達する。

私たち全員が、自分が書いた汚いコードを見つめながら、

  • 本当に!
  • 後で!
  • 本当に直すから!!

と誓った経験があるでしょう。しかし、「その後」は決して訪れません。

3. 悪いコードによる代償

悪いコードは開発のスピードを大きく落とします。プロジェクトの初期段階では非常に速く進行していたチームも、1〜2年後には亀のように遅くなることがよくあります。

悪いコードが積み重なるほど、チームの生産性は低下し、ついにはゼロに近づいてしまいます。(写真を参照)
image.png

3.1 偉大な革命の夢

ついに再設計が行われる。

このような汚いコードではもう仕事ができないと感じ、管理層に再設計を要求します。管理層は再設計にリソースを投入することに乗り気ではありませんが、生産性が底をついている事実を否定することはできません。

ついに再設計のためのタイガーチームが編成され、誰もがこのチームに参加したいと考えます。

今度こそ、最初から美しいコードを書けるチャンスだからです。

しかし、最も有能で賢い人々だけがそのチャンスを得ることができます。残りの人々は引き続き汚いコードをメンテナンスしなければなりません。

タイガーチームは既存のシステム機能をすべて提供する新しいシステムを立ち上げるだけでなく、その間に既存のシステムに加えられる変更もすべて追いかけなければなりません。

この話に共感できるのであれば、最初から時間をかけてきれいなコードを作る努力が、コストを削減する方法であるだけでなく、プロとして生き残るための唯一の方法であることを認めるでしょう。

4. まとめ

開発者としての経験とこれまでの話を通じて、悪いコードが作業速度を遅くするという事実を理解できたと思います。

それでもなお、多くのプログラマーが締め切りに間に合わせるために悪いコードを大量に生産するしかないと感じています。しかし、真のプロフェッショナルは、むしろ乱雑な状態が原因でスピードが直ちに遅くなり、締め切りを逃すことを知っています。

「最も速く進む唯一の方法は、常にコードをできるだけきれいに保つ習慣をつけることです。」

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0