Moonmile Solutions Blog

感覚的には、コードを短くすると、単体テストが楽になり、結果的に品質があがり、最終的にはプロジェクトの成功率が上がる、ことは理解っているのだけど、人に説明すると、どうも「納得いか～ん」方が居られるので、ちょっと論理的に証明などしてみます。

# 実は、証明するよりも、「人は理解したいものを、理解する」という訳で、ロジックで説明しても無駄なことが多いんですけどね。ま、自分を納得させるためにも必要ということで。

■現状分析

ソフトウェア開発において、ステップ数でプロジェクト規模換算をしようとすると、請負側からすれば規模を大きく見せる≒プロジェクトを擬似的に大きく見せる、ためにステップ数を「実効数」よりも増やすという現象があります。
また、プロジェクトが終わった段階で、ステップ数が多いということが、イコール「たくさん仕事をした」ということで、報酬が多くなるという現象もあるわけです。

なので、ステップ数を減らすと、「仕事量が少ない」ゆえに「報酬が少なくなる」ということに成りかねないので、この話は、

・自社で、パッケージアプリケーションを開発する。
・プロジェクトの成否が、自社の報酬に影響する。

時に使ってください。

# F# などの関数言語を使ってみると、短く書く≒簡素に書くことの重要性がわかるのですが、全てのプログラマが関数言語を使ってみるというのも難しい話なので。

■背理法で証明する

厳密に言えば、最初は詭弁的な方法で論証してみます（笑）。手っ取り早いので。

1.ステップ数が多いコードがある。
2.ステップ単位で予想されるバグ件数は決まっている（品質上）
3.ゆえに、バグ件数は、ステップ数の比例する。

バグ件数 = ステップ数 × 予想バグ比率

ということで、ステップ数を増えれば、バグ件数が増える。
なので、バグ件数を減らすためには、ステップ数を減らせばよい。

証明おわり。

…っての考えたのですが、論理的に間違っているので「証明」にはなりません。「説得」にはなるけど。

weak point は、
・予想バグ比率は、一定とは限らない。
　→　例えば、自動生成されるコードは、バグを一切含まない。
・予想バグ比率は、実際は人依存である。
　→　例えば、ベテランと新人では、予想バグ比率が異なる。
・バグ件数が、そのままプロジェクトの負荷になるわけではない。
　→　例えば、細かいバグと重大バグでは、１件の重みが異なる。
　→　システム試験などで見つかる（あるいは見つからない）潜在バグのほうが、プロジェクトの負荷となる。
のように続々とでてきます。

まぁ、これらの反論が、コード数を減らそうとはしない、という人の動きになるのですが。

経済心理学的に、ステップ数を減らすと短期的にコストが減る、という幻想を生み出しておくのと、現実にプロジェクトのコストが減る、という現実を作らないと駄目なのです。

■in/out を明確にして DFD 風に証明する。

ソフトウェア開発のプロジェクトの肝は、情報量を如何にして制御するか、です。
「情報量」ってのは、

・要件定義の工程で確定した契約　だったり
・アプリケーションの機能数　だったり
・Web アプリケーションのページ数　だったり

するわけですが、まぁ、一般的に「作る量」ってやつです。

# 「情報量」については、後に正確に定義しないと駄目だなぁと思っています。
# DFD を使うか、IDEF0 を使うか、そのあたりを制御しないと PERT 図に落とせないので。

ソフトウェア開発での作業量というのは、以下の法則があります。

・人が作成する量があれば、単純に時間がかかる。
　→　単純に人件費が、という話です。
　→　なので自動化されるもの（自動化されたドキュメント、自動生成されたコード）は、作業量に含みません。
・人が作成するものが複雑であれば、単純に時間がかかる。
　→　同様に、頭を使う時間が必要ということです。
　→　複雑怪奇なコードでも、自動生成されたり、ライブラリでモジュール化されているものは、人に対しては「複雑」とは言いませんね。
・人とのコミュニケーションが発生すれば、時間がかかる。
　→　顧客との問い合わせ、遠隔地での電話会議、ひとりではなく複数名で作る場合などです。
　→　いわゆるコミュニケーション・コストです。

さて、これを前提にすると、

コードの量が少ない場合、その状態として次が考えられます。

