EurekaMoments

新米エンジニアが一人前を目指す修行の日々を記していくブログです。

プログラミングにおけるネーミングについての勉強メモ

背景・目的

大規模なシステムを動かすプログラムを開発していると、クラスやメソッド、変数の名前を既存のものと区別できるように考えるのですが、ネタ切れになってくるとテキトーになってしまったり、以前にもあったようなネーミングをしてしまった紛らわしくしてしまったりします。 そこでプログラミング時のネーミングについてコツなどはないか調べていたところ、以下の記事がとても参考になったので、これを読んで学んだ事を自分が開発するソフトウェアと照らし合わせながらメモしておくことにします。

参考文献

プログラミング作法

プログラミング作法

参考記事

frasco.io

抽象度

メソッド名と変数名は、それらが何を意味しているのか、に基づいて命名する。変数には、変数に入る値よりも高い抽象度の名前をつけるべきである。つまり、その変数の目的を表す必要があり、入り得る値を表すべきではない。またメソッドについても、そのメソッドがどのように動作するかは関係なく、戻り値などをメソッド名に入れてしまわないようにする。

これはついついやってしまいがちですが、正直難しいですね。出来るだけコメント要らずで分かりやすいコードにしようとすると、変数やメソッドの名前は詳細にしてしまいます。

こうなると何か変更が必要になった際に、引きずられて変更しなければならない箇所が増えてしまいますが、その分クラスをもっと細分化することでメソッドや変数の数を少なくしておけば、まあ対応できるかなと思います。
どちらにしても、変更やメンテの負担を如何にして軽くするかということですね。

抽象度とクラス名

クラス生成時に未来を気にする必要はない。クラス名は、そのときどきの想定に基づいているべきである。

「単一の原則」でも言われているように、全てのモジュール及びクラスは、一つの役割のみを持たせるべきと考えられています。これによりクラスの中身がシンプルになっていれば、自ずとクラス名は役割を表した名前になるということですね。

こういった考え方があるのに対して、自分が普段の業務で開発するソフトのコードには、複数の小さいクラスをまとめて一つの大きなクラスに統合していたりするのですが、果たして本当にこれが必要な実装なのかを見直してみようと思いました。

タスクを小さく分割する

良いアーキテクチャを構築するのに役立つテクニックの一つとして、タスクを小さく分割するという方法がある。例えば「自動車」というクラスを設計するとして、一つのクラスの中で全ての機能に名前を付ける事は困難だが、Wheel, Tire, Steeringのようにより小さな構成要素に分ければ命名しやすく、その目的も明確になる。

今の自分のコードでは各クラスの名前が悪い意味で抽象的であり、それぞれが担う役割というのが少々分かりにくくなっている気がしています。例えば自動運転の障害物センサに関するクラスなら、センサの名前がそのままクラス名になってしまったりしていては、具体的に何をするものなのかが分からないですね。コントローラと通信するとか、周囲の環境をスキャンするとか、これくらい細かく分けてもいいのかもしれません。

最後に

「正しく命名することに時間をかけることには確実に価値がある。」

時間がなくて切羽詰まっていたりすると、こういうことはついつい疎かにしていまいがちです。そこをあえて時間を掛けて考えるようにすれば、可読性の高いコードになり、他の開発者のためだけでなく未来の自分のためにもなるので、上記の言葉はこれからも忘れないようにしたいと思います。