うまく名前をつけることは、「究極の設計」ではある（と私は思う）けれど。
ここではもっとカンタンなお話として。
（上位の）設計書からそのまま名前を引用しようとすると、
コードにうまくマッチしないときがある。
なぜならば、設計書に書かれるものは「インスタンス」だから。
プログラムは抽象化しているから「そのもの」ではないときがある。
そこのところの線引きが頭の中でうまくできないといけないし。
抽象化したもの／ことに対しても（別の）名前をつけないといけないし。
ちゃんとみんなにわかるように名前つけてあげないといけないし。
もうひとつは置き場所のこと。
この部品／この情報は、「どこ」に置いておくべきか、「どこ」に持たせておくべきか。
「持ち主」をはっきりさせることがだいじ。
もちろん、そこにはいろんなひとの考え方があって、
必ずしも満場一致とはいかないだろうけど、
そういうことを仲間と話し合うことで、考えが深まっていくわけで
そういうやりとりすることがすごく大事だと思う。
そして、こういうことを意識してコードを配置しないと、
どこに何が書いてあるのか全然わからなくなる。
読んでいるほうはそういう見方をするから、
そうなっていないもの（＝ルールや規則性のないもの）を追いかけるのは
すごくしんどい。
「子供の落書きと一緒、書き散らかしてるだけ」とは
私の先輩の言葉だが、まさにその通り。
意図がわからないコードはただの落書きだ*1。
その場の思いつきで、書きたいところに書いているだけ、に見えてしまう。
こういうことは、ごくごく基本的なプログラム設計の考え方だと思っているのだけど、
「自分でイチからつくってみる」ってことをやっていないと
ちゃんと身につかないものなのかもしれない。
例えば大きなシステムのごく一部だけをつくっているだけだったり、
人が考えた設計をコードに落とすだけだったりするような仕事がずっと続いているようだと
身につかなくなるものなのかもしれない。想像ではあるけれど。
