動作するきれいなコード

2013年11月13日のメモ。動作するきれいなコードって英語で何と言うのだろう。

Web開発の基礎徹底攻略の特集2コーディングの基礎知識を参考にまとめた。

コードレビュー

• 動作するきれいなコードを目指すためにやらない手はない
• 他人からの視点は重要
• 他人に見られるときれいに書こうとする意識が働く場合がある
• しかし、漠然やっても意味がない
• きれいなコードや汚いコードの基準のようなものをまとめておいて wiki なんかにガイドライン的なものとしてまとめておく
• あとから追加できるように
• そうすることでこれらの判断材料をもとにコードレビューできるため、漠然としたものになりにくそう

汚いコードの特徴

• 数百行にも及ぶメソッド
• 必要以上のグローバル変数の使いまわし
• 似たような処理が至るところに散らばっている
• 何をしているのかわからない複雑なクラス
• 処理のかたまりを見たときに何をするものなのかがぱっとわからない

きれいなコードの条件

• 人に意図が伝わる

• コードが自己説明的である
• つまり、コードがコード自身により何のために書かれていて、どのような処理を行っているか説明できていなければならない
• コードの理解に無駄な時間を取られることがなくなる

• 変更に強い

• コードは日々変更（修正）されるもの
• 変更に弱ければ、修正に時間がかかるしバグが作られやすい

適切な名前がつけられ、不要なコメントがない

適切な名前の条件

• 説明的である

• 何なのかを正確に表現している
• 名前が思いつかない場合、自分が何に名前をつけようとしているのか理解できていない
• メソッドやクラスにたくさんの処理をさせている場合、うまく名前がつけられない
• 1つのメソッドで1つのことをやるようにする

• スコープに従う

• スコープが広いものほど長い名前（より説明的であれ）
• スコープが短いものは、簡単な名前でよい

• 命名規約・習慣に従う

• チーム内でコーディング規約を統一する

コメント

• コードを読めばわかることをわざわざコメントに書く必要はない

• コードとコメントの情報の重複

• コードとコメントの内容の不一致

• コメントを修正し忘れたり、めんどうで書かなかったりして最新のものに追随できなくなる

• コメントはメソッド抽出の良い目安

テクニック

• 条件判断をメソッドで隠蔽する

• 条件判断はコードを見づらくしがち

• 単一責任の原則

• クラスの責務は1つでなければならないとか

テスト

• 不安を感じたら一歩ずつテストケースを作成してコードを書いていく
• 不安を感じないのであれば、明白な実装をしてもよい
• テストコードのリファクタリングで、似たようなテストをしているテストケースが他にあり、内容が重複していると思ったらテストケースを削ってもよい

• 見通しをよくするため

リファクタリング

• 外からの振る舞いを変えずに、内部のコードを整理すること
• 随時行われるもの
• 機能追加をするタイミングでリファクタリングを行う
• テストありき。テストがない場合、まずテストを書く

• 全部を網羅するように書く必要はない

• リファクタリングと機能追加は一緒には行わないようにする

• メソッド抽出（見通しが悪いと感じたとき、重複があったとき）

• メソッド名を決める
• コードをコピーする
• 元のコードとメソッドを置きかえる
• テストを実行して確かめる

• 内部の処理が微妙に違う場合

• コネクションを作り、最後に終了させるのは同じだが、返ってきたリクエストに対する操作が違う場合とか
• そういう場合、ブロックを使う
• ブロックを使えば、違うところをコード片として渡せばよい

• 具体的な処理をメソッド抽出し抽象化する

• 難しいと思ったらそこをメソッドにするなどして隠蔽してしまう

• メソッドの引数を少なくする

• 理想は0
• 3つ以上（1つの方針）になったら複数のメソッドに分割できないか検討する