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

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

福井コンピュータ株式会社 小島 富治雄(Microsoft MVP 2006 − Visual C#)
2006/02/22

■■モデリングのコツ■■

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

   
そうですね。何だか難しそうです。
   

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

 それは、

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

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

   

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

   

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

*3 全然ダメ。

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

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

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

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

 また例を挙げるわ。

 

 例えば、CADを作るとする。「2点をマウスでクリックすると1本の線分が追加できる」とするわな。このとき、この「2点がクリックされたら、線分を追加する」いう仕事をさせるクラスを作るのが普通や。このクラスの責務は、「クリックされることを受けて線分をデータとして登録すること」や。で、このクラスに「線分追加コマンド」と名前を付けたとする。

class 線分追加コマンド
{
}

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

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

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

【ポイントやで!】
名前が大事。
名前付けはモデリングの入り口。
正しい名前付けは、コミュニケーションに使えるモデルのキモ。

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

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

*4 台無しな様子。

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

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

「名前の変更=モデルの変更(設計の見直し)=リファクタリング」や

■■名前付けのプラクティス■■

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

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

名前付けのプラクティス:

  1. 概念と名前を一致させる

  2. 同じ概念には同じ名前を付けて、異なった概念には違う名前を付ける

  3. 1つの独立した概念のみを表す名前を付ける

  4. 抽象的な概念には抽象的な名前、具体的な概念には具体的な名前を付ける

  5. 抽象的すぎて伝わりにくい概念は、メタファ(例え)で表す*5

 
*5 例えば、Command(コマンド)クラスのインスタンスを作るためのクラスの名前をCommandFactory(コマンド工場)とする、など。
 

名前付けのアンチ・プラクティス(やったらあかんこと):

  1. 名前の後ろに数字を付ける
    例:Calc1、Calc2、Calc3……

  2. 省略する
    例:(GetNameを)GetNm、(Initializeを)Intl

  3. 意味不明の名前
    例:TheFunction

  4. 名前に、種類(クラス、メソッドなど)や型名を入れる
    例:MainClass、FirstMethod、intNumber、doubleValue

  5. 統一感がない
    例:命名規則がなく、名前の付け方がばらばら


 これらは、ええ名前を付けるためのガイドラインにしたってな。

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

■■まとめ■■

今日のまとめや。

■■エピローグ■■

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

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

   
十蔵さん、ありがとうございました。またぜひ教えてくださいね。
 

終わりに

 今回はNAgileの最も重要な考え方である「5つの価値」のうちから、特に「コミュニケーション」について考えてみた。どうだっただろうか。今後もさらに、「5つの価値」について考察していきたいと思っている。お楽しみに。

 またNAgileシリーズ基本版の「第3回 ソフトウェアの良い設計を行うコツ」も併せてお読みいただきたい。End of Article

(Illustrated by 正木茶丸


 INDEX
  開発をもっと楽にするNAgileの基本思想
  第1回 アジャイル開発ではドキュメントを書かないって本当?
    1.アジャイル開発ではドキュメントを書かないの?
    2.アカウンタビリティは大切
    3.ソース・コードのアカウンタビリティとは?
    4.ソース・コードにアカウンタビリティを持たせよう!
  5.モデリングのコツ
 
インデックス・ページヘ  「開発をもっと楽にするNAgileの基本思想」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

注目のテーマ

Insider.NET 記事ランキング

本日 月間
ソリューションFLASH