・コードをタイピングする時間が少ない
　→　IDE などでインテリセンスを利用するとタイピングが減りますが、先の条件で「自動化」の部分にあてはまります。
　→　コピー＆ペーストも、タイピングを少なくする手段のひとつです。
・コードを簡素にする
　→　複雑なものよりも、簡単なもののほうが、時間が少なく書ける。
・ひとつのコードを、ひとりが扱う
　→　ひとつのコードを複数名でやり取りするよりも、ひとりで完成させたほうがコミュニケーションコストは下がります。

これを因果関係で直すと、

1.コードのタイピングを減らす → 作業量が減る。
2.コードを簡素にする → 作業量が減る。
3.コードをひとりが扱う → 作業量が減る。

のいずれかのパターンになります。
つまりは、いずれかのパターンを取ると「作業量が減る」という結果が得られます。

# ちなみ言うと、「コードのタイピングを増やす」→「作業量が減る」という論理も正しいのです。
# こちらのほうは証明しません。命題は「確実に作業量が減る方法は？」なので。

この中で、1.のコードのタイピングを減らす方法で作業量を考えると、

1.コードのタイピングを減らす → 作業量が減る。
2.作業量が減る → コード量が減る。
3.コード量が減る → バグ混入率が同じであれば、バグの発生数が減る。
4.バグの発生数が減る → バグの難易度が同じであれば、不具合を直す総時間は減る。
5.不具合を直す時間が減る → アプリケーションの完成が早くなる

ゆえに、ひとつのアプリケーションを扱ったときは、コードのタイピングを減らせば、バグの発生数が減り、アプリケーションが早く完成するということになります。

ただし、これには仮説が入っています。

・バグの混入率が同じであること。
・バグの難易度が同じであること。

ですね。これはどうなのでしょうか？

例えば、perl のようなワンライナーの場合は、バグの混入率は違いますよね。また、難易度も違います。
このバグの混入率、難易度を「同じ」にする前提としては、

・コードが短くなっても、1行のコードの複雑度は同じ。

というケースが考えられます。
具体的に言えば、

・1行で扱う変数の数は、変わらない。
・1行で扱うメソッドの数は、変わらない（メソッドチェーンは、理解度を上げるが、複雑度を上げる）。

という指標があります。

なので、結論で言えば、

1行で扱う変数やメソッド数を変えずに、複雑度が上がらない状態で、
コード数を減らすと、アプリケーションが早く完成する。

ゆえに、プロジェクトの成功率が上がる。

という論法です。

さて、実務はどうなるかというのは後ほど。

コードを短く書く努力をすると、テストが省ける | Moonmile Solutions Blog
http://www.moonmile.net/blog/archives/2135/

の続きです。上記では refactoring 前を書いていないので、メリットが良く分からない。ということで、冗長な書き方をさらしておきます。

■ステータスバーを設定（冗長パターン）

