連載
開発をもっと楽にするNAgileの基本思想

第1回 アジャイル開発ではドキュメントを書かないって本当？

さて次に、簡単なモデリングのコツについて話したろ。モデリングやいうたら、なんや、小難しいことのように思うかも分からん。

それでや。取っ付きやすいモデリングのプラクティスを伝授しょう。

　それは、

名前をちゃんと付けることや。

どやっ、簡単やろ。クラスでもメソッドでも変数でも、きちんと分かりやすい名前を付けること。それが上手なモデリングの第一歩なんや。

そうなんですか。私、変数名なんか、けっこういいかげんに付けてますけど。

先のひどいソース・コードの例ではクラス名もメソッド名も変数名もむちゃくちゃや。めっちゃ分かりにくい。さっぱわやや*3。

　なんで名前をちゃんと付けなあかんのか？

　大事なことを教えたる。ええか。

「名前付けは、モデリング（設計行為）なんや」

　例えば、クラスを作るとするわな。このときクラスには、何か1つの明確な責務いうもんを持たすようにするもんやろ？

　また例を挙げるわ。

　このときの名前は、この責務を持った、その人にとっての「概念モデル」と一致させたらなあかんわけや。ところが、多分この話の順番は逆で、実際には名前を付けることによって、「概念モデル」が出来上がっとんねん。名前が付いて初めて、概念とその範囲が確立すんねん。ほかの概念との境界も決まんねん。「線分追加コマンド」の例でいうたら「線分追加コマンド」と名前が座ったことで、このクラスの概念や責務の範囲が腰を据えんねんな。せやから、「名前付け」いうのは大事なモデリングなんや。

　それからもう1つ。「頭の中にある『それ』をどう呼ぶようにするか」を決めるということは、自分の中にしかなかった、ある関心の範囲の概念、つまり暗黙知でしかなかった概念を、他人にも分かるようにする、つまり形式知化する作業なんや。「線分追加コマンド」の例でいうと、「線分追加コマンド」という名前がないうちは、その概念を他人さんに伝えんのは困難なことなんや。名前が決まって初めてコミュニケーションに使える。せやから、これはコミュニケーションのためのモデリングやということもできるんや。

　そういったわけで、名前付けをおろそかにしたらあかんねん。

　まあいろいろいうたけど、つまりは、「ちゃんとした名前を付けよう」いうことや。適切な名前が付いてへんいうことはや、そのクラスなりメソッドなり変数なりの責務・役割がはっきりしてへん、ほかのクラスやメソッドや変数との責務・役割の境界もはっきりしてへん、いうことなんや。

　もしやで、「ある人の付けた名前＝その人の概念モデル」となってへんと全部わやや*4がな。伝えたい概念が正しく伝わるはずがない。すなわち、コミュニケーションに支障が生じるいうことや。

　また、おかしな名前が付いとるいうことは、それがおかしなモデルや、いうことになるわな。つまりは、その名前を付けた人の頭の中で、きちんと概念が整理できてない。その人自身にとって分かりやすいもんになってへん。そんなんで、うまいこと人に伝えられるわけないわな。

　それから、さらにもう1つ。リファクタリングの本に、「名前の変更」は立派なリファクタリングの1つやと書いとる。「名前の変更」によってモデルが変わるんやさかい、立派なリファクタリングやな。

「名前の変更＝モデルの変更（設計の見直し）＝リファクタリング」や

名前付けの大切さが分かったところで、次は、名前付けのコツを教えたろ。名前付けのプラクティスの紹介や。アジャイルなソース・コードのためのプラクティスやな。

　これは、特に「コミュニケーション」という価値にコミットしたプラクティスやで。

　これを参考にええ名前を付けること。それが、ええモデルによるシンプルなコミュニケーションの第一歩や！ アカウンタビったソース･コード書こう思たら、まずはここからスタートやで、滝ちゃん！

今日のまとめや。

まあ、そういうこっちゃ。今日はこのくらいで勘弁しといたるわ。きばって精進してな。

　ほなな、滝ちゃん。マスターにあんじょういうといてや。また今度いっしょに茶ぁでもしばきまひょか、て。