こんにちは。
プログラマー / マネージャーのAです。
先日、
プログラマー育成の効率UPのため、
命名規則をドキュメント化しました。
その中で新たな気づきがあったので、
いくつか紹介します。
① ムズカしかった
個人的に。
プログラミングは命名を繰り返す作業であり、
命名以外の作業比率が無視できないのは、
適切な命名が施されていないからだ、と考えています。
我ながら、強烈な思考だと思います。
その根本にあるのは、
これまで培ってきた多くの情報。
それら多くの情報を整理・言語化することは難しかったです。
名著「HIGH OUTPUT MANAGEMENT」には
– 教えることは行うことよりもずっと難しい –
の様な一節がありますが、
それを身をもって体感しました。
② 自分は「するべきか否か」の書き方ばかりしていた。
例えば
if( can_animate ) … => アニメーション出来るなら…
if( needs_animate ) … => アニメーションする必要があるなら…
のような書き方が巷にはありますが
自分のプログラムにはそういった書き方は無く、
if( should_animate ) … => アニメーションするべきなら…
ばかりでした。
個人的にですが
「must(should)」「can」「will」のフレームワークには少し否定的で、
まず「must(should)」だけで物事を考えるようにしているのですが
それがコードにも表れているのは面白い気づきでした。
③ 基本的な英語力がある事が前提だった
例えば、普段、
「アニメーションしているオブジェクト」と命名をするとして
「”animate_object” ではなく “animating_object” だ」
と言い切ってしまうんですが
これは
① animate は動詞（アニメーションする）
② animating は現在分詞（アニメーションしている）
③「e」 で終わる動詞 は「e」を外して分詞にする。
④ 分詞は1語だけなので前置修飾。
という英語力を元にした行為でした。
無意識に、英語力を使っていたと気づきました。
ただし
今回の目的は
英語力UPではなく、命名力UP。
英語の参考書にならないよう、
十分に留意して、ドキュメントを書く必要がありました。
④ 「〇〇してはいけない」だけでは響かなかった
何事においてもそうですが
「〇〇してはいけない」と口にするのは簡単。
無意識にその言い方に流れます。
ところが、
「じゃあ、何をするべきなの？」という問いかけに
明確な答えを用意しない限り、
説得力のある文章にはならないと気づきました。
読んでも、何かスッキリしない。
本件に限らず、
理由を論理的に示して、
責任をもって、
「〇〇するべきだ」と断言することは、
難しいことです。
今後
「〇〇するべきだ」という言い回しに出会ったときは
「どういう理屈なんだろう？」と考えてみたくなりました。
