アラタナエンジニアブログ

aratana Engineer's Blog

コードの不吉な臭いを嗅ぎ分ける。ワンッ!U^ェ^U

この記事はアラタナアドベントカレンダー18日目の記事です。

f:id:kimesawa:20161202085600j:plain


犬も好きですが、家ではネコを飼っています。ネコ派の木目沢です。

犬は嗅覚が優れていて、刺激臭なら人間の1億倍の嗅覚を持っているそうですよ。

エンジニアなら、コードの不吉な臭いに1億倍の嗅覚を持ちましょうというのが今回のテーマです。

コードの不吉な臭いとは?

リファクタリング」をすることについて、その重要性は、もうこの時代一般的に行われている、認識されていることかと思います。

けれど、「いつ」するのか、「どう」するのかについてはあまり意識したことがないのではないでしょうか?

あまりに汚いコードを見た時、変更できないぐらいコードが複雑なとき、リファクタリングをするきっかけとなったりしますが、もっと具体的に「こんなときにリファクタリングをしましょう」という根拠があるきっかけを「臭い」という比喩であらわしたものが「コードの不吉な臭い」です。

この「コードの不吉な臭い」は書籍「リファクタリング(MartinFawler)」の第3章に詳しく載っていますのでぜひ読んでみて下さい。
新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

コードの良い・悪いは説明できる

よく、良いコード、悪いコード、読みやすい、読みにくいコード、きれいなコード、きたないコードということがありますが、個人によってその解釈が異なったりしますよね。

特に、コードレビューをする際には、人によって違うことを言っていたりして、困ったりしたことがないですか?

「コードの不吉な臭い」には、それぞれ名前がついていますし、何故悪いのかという根拠もあります。
これをチームで学ぶことで、コードの良さ、悪さの共通認識を持つことができるんです。

KentBeckとMartinFowlerはこの書籍で「コードの不吉な臭い」を書くきっかけを以下のように語っています。

インスタンス変数の削除や継承階層を作成する手順を説明するのは簡単なことです。それほど手間もかかりません。しかし、それをいつ実行するべきかについては明快な答えが見つからない状態です。プログラミング上のあいまいな美意識に頼るのではなく、よりしっかりとした根拠で説明したいのです。

最後にいくつか「コードの不吉な臭い」の例をあげましょう。ぜひ書籍内の全ての臭いを読んでみて下さい。

重複したコード

単純ですが、よくある臭いです。同じようなコードが2箇所以上で見られたら、1箇所にまとめることを考えましょう。

「メソッドの抽出」などのリファクタリングテクニックが使用できます。

長すぎるパラメータリスト

メソッドの引数が多すぎると1つ1つが何を意味しているのか理解しづらくなります。それぞれの引数間の一貫性がなくなり、使いにくくなります。新たなデータが必要になったときには、パラメータリストを変更していかなければなりません。

メソッドの引数が多すぎるときは、まとめて一つのクラスにすることを考えてみましょう。

「パラメータオブジェクトの導入」などが使用できます。

スイッチ文

スイッチ文は重複したコードを生み出します。コードのあちこちに同じようなスイッチ文を探して似たような変更をしていかなくてはなりません。

「メソッドの抽出」や「ポリモーフィズムによる条件記述の置き換え」などが使用できます。



いかがでしょうか?
コードの不吉な臭いを嗅ぎ分けて、良いコードとはどういうコードなのか一度考えて見て下さい。

f:id:kimesawa:20161202085600j:plain

次回のアドベントカレンダーはECテックのプロフェッショナルデザイナーTEKさんによる、
3Dとか映像とか興味があるならやってみればいいじゃない!lab.aratana.jp

です。この記事は本当に凄い、ぜひ読んでみて下さい\(^o^)/

ではでは。