📃
自分が辿りついた綺麗なコードを言語化する
概要
業務経験を積んで色々なコードを見てきて綺麗/良いコードに対する考えがまとまってきたので、普段自分がコーディングする際に意識していることを一度言語化してみようかなと思います。
細かいルールや気にしている事は全て書き出さず、特に重じている考えを簡潔にまとめます。
月並みですが、大きな要素として下記の2つです。
- テストしやすい
- 読みやすい
それぞれ説明していきます。
※あくまで本記事は一個人の見解となりますのでご了承ください。
テストしやすい
筆者は一つ関数やクラスを作成したら、すぐにその後テストを書くスタイルです。
そのせいもあってかコーディングしている時に、常にテストしやすいかどうかを考えます。
（そしてテストがしにくい時があると、そのコードを書いた自分に怒りを覚えます。
- 冪等性、純粋関数、参照透過性を意識する
- 同じ引数で何度実行されても同じ値を返すかどうかなど
- また、副作用があるとテストが複雑になるので可能な限り避けたい
- 凝集度と結合度を守る
- 結合度と凝集度が守られていない時は必然的にテストがしづらい
- ”凝集度と結合度"という言葉で片付けるのは少し括りが大きいかもしれないが、それほど”凝集度と結合度”はテストのしやすさに強く関係している
読みやすい
コードは人間が理解しやすいようにわかりやすくシンプルに書くのが、エンジニアの使命ですよね。
- 抽象度の統一をする
- 抽象度はかなり可読性に関わると思っているので大事にしている
- これは普段の自然言語でも同じで、抽象度の整っていない文章は読みづらい
- コメントは基本ナシ
- コードで表現できるならそれがベスト。コメントに関しては色々な考えがあると思うが、自分はコメントは最終手段という考えにたどり着いた
- ただ、PHPでいうところのPHPDocなどのコメントは絶対活用しよう
- 凝集度と結合度を守る
- これを守っていれば勝手に処理は短くて読みやすくなる。凝集度と結合度って万能過ぎでは？
- 関数に対する考え方で「関数内の処理は短くしろ！」などたまに見かけますが、根底を辿ると「凝集度を意識しろ！」が正しいと思っている
- 先人が提唱している法則/原則を活用する
- DRY原則などの原則は一通り頭にいれておき活用する
- ただそれらの原則を適切に使う事が何より大事。悪用すると可読性だけでなく保守性も下がる
- 命名しやすいようにする
- 言わずもがな命名は命。上に書いたことを全て守っていても命名がダメなら全て台無しになるレベル。どんだけ大事なんだ
- 命名に関する細かいルールは色々あるが結局は、「名前がつけやすいかどうか」が大事な気がしている。例えば単一責任を守っていれば自ずとクラスや関数などは命名がしやすくなり、良い名前がついて読みやすくなる。
- 命名しやすい時は大抵コードが綺麗にまとまっている。命名がしづらい時は大抵なにかのルールを守っていない（もちろんルールに従っているのに命名しづらいパターンも多々あるが）
さいごに
コーディングで意識することは本当に多岐にわたるので、大事なことの取捨選択が非常に難しかったです。ただ言語化してみるのは自分の考えを整理できるのでよかったです。
コード例などそれぞれの項目に載せた方がいいと思うので、あとから載せようと思います
Discussion