コードの整理、その前に
-
2022年7月5日
こんにちは、cocone connectでサーバ開発を担当しています、原です。
突然ですが、開発をしていると「ここのコード、もうちょっと良くしたいな」って思うこと、ありますよね。
ただ、“コードを改善する”と言ってもその観点によって様々な対応があって、なかなかどこから手を付けて良いのか、途方に暮れてしまう事も多いかと思います。
特に、エンジニアとしてコードを書き始めて数年の方などは、先輩から「このあたりのコードちょっと汚くなってきてるからリファクタしておいて」などと依頼された際、具体的に何をすれば良いのか分からず困ってしまう事もあるのではないでしょうか。(私の実体験です…笑)
今回はそのような方々へ向け、具体的な改善の方針を決める前にコードの見通しを良くし、パターン化しやすく、普段の設計・実装にも活かせる、(より大きな改善可能点を見つけるための前段階の整理として意識している事が多い)全体を整理する足がかりとしておすすめの基本的な観点を３つご紹介していきます。
現場でがっつりコードを書かれている方にとっては当たり前過ぎてあくびが出てしまうかもしれませんが、「いままでは勢いに任せて書いていたけど、そろそろ少し色々と意識してみたいな」という方がどこから意識すれば良いのか困ってしまった際の足がかりになれば幸いです。
それでは、どうぞ。
１．重複コードを排除する
これは、どのプログラミング入門書にも(おそらく)書かれているであろう事ですね。
同じ処理を行うコードを何度も何度も書いていると、可読性が落ちるだけではなく、その部分に変更が生じた際の修正もれにも繋がり、整合性がとれなくなるなど、あまり良いことは起こりません。もし別メソッドに切り出せるようであれば積極的に切り出していきましょう。また、IDEによっては重複コードを抽出して警告を出してくれる機能を持った物もあるので、状況に応じて利用してみても良いかもしれません。
２．条件分岐のネストを解く
仕様書を元にコードを書いているとよくやらかしがちなパターンです。
「条件Aの場合、Aの処理。ただしBの場合はBの処理も行い、そのうちCの場合はC’,ただし、状態がDの場合はD’」のように記述された仕様の条件を読んだままにコーディングしていくと
if (条件A) {
// ありきたりな処理
if (条件B) {
// 何か複雑な処理
if (条件C) {
// すごく単純な処理
} else if (条件D) {
// 特殊な処理
}
}
}
のように、見るからに可読性の悪いコードとなってしまいます。
そのような場合にはいくつか方法はあるのですが、一番簡単なのは返却可能となった段階で早期にreturnしてしまう事(アーリー・リターン)です。
if (条件D) {
return {処理の結果}
}
if (条件A) {
// ありきたりな処理
if (条件B) {
// 何か複雑な処理
if(条件C) {
}
}
}
のように、ネストが１段浅くなるだけで見やすくなるだけではなく、その後の処理で考慮する事も減るので、積極的にreturnしてみましょう。
３．尋ねるな、命じろ。
このワードも、”デメテルの法則”という単語と一緒に聞いたことがある人は多そうですね。
ざっくり説明すると、「他のクラスの情報を元に何かをしたり、他のクラスの情報に直接干渉するな」といわれています。
かといって「直接干渉しないで、getterとかsetter経由で読み書き(カプセル化)すれば良いんでしょ？」というわけではなく、もっと踏み込んだ所を意識する必要があります。
「デメテルの法則」と検索すればたくさんの参考記事があるので軽く見てみてください。
ここを意識するだけでコードの見通し(特に呼び出し側)が良くなり、次に進むべき改善点も見えてくると思うので、上記１，２と合わせて見てみてください。
終わりに
さて、簡単にですが、私自身が本格的なコードの改善を行う前段階の整理や、より本質的で具体的な改善点を見つけるための１段階として見ている事が多い観点を３つご紹介しました。
これから「これまでよりちょっと良いコード」を書いてみようと思っている方の参考になれば幸いです。
cocone connectでは一緒に働く仲間を募集中です。
ご興味のある方は、こちらのリンクからぜひご応募ください。
cocone connect株式会社 採用情報
https://recruit.jobcan.jp/coconeconnect
cocone connect株式会社 公式サイト
また、ココネでも一緒に働く仲間を募集中です。
ご興味のある方は、ぜひこちらの採用特設サイトをご覧ください。
