どうも大沼です。今回は「Clean Code アジャイルソフトウェア達人の技」という本を読んだのでそれについて記事を書こうと思います。
Clean Codeという本はよくリーダブルコードの次に読むべきより実践的な本としてよく紹介されています。
内容としては著者の経験から良いとされるコードの書き方を紹介している本です。その内容をかいつまんで軽くご紹介致します。
ちなみに大分コンパクトにしたので既に読んだ方はあれやこれが抜けていると感じられたら恐縮ですし、番号振ってますが章とリンクしている訳ではございません。
1.まずクリーンコードとは何か
まずなぜクリーンコードを書かなくてはならいのかという問いに関しての答えは、生産性を上げるためという回答になります。
そのために「コードのセンス」を身につけようというのが序盤に語られる趣旨です。
どしてかと言うと、良いコードと悪いコードを判別出来る人はたくさんいるがそれができても、洗練されたコードが書けなくては意味が無いからです。
該当コードの周辺が読めなくては、コードを書くことはできないので、読みやすくするということは、書きやすくすることを意味しているのです。当然、一度クリーンコードを書ければいいわけではなく、継続して洗練していかなくてはならないです。
以下からノウハウへの旅が始まります。
2.意味のある名前
・意図が明確な名前にする
何故それが存在するのか、何をするのか、どのように使用するのか。もしも名前に解説が必要なら、その名前は、意図が明確とは言えない。
・偽情報を避ける
曖昧な名前にすることで、間違った情報を与えてしまうことがあるため、避けた方が良い。
省略や、単語の意味が複数ある単語など。
特別な意味のある単語を使用してそれに沿っていない場合。例えば、flgとなっているのに入ってくる値は0,1,2とか。
・検索可な名前にする
例えばuserFirstNameなら簡単に検索に引っかかるでしょうが、これがnameだった場合、ほかで使われているものまで引っかかって目的までたどり着くのに時間がかかる。
aなどの一文字の変数は小さなメソッドのローカル変数以外ではつかってはいけない。
・クラス名
クラス名には名詞を使うようにし、動詞は避けるようにする。
・メソッド名
メソッド名にはgetやsaveといった動詞、動詞句をつける。
3.関数
・小さくする
関数の第一規則は小さく、第二規則はさらに小さくである。
関数の長さは２０行を超えないようにすべき。
１行は１５０文字を超えないようにする。
長いとコードを理解するのに時間がかかってしまうため。
関数の中にはネストされた構造を作ってはいかないので、関数内でのインデントは２階層までにすべき。
・１つのこと
以下のような助言が語り継がれてきた
「関数では１つのことを行うようにせよ。その１つのことをきちんと行い、それ以外のことは行ってはならない。」
この「１つのこと」とはなにか。
関数の名前で示される、ある１つの抽象レベルのいくつかのステップのみで表現されるのであれば、その関数は１つのことをしているといえる。
つまり、ある１つのより広い概念を次の抽象レベルのいくつかのステップに分解されたものが関数である。
・１つの関数に１つの抽象レベル
関数が「１つのこと」のみを行っているかを確実にするには、関数内の分が１つの抽象レベルになっているかを確認する必要がある。
・内容をよく表す名前を使う
１つのことを行う小さな関数に適切な名前を付けること。
関数を小さくして行くことに慣れていけば内容を良く表す名前を付けることが簡単になっていく。
内容を表す長い名前は、不可解な短い名前より優れていて、内容をよく表す長い名前はないようを良く説明した長いコメントよりも優れている。
関数が何をするのかを明確にするために複数の単語を関数の名前にしようするべきである。
名前を考えるのに時間を使って良い。
内容をよく表す名前にすればあなたの頭にある設計がまとまり、コードの構造を改善することにつながる。
・関数の引数
関数の引数は理想的には０である。
最高で２つに押さえるべきで、３つ以上にするのはさけるべきである
引数は持ち回ることができるため、流れを追うためにコードの解読が必要になる
引数がなければ考えなくて良いが、引数があるのならたとえ重要でなくても実装詳細について知らなくてはならなくなる
4.コメント
コメントで駄目なコードを取り繕うことはできない。
コードを－度を書いているうちに雑然としていることに気づいた時にコメントで改善しようとするのではなく、コードをきれいにすることを心がける。
コメント入りの雑然としたコードより、コメントがほとんど無い、きれいなコードの方が優れいてる。
・良いコメントとは
有益なコメントとはどのようなものか。大前提として書かずにすむことほど優れたコメントである。
→情報を与えるコメント：変数の書式をつためるため（YY:mm）など
→意図を説明するコメント：裏に隠された意図をつたえるため
→明確化するコメント：あいまいな引数や戻り値を明確にするため
→結果に対する警告をするコメント：重い処理であるなどを知らせるもの
・悪いコメントとは
ほとんどのコメントはここに属する。
→書き捨てられたコメント：必要に迫られた、行きがかり的なもの。結局ほかの部分のコードを調べる必要がでてくる
→冗長なコメント：コードを上回る情報がなく、コードより不正確であるため読み手の正しい理解を妨げるもの
→誤解を招くコメント：微妙な誤解を招く表現はコードを読んでいれば防がれた誤解を生むことがある
→ノイズコメント：新しい情報がなく、コードを読んだらわかることを書いてあるため時間が余計にかかってしまうため、無視されコードを読むときにコメントを読み飛ばすようになり、コードが変更されてもコメントがメンテナンスされなくなり嘘の情報になるため
→コメントアウトされたコード：禁止（もっと細かく書いていたが要約するとこう）
5.クラス
・クラスは小さくしなくてはならない
クラスの規則の筆頭は、小さくするということです。第二の規則は、さらに小さくするということです。そのためには責務を少なくしなくてはならない。
クラスにあいまな名前をつけると責務が大きくなりがちなので、わかりやすいクラス名にしよう。（曖昧な例：processor,manager,super）
・単一責務の原則
SOLIDでも出てくるやつです。
クラスは変更の原因となるものが１つでなければならない。クラスは、ただ１つの責務、つまり変更の原因となるものをもたなくてはならない。
システムを多目的の大きなクラスで構成すると大量のロジックと複雑さを持っており、理解しなくてもよい部分まで調べることになってしまう。
システムは少数の大きなクラスではなく、多数の小さなクラスで構成する必要がある。個々の小さなクラスは１つの責務をカプセル化し、１つの変更の原因となるものを有している。
・凝集性
クラスの凝集性は低くするべきである。あるメソッドが操作する変数が多いほどそのクラスのメソッドは凝集性が高いといえる。
・変更のために最適化する
変更を行う時は常にシステム内の別の部分が想定通りに動かなくなる危険が伴う。洗練されたシステムは変更に対するリスクが最小限となるように構成されている。
6.ケント・ベックによる単純な設計のための４つ規則
・全テストを実行する
システムをテスト可能にすることで設計者は暮らす１つ１つが小さく、それが単一機能を実装しているような設計へとうながされることになる
・重複がない
重複はシステム最大の敵。
システムをきれいにするためには小さな重複も排除し、共通化する。
この小さな再利用がシステムの複雑さを大きく減少させることになる。
・プログラマの意図が表現されている
システムが複雑化していくにつれて、それを理解するのに時間がかかり誤解が生じる可能性が増す。
そのため、コードは書き手の意図が明確に表現されている必要がある。意図が明確であるほど、他の人が理解するのに必要な時間が減る。そのため、不具合を減らし、保守コストを低減させることに繋がる。
・クラスとメソッドを最小化する
上記３つの規則を行き過ぎた状態にしないために存在してる規則。
小さなクラスとメソッドがあまりに多く生成されてしまわないように、関数とクラスを少なくすることを心がける。
但し、この規則は先に提示した３つの規則の中でもっとも優先度が低い。
7.継続的改良
コードをきれいに保つことは比較的容易であると説いている。
いきなりきれいなコードが書ける必要はなく、まず汚いコードで書き、それをきれいにしていけば良い。
朝、混乱を持ち込んでも、午後には解消することが簡単にできる。コードはつねにできる限りきれいで単純に保つことが必要である。これは子供の頃に習った作文の書き方と同じで、下書きを書き何度か下書きを重ねた結果最終版を書くのと同じであると例えていた。
よくプログラムを動かすことが目的と考えているプログラマがいるが、そうではなくどのように動く状態か、宇どいていても壊れている場合があることを意識すべきである。
まとめ
結局長きに渡り今まで紹介してきたノウハウを提供しており、てっきりノウハウ集的なものと思って読んでいたのですが、ラストに著書の言いたいことが纏まっていました。
「価値体系こそが目的であり、この本のテーマだった。」
クリーンコードとはルールに則りコードを書くことではない。ルールを学んだからといってプロになれるわけではないのです。
価値体系とは調べてみると以下である。
価値体系（かちたいけい）とは社会学用語の一つ。これは社会においての構成員個人の持つ価値意識の総体が、社会の文化の枠のもとで体系化されているような状態のことを言う。このことから、ここで述べられている社会の構成員ならば、社会においての独特な価値体系の示す規範に従って思考して行動しているということになるわけである。価値体系 by weblio
つまり、規則を共有して同じ考えでコードを書いていくことこそがクリーンコードということになる。
よって、我々がやることはチームでコーディング規約を作成して、それに則り開発を行っていくことが目的である。
ちなみに、第17章においと経験則では、今までの章のノウハウが端的に纏まっており、ここだけ読んだり読み返す、またはコーディング規約の参考にするだけでも有益です。
最後に、この本について先日軽く発表したので、その資料を貼っておきます。
この発表の時も議論になったのですが、今回紹介した部分や本の内容を絶対やらなければいけないわけではなさそうです。
そもそも、内容によってはチームで議論になることは少なくないと思われます。ですので、そこも含めて価値体系を設定していこうぜ☆
ということなんじゃないかな、と私は考えました。
ではでは。