自分がコーディングをしているときに大切にしていることはいくつもある。
この記事では "今日"、実際に大切にしたことを書く。
変数名は型を類推可能なものにする
Kotlinを書いているので、類推できなかったとしてもIDEが教えてくれる。
ただ、能動的に教えてくれるタイミングはコーディングしているときである。
つまり、リーディングしているときには能動的には教えてくれない。
もちろん、カーソルを当てると型を出してくれはするが、それは変数の型が類推できなくなったときの行動であり、喜ばしい状況ではない。
したがって、類推可能であることは大切だと考えてコーディングをしている。
変数定義は使う直前に
リーディング時の認知負荷を上げる要因として、よくあるのが変数定義されたがしばらく登場しない状況である。
これは、「定義された」＝「すぐに使われるはずである」という期待が生み出す認知負荷ではあるが、いまどきのコーディングルールでは必ず書かれているものなので、期待することは避けられない。
したがって、新規に書かれるコードは期待に答えてくれるものが多い気がする。
逆に、コードを変更するタイミングで期待にそぐ****わない状況が起きてしまうことがあるような印象を持っている。
変更するときには、特に意識したい。
結果的に整合する（楽な）実装があったとしても、ドメインの表現ができる実装を行う
例えば、以下のようなドメインの表現があるとする。
- ある条件が適用されるとモデルの状態がAからBになる。
- Bの状態のモデルを使って、ロジックを動かすと必ず結果は一定になる。
このとき、「モデルの状態をAからBに変更する」実装コストが高いとしよう。
そして、「ロジックの中でモデルに対する適用条件を見て、一定となる結果を導く」実装コストが低いとする。
このとき、どちらの実装を選ぶだろうか？
私は、実装コストが高い方を選ぶようにしている。 *1
これは以下のように考えているからである。
- 結果的に整合する状況が担保されていない可能性がある
- 条件が変わったときにロジックが破綻する可能性がある
- 破綻しなかったとしても、条件が変わることで必要な情報が変化し、本来ロジックに必要のないはずだった状態が増えてしまい、本質的ではない依存が発生する
- ドメインを理解し実装を見ると、いたずらに認知負荷を上げてしまうこと
- あるべき箇所に実装されていないので、なぜ動いているのか分からなくなることが予想できる
- あるべきではない箇所にあるロジックが、どこから発生したものなのか推測できない
今日は記事かけて一安心。
カジュアルにかけるネタを今後も探っていきたい。
*1:一応弁明を書いておくが、可能な限りだ。実装コストが10倍高く、時間をかけることができないような状況では、しぶしぶ低いコストを選ぶことはある。
