ホーム

スタッフブログ

2021年1月12日

命名規則をドキュメント化しました

こんにちは。

プログラマー / マネージャーの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。

 

英語の参考書にならないよう、

十分に留意して、ドキュメントを書く必要がありました。

 

 

④ 「〇〇してはいけない」だけでは響かなかった

 

何事においてもそうですが

「〇〇してはいけない」と口にするのは簡単。

無意識にその言い方に流れます。

 

ところが、

「じゃあ、何をするべきなの?」という問いかけに

明確な答えを用意しない限り、

説得力のある文章にはならないと気づきました。

読んでも、何かスッキリしない。

 

本件に限らず、

理由を論理的に示して、

責任をもって、

「〇〇するべきだ」と断言することは、

難しいことです。

 

今後

「〇〇するべきだ」という言い回しに出会ったときは

「どういう理屈なんだろう?」と考えてみたくなりました。

 

 

求人バナー

このページの上部へ戻る