ボタンなどのコントロールの、MouseEnter と MouseLeave にちまちま書きます。

    ''' <summary>
    ''' Button1 の MouseEnter
    ''' </summary>
    ''' <param name="sender"></param>
    ''' <param name="e"></param>
    ''' <remarks></remarks>
    Private Sub Button1_MouseEnter(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.MouseEnter
        ' ステータスバーにメッセージを表示
        ToolStripStatusLabel1.Text = "一番最初のボタンです"
    End Sub

    ''' <summary>
    ''' Button1 の MouseLeave
    ''' </summary>
    ''' <param name="sender"></param>
    ''' <param name="e"></param>
    ''' <remarks></remarks>
    Private Sub Button1_MouseLeave(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.MouseLeave
        ' ステータスバーのメッセージをクリア
        ToolStripStatusLabel1.Text = ""
    End Sub

    ''' <summary>
    ''' Button2 の MouseEnter
    ''' </summary>
    ''' <param name="sender"></param>
    ''' <param name="e"></param>
    ''' <remarks></remarks>
    Private Sub Button2_MouseEnter(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.MouseEnter
        ' ステータスバーにメッセージを表示
        ToolStripStatusLabel1.Text = "真ん中のボタンです"
    End Sub

    ''' <summary>
    ''' Button2 の MouseLeave
    ''' </summary>
    ''' <param name="sender"></param>
    ''' <param name="e"></param>
    ''' <remarks></remarks>
    Private Sub Button2_MouseLeave(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.MouseLeave
        ' ステータスバーのメッセージをクリア
        ToolStripStatusLabel1.Text = ""
    End Sub

    ''' <summary>
    ''' Button3 の MouseEnter
    ''' </summary>
    ''' <param name="sender"></param>
    ''' <param name="e"></param>
    ''' <remarks></remarks>
    Private Sub Button3_MouseEnter(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button3.MouseEnter
        ' ステータスバーにメッセージを表示
        ToolStripStatusLabel1.Text = "一番下のボタンです"
    End Sub

    ''' <summary>
    ''' Button3 の MouseLeave
    ''' </summary>
    ''' <param name="sender"></param>
    ''' <param name="e"></param>
    ''' <remarks></remarks>
    Private Sub Button3_MouseLeave(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button3.MouseLeave
        ' ステータスバーのメッセージをクリア
        ToolStripStatusLabel1.Text = ""
    End Sub

長い…長すぎますッ!!! Visual Studio を使うとヘッダのコメントは自動生成してくれるのですが、これで 3 つしかボタンに割り当てていません。
コード的には、MouseEnter と MouseLeave のワンセットで 20 行かかります。
なので、10 個のボタンがあれば、200 行掛かるわけですね。

■ステータスバーを設定（イベントを共通化、でも冗長）

これでは、あまりにも、なのでイベントを共通化します。

    ''' <summary>
    ''' Button1 の MouseEnter
    ''' </summary>
    ''' <param name="sender"></param>
    ''' <param name="e"></param>
    ''' <remarks></remarks>
    Private Sub ButtonCom_MouseEnter(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles _
        Button1.MouseEnter, _
        Button2.MouseEnter, _
        Button3.MouseEnter
        ' ステータスバーにメッセージを表示
        Dim msg As String = ""
        If sender Is Button1 Then
            msg = "一番最初のボタンです"
        ElseIf sender Is Button2 Then
            msg = "真ん中のボタンです"
        ElseIf sender Is Button3 Then
            msg = "一番下のボタンです"
        End If
        ToolStripStatusLabel1.Text = msg
    End Sub

    ''' <summary>
    ''' Button1 の MouseLeave
    ''' </summary>
    ''' <param name="sender"></param>
    ''' <param name="e"></param>
    ''' <remarks></remarks>
    Private Sub ButtonCom_MouseLeave(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles _
        Button1.MouseLeave, _
        Button2.MouseLeave, _
        Button3.MouseLeave
        ' ステータスバーのメッセージをクリア
        ToolStripStatusLabel1.Text = ""
    End Sub

おお、ずいぶんすっきりしましたね。イベントをひとつにまとめたので【共通化】されています。elseif の羅列のかわりに select case を使う方法もあります。

    ''' <summary>
    ''' Button1 の MouseEnter
    ''' </summary>
    ''' <param name="sender"></param>
    ''' <param name="e"></param>
    ''' <remarks></remarks>
    Private Sub ButtonCom2_MouseEnter(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles _
        Button1.MouseEnter, _
        Button2.MouseEnter, _
        Button3.MouseEnter
        ' ステータスバーにメッセージを表示
        Dim msg As String = ""
        Dim cont As Control = TryCast(sender, Control)
        Select Case cont.Name
            Case "Button1"
                msg = "一番最初のボタンです"
            Case "Button2"
                msg = "真ん中のボタンです"
            Case "Button3"
                msg = "一番下のボタンです"
        End Select
        ToolStripStatusLabel1.Text = msg
    End Sub

さて、日曜プログラマならば、この程度で許せるのですが、【業務プログラマー】ならば、この時点で２点気づかないと駄目です。

・Button1.MouseLeave 等が、二重に記述されている。
・メッセージが埋め込まれている。

イベントが多くなると、Handles を２箇所修正しないと駄目ですね。VB v2.0 特有ではありますが、継続記号「_」を書く必要があるので、結構面倒です。
また、elseif でも select case でも、所詮は【設定】なのですから、配列/リスト/ディクショナリを使ったほうが、【設定】として際立ちます。

■ステータスメッセージとイベントを設定風に変える

これが、前回書いたときのの【意図】です。
設定として記述するので、SETSTATUS のような関数を使って並べていきます。

Public Sub InitStatusBar()
	SETSTATUS(Button1, "先頭のボタンです")
	SETSTATUS(Button2, "真ん中のボタンです")
	SETSTATUS(Button3, "一番舌のボタンです")
	SETSTATUS(ComboBox1, "項目を選択します")
	SETSTATUS(TextBox1, "名前を入力します")
	SETSTATUS(TextBox2, "年齢を入力します")
	SETSTATUS(TextBox3, "住所を入力します")
End Sub

ここのメッセージを enum なり const string なりを参照しても良いですし、外部ファイルから読み込みをしても構いません。

	Class STATMSG
		Public cont As Control
		Public msg As String
	End Class
	Private _status As New List(Of STATMSG)
	''' <summary>
	''' フォーカス時のメッセージを設定
	''' </summary>
	''' <param name="c"></param>
	''' <param name="msg"></param>
	''' <remarks></remarks>
	Public Sub SETSTATUS(ByVal c As Control, ByVal msg As String)
        Dim sm As New STATMSG()
        sm.cont = c
        sm.msg = msg
        AddHandler c.MouseEnter, AddressOf COM_MouseEnter   'MouseEnter
        AddHandler c.MouseLeave, AddressOf COM_MouseLeave   'MoueeLeave
		_status.Add(sm)
	End Sub
''' <summary>
''' フォーカス時のメッセージを設定
''' </summary>
Public Sub ChangeFocus(ByVal sender As Object, ByVal b As Boolean)
	If b = False Then
		ToolStripStatusLabel1.Text = ""
	Else
		For Each cm In _status
			If cm.cont Is sender Then
				ToolStripStatusLabel1.Text = cm.msg
			End If
		Next
	End If
End Sub

ここまで共通関数で、以下のイベントを form に追加します

Private Sub COM_MouseEnter(ByVal sender As System.Object, ByVal e As System.EventArgs)
	ChangeFocus(sender, True)
End Sub
Private Sub COM_MouseLeave(ByVal sender As System.Object, ByVal e As System.EventArgs)
	ChangeFocus(sender, False)
End Sub

こうすると、コントロールが増えても InitStatusBar 関数に1行追加するだけで済みます。
また、メッセージをファイル読み込みするときは、InitStatusBar 関数でメッセージをファイルから読み込むように書き換えるだえけでいいのです。

■高速化するためにリファクタリングする

この設定では List を使ったのですが、Dictonary を使ったほうがループがなくなります。これはリファクタリングの範囲なので、インターフェースは変わらないように作ります。

    Private _statusdic As New Dictionary(Of Control, String)
    ''' <summary>
    ''' フォーカス時のメッセージを設定
    ''' </summary>
    ''' <param name="c"></param>
    ''' <param name="msg"></param>
    ''' <remarks></remarks>
    Public Sub SETSTATUS(ByVal c As Control, ByVal msg As String)
        _statusdic.Add(c, msg)
        AddHandler c.MouseEnter, AddressOf COM_MouseEnter   'MouseEnter
        AddHandler c.MouseLeave, AddressOf COM_MouseLeave   'MoueeLeave
    End Sub

    Public Sub ChangeFocus(ByVal sender As Object, ByVal b As Boolean)
        If b = False Then
            ToolStripStatusLabel1.Text = ""
        Else
            ToolStripStatusLabel1.Text = _statusdic(CType(sender, Control))
        End If
    End Sub

Control から string を引き出すだけなので Dictionary が使えます。
まあ、List をループさせても、コントロール数はそう多くないので(1万個とかではないでしょう)、スピードは大して変わりません。

というわけで、こんな風に行数を減らしていきます。
今回のポイントとしては、

・冗長な部分を共通化させて、行数を減らす。
・設定なのかロジックなのかを区別する。設定ならば、設定風に書き換える。
・リファクリングをして高速化する。

ってのがミソです。

業務コードの場合、単純にコピー＆ペーストで済めば、それを使っても良いのですが、コード自体が冗長になる場合は考え直したほうがよいですね、という話です。このあたりは、保守性も含めると、短いコード（保障されたコードを再利用する）というのが、業務コードを書くときのコツです。