エイチームライフスタイルアドベントカレンダー2017の8日目です｡
本日は株式会社エイチームライフスタイルの新卒1年目のエンジニア@kyntkが担当します。
はじめに
私もエンジニアとして 「コードがきれい」って言われたい！ と思い､普段学んだことをまとめる一環としてこのテーマで書くことにしました｡
約8ヶ月前､入社したばかりの頃､私は「きれいなコード」と聞いてもあまりピンとこない状態でした｡スキルはRailsで簡単なアプリを作れる程度で､コードの美しさについては考えたとがありませんでした｡私が書くコードに対しては､ほぼ毎回「読みづらい」という指摘を受けていました｡
そんな私が､様々な開発やリファクタリング､コードレビューを通して学んだ､きれいなコードの定義と条件をまとめました｡
以前の私のような､「きれいなコードって言われてもよくわからない」という人に､「もっと､きれいなコードの条件を知りたい！」「リファクタリングをしてみたい！」と思ってもらえたら嬉しいです｡
きれいなコードってどんなもの？
ずばり､読みやすくて､修正しやすいコードだと思います｡コードを読むのは､周りの開発者や､将来の自分です｡
コードは一度書いたら終わりではなく､ずっと保守を続けなくてはいけません｡もしコードが読みづらいと､処理の理解に余計な時間がかかってしまいます｡また､コードが修正しづらいと､修正にかかる時間が長くなるだけでなく､不具合も起きやすくなってしまいます｡
逆にきれいなコードを書くことができると､周りの開発者や将来の自分が泣いて喜ぶでしょう｡不具合も起きず､ユーザーからの感謝にもつながるかもしれません｡周りからの評価も上がること間違いなしです｡
では､読みやすくて､修正しやすいコードの条件とはどんなものがあるのでしょうか｡
きれいなコードの条件
私がコードレビュー時に受けた指摘や､本･ネットなどから学んだ､「きれいなコードの条件」を紹介していきます｡
● 同じ処理はまとめる｡繰り返し書かない
同じ処理が繰り返し書かれていると､コード量が多くなるため読みづらく､修正する時に修正箇所が多くなってしまいます｡また､このような処理は､条件が追加されると､更にまた同じコードが増えてしまいます｡
そして､もしロジックを変更したいときには､多くの既存のコードを修正することになり､抜け漏れにつながります｡このような処理を書かないように､まとまった処理をメソッドとして抽出しましょう｡すると､コードがシンプルにまとまり､修正箇所もひとまとめにすることができます｡
● ネストは浅くする
if文などでネストが深く､条件が複雑に組み合わさっていると､ぱっと見で条件が理解しづらくなってしまいます｡
また､テストケースを網羅しようとするときにも､抜け漏れが発生しやすくなります｡そのため､条件を複数に分解できないかを考えたり､ネストが深くならないようなコーディングをすることが必要です｡
ネストが深い時、条件の順番を入れ替えてみるだけで、ネストを浅くすることができるかもしれません。どうしたら単純な条件になるのか考えて見ましょう。また、一部をメソッドとして抽出してみてもいいと思います。
● 変数名･関数名をわかりやすくする
ネーミングがシンプルかつストレートにできると､名前だけで何をする処理なのかが想像できます｡逆に､ネーミングに失敗すると､誤解を与えることにもつながります｡私もこの点に関して何度も先輩から指摘を受けました｡
わかりやすいネーミングをするために､その処理が何をする処理なのか､どんな変数なのかを考え､それを端的に示す単語を選びましょう｡また､その名前を見て誤解されないかを考えてみることも重要です｡
その他
- 1つのメソッドは短くする
- インデントや命名規則などのチームにおけるコーティング規約を守る
- 使っていない処理のコメントアウトは削除する
といったものもあります｡もっと詳しく知りたいときは､新装版 リファクタリングやリーダブルコードを読んでみましょう｡
常にきれいなコードを書けるわけではない
はじめは､「自分が書いたコードが汚いのはスキルが足りないから｡スキルが付けばきれいなコードが書ける」と思っていましたが､そうとも限らないことを知りました｡スキルが高くても常にきれいなコードを書けるとは限りません｡
例えばリリースを最優先で行うためにスピードを重視している時は､コードの綺麗さがあまり重視されないこともあります｡また､既存コードに同じような実装があることに気づかず､再度実装してしまうこともあります｡
リファクタリングしてみよう
常にきれいなコードを書ければいいですが､汚いコードが生まれてしまうこともあります｡そんな時には､コードを書き直してきれいなコードにすればいいのです｡これがいわゆるリファクタリングです｡
リファクタリングとは
読みづらく､修正しづらいコードをきれいなコードにすることです｡
新装版 リファクタリングの中で､リファクタリングは「外部から見たときの振る舞いを保ちつつ､理解や修正が簡単になるように､ソフトウェアの内部構造を変化させること」と定義されています｡
リファクタリングでは､新しい機能の実装も､バグを潰すこともしません｡また､リファクタリングしたからと行って､ユーザビリティが上がるわけでもありません｡ただ､コードをきれいにすることを目的として行います｡
リファクタリングの始め方
まずは､「このコードきれいじゃないかもしれない」「もっと良い書き方があるかもしれない」という気になるコードを見つけましょう｡
タイミングは､わざわざ探す時間を取らなくても､開発中やバグフィックス中に少し気にしてみるだけで大丈夫です｡普段あまり触らない部分のリファクタリングをするよりも､変更の頻度が高い部分のリファクタリングをした方が効果的でしょう｡
そして､もし気になるコードを見つけたら､毎回少しずつでもきれいにすることが大切です｡見て見ぬふりをしてしまうと､汚いコードが蓄積されて､解消するのがとても大変になってしまいます｡
コーディングでも､ボーイスカウト精神「来た時よりも美しく」を意識してみると良いと思います｡
どんなことをしたか
● 自分で書いたコードをとにかくリファクタリングしてみる
どんな処理をしているかを理解していて､汚いコードである自分のコードでリファクタリングをしました｡もっと短く！ もっとわかりやすく！ と考えるだけで､意外とコードは改善されます｡
● 今あるコードをリファクタリングしてみる
開発をしていて､「このコード､もっときれいに書けるんじゃないか？」と思ったところをリファクタリングしてみました｡また他にも､「ここをリファクタリングしたら､より効率的に開発ができるようになる」というところを教えてもらってリファクタリングしたこともあります｡
● きれいなコードの書き方を学び、使ってみる
本やWebの記事を読んだりして､言語やフレームワークにどんな書き方があるのかを学びました｡例えばパーフェクトRubyやパーフェクト Ruby on Railsを読みました｡
また、リファクタリングや技術的負債について学びました｡Webの記事は色々見ましたが､コードを書く際の指針として見返すサイトまとめなども参考にしました｡本は新装版 リファクタリングやリーダブルコードです｡そして､学んだことをリファクタリングに活かしました｡
リファクタリングをしてよかったこと
● 言語･フレームワークの理解が深まった
よりシンプルに書く方法を調べることによって､それまで知らなかった文法や実装方法を学ぶことができました｡
● プロジェクトのソースコードの理解が深まった
リファクタリングするには､どんな実装かをきちんと理解している必要があります｡そのために､既存のコードをきちんと読んで､理解を深める事につながりました｡
● コードレビューで指摘される回数が減った
リファクタリングをしていると､実装の時からどうしたらきれいなコードを書くことができるかを意識するようになります｡すると､初めからきれいなコードが書けるようになってきました｡
● 修正が簡単になった
リファクタリングをしたあとに､そこの修正工数が大幅に減りました｡以前は1回の修正に約80ファイル修正しなくてはいけなかったものが､リファクタリングによって1ファイル修正することで同じ変更を行うことができるようになりました｡
これにより､修正工数が大幅に減り､不具合も起きにくくなりました｡
まとめ
- きれいなコードとは読みやすく､修正しやすいコード
- まず汚いコードの条件･きれいなコードの条件を学ぶのが重要
- 汚いコードがあったら､こまめにリファクタリングしていくこと
- コードがきれいと言われるようになろう！
終わりに
エイチームライフスタイルアドベントカレンダー2017の8日目､いかがでしたか？
明日はデザイナーの@chika_1127さんがcssアニメーションについて書いてくれるらしいので、お楽しみに。
また､株式会社エイチームライフスタイルでは、一緒に働けるチャレンジ精神旺盛な仲間を募集しています。興味を持たれた方はぜひエイチームグループ採用サイトを御覧ください。 http://www.a-tm.co.jp/recruit/
参考
書籍
- 新装版 リファクタリング 既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)
- リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)