こんにちは。
システムチーム / プログラマーのNです。
少し前になりますが、「良いコード、悪いコードで学ぶ設計入門」という書籍を読んだので、感じたことをブログにまとめたいと思います。
プログラマーによって書き方や思想の違いがある中で、どのように「良い」「悪い」を判断するのかを学びました。
良いコードは命名を見れば判断できる
コード全体を見なくても、最初の数行をみれば判断できる
というものです。
変数名から中身を理解できるように命名する必要があります。
そりゃそうやな、と感じると思うのですが、
命名は実際ものすごく難しいです。
なのでこの書籍でも、いたる所で重要性が書かれています。
名前を短くしようとすると中身がわからない。
中身を説明しようとすると不必要に長くなってしまう。
経験してきた中で、例としてどういったものがあるだろうと考えながら読み進めました。
整数なのか少数なのかわかるようにするには、どんな命名にするのが適切なのか。
「Floatとか、Intを命名に含めればいいんじゃない？」
と単純に考えがちですが、
Array、flag、Intなどを使った命名は保守性が落ちるとあります。
技術駆動命名と呼ばれ、技術用語をそのまま使った命名方法です。
なぜ保守性が落ちるのか
１．技術的な背景を理解していない人はコードが読みにくくなる
２．ロジック（処理手順やルール）が技術的な名前に引っ張られてしまう
３．ロジックの変更時に、技術的な名前もそれに合わせて変更する必要が生まれる
「３」は特に気を付けないといけないと思っています。
なぜかというと、
・変数名を変えなくてもエラーが発生しない
・エラーが発生しないから、変数名と中身の意味が一致しなくなっても気が付かない
これが1箇所、2か所、、、、となってくると想像しただけで怖いです。
じゃあどういう命名が正解なのか、
FloatなのかIntなのかは命名しなくていい
その理由なんですが、
「何の値か」を表すべきであって、「何の型か」を入れる必要がない
例えば、位置や座標を格納する変数の場合、整数も少数もありえるからです。
posXFloatなどと限定してしまうと、場面によって嘘になってしまう。
何の値かを明確にした命名で、もし整数が必要ならキャストすることで明示する
というのがベターなのかな。
命名については思想とか流儀が人それぞれ存在するので、絶対はないと思うのですが、
本書を読んで理解が進んだ部分です。
本書全体を通して
設計は特別な才能や大げさな建築作業じゃない
という言葉が刺さりました。
設計は難しいのは前提ですが、
変数名をどうするか、条件分岐をどう整理するか、など
こういう小さな判断こそが設計という考え方
難しいものを難しいままにしないために小さな判断を積み重ねることが大事
読んでみてすごくいい本だなと思いました。
