プログラミング

2006-03-03 で書いた「プログラミング C# 第4版」を読んでいて、いいなあと思った表現。

ところがあいにく、それはセモリナ粉の種であり、スパゲッティコードと終わりなき混乱を生み出してきました。

48ページの goto 文についての説明のところで出てきた表現。スパゲティの素材となるセモリナを、スパゲティコード (複雑に絡み合ってメンテナンスしにくいプログラム) の素としたジョーク。

幼い頃に給食で出たスパゲティが入っていた袋にはデュラム・セモリナと書いてあって、それが幼い頃の自分にとっては意味不明というか謎めいていて好きだった。その後、本などで調べて、デュラム小麦というものの中心部分を粗挽きにしたものをデュラム・セモリナと呼ぶことがわかったのだが、それでもデュラム・セモリナという言葉の響きはなんだか不思議な感じがする。

オライリーのメールマガジンを読んでいたら、プログラミングC# 第4版刊行のお知らせが書かれていた。


Jesse Liberty著 鈴木 幸敏、首藤 一幸、株式会社情報技研 訳
5040円

2006年2月発売予定とのこと。まだ amazon に登録されてないようなのでリンクは張らない。「プログラミングC# 第3版」では開発運用編と言語詳解編として分冊になってたけど、第4版では一冊にまとまったのかな? 原書は644ページもあるし、そうなんだろうな。

そろそろリファレンスとして一冊手元に欲しいな。第3版は仕事場では何人か持っている人がいるのですぐに借りることはできるけど、メモを書き込んだり、マーカーを使ったりできないしね。C# 2.0 に対応してるなら買おう。


ちなみに、原書ならば日本の amazon でもすぐに手に入る。

- Programming C# 4th Edition は C#2.0 と Visual Studio 2005 対応

うーん、原書は2005年2月なので C#2.0 は未対応な雰囲気・・・?

oreilly.com -- Online Catalog: Programming C#, Fourth Edition
http://www.oreilly.com/catalog/progcsharp4/

The fourth edition of Programming C#--the top-selling C# book on the market--has been updated to the C# ISO standard as well as changes to Microsoft's implementation of the language. It also provides notes and warnings on C# 1.1 and C# 2.0.

と思ったけど、上記解説によると C#2.0 向けの記述や警告があるとのこと。

amazon に掲載されている第4版の原書の表紙画像の右肩にも 4th Edition Covers C# 2.0, .NET 2.0 & Visual Studio 2005 と書かれてるし、それなら翻訳版も十中八九対応してるでしょう。

via: O'Reilly Japan News 第96号

2005-12-12 の「ビジネスロジックとは」にいくつかコメントや指摘を頂いた。

- ビジネスロジック = ドメインロジック

はてなブックマーク - ビジネスロジックとは
http://b.hatena.ne.jp/entry/http://sonic64.com/2005-12-12.ht ...

Dice-Kei 『ビジネスロジックをもっと簡単に…『手続き』とか？』
naoya 『[programming] なんか最近はドメインロジックって言ったりもするよね。』

あ、一言で表現するというよりは、「ビジネスロジックって何ですか?」と新人たちに聞かれたときに簡単に説明できるようにしておきたいってことなんです。全然言葉が足りませんでしたね。

今までは「ロジック」とか「シーケンス」とか「シナリオ」など言ってたものが、ここ数年で「ビジネスロジック」と呼ばれるようになったんです。しかも、ちょっと言葉の指す範囲が拡大している。で、それを簡潔に説明できないかなあと考えてました。

ドメインロジックって呼んでるのはファウラーと彼の本の読者というイメージがありますね。業務上の会話ではもうビジネスロジック一色で、ドメインロジックって言葉を見かけるのはウェブと書籍だけかなあ。そうそう、ドメインロジックはビジネスロジックと同義なので言い換えることができますが、「ドメインモデル」を「ビジネスモデル」と言い換えてる例を見かけないのは、経営の用語と混同しちゃうからからなんですかねえ。

- トランザクションスクリプト的

Landscape - エンジニアのメモ - ビジネスロジックとは
http://publicstaticvoid.main.jp/jugyo_blog2/?p=1729

トランザクションスクリプト的な考え方だなと思いました。

私もなんとなくそう思います。2005-12-12 で一番最後に挙げた「これらをどういった順番で処理するのか。」がトランザクションスクリプトっぽさを醸し出しているんでしょうね。

私の扱っているアプリケーションは小規模で、かつプラットフォームが .NET なのでトランザクションスクリプトというか Table Module で作ることが多くなりますね。そういえば、そもそもドメインモデルで作ったことってあったかなあ?

ドメインモデルの利点は頭では理解できるんですが、私の扱ってるケースではいまのところそこまで手をかける必要は無いと判断してます。Table Module だとトランザクションの開始と終了がシンプルで明確になって、ACID を確保しやすいのでよく使ってます。

- それ違う

ビジネスロジックとは
http://dkiroku.com/2005-12-12-10.html

ビジネスソング・ロックバンド NO YOUNG
http://noyoung.biz/blog/

全然違う! しかしこのバンドの歌詞、すごいなあ。

私はビジネスロジックを「アプリケーションがおこなう処理やルール、その手順」という意味で使っている。

ビジネスロジックという言葉を使うようになったのは、いつからだろう。私の周りで会話で普通に使われるようになったのは、3年から4年前くらいだろうか。書籍やウェブではもっと前から当たり前に使われてたんだろうけどね。

コンピュータ系の用語は、使う人によって意味が異なったり別の物を指していることがよくある。私の中の「ビジネスロジック」をもうちょっと詳しく書くと以下のようになる。

ビジネスロジックはそのアプリケーション固有の処理やルールを指す。逆に言うと、アプリケーションのうち、データアクセスやプレゼンテーション以外の部分。

アプリケーション固有の処理とは以下のようなもの。

・どこから、どんなデータを取得するのか。
・そのデータをどう処理するのか。
・どんなことを、どんなときにエラーとみなすか。
・エラーとみなしたときはどうするのか。
・これらをどういった順番で処理するのか。

私のビジネスロジックの定義は以上。もっと簡潔で明確な説明はないのかなあ?

「使い方によっては危険なメソッド」が呼ばれたときに、呼んだプログラマに対してなんらかの警告を出したい。できるならば、プログラムを実行する前に。

- 危険なメソッドが呼ばれたら警告を出したい

C++ で書かれたとある通信用 DLL ファイルがある。その 通信用 DLL を直接呼ぶとリソースの管理やマーシャリングが面倒なので、C# でラッパーを書いた。そのラッパーは、いろんな開発者に渡して使ってもらうことになる。ただ、ラッパーのソースを渡すことはできないので、コンパイルしたアセンブリとして配布する。

その後、C++ で書かれた通信用 DLL の特定の関数にバグがあることがわかった。一定回数以上その関数を呼ぶと、エラーしか返らなくなるというものだ。その関数はラッパー上では DllImport 属性でインポートしているだけなので、もとの DLL のバグが修正されない限りはバグが発生する。バグに当たるのを避けるため、C# で作ったラッパーの利用者に「その関数を使うのは危険だよ、呼ぶのは一定回数以内で済む場合だけにしてね」という警告を出したい。

できれば、コーディング中にそのメソッドを呼ぶコードを書いたら警告を出すとか、もしくは、コンパイル時に警告を出すようにしたい。実行時に警告を出すのでは遅すぎる。さて、どうするのがいいだろう。

- Obsolete 属性を付ければ警告を出せるけど、意味が違う

後輩はラッパーの該当メソッドに Obsolete 属性を付けることでこの問題に対処した。

C# プログラマーズ リファレンス Obsolete
http://www.microsoft.com/japan/msdn/library/ja/csref/html/vc ...

これなら、このメソッドを呼んでいる場合、コンパイル時に警告が出る。期待する動作だ。でも、意味が違う。Obsolete は「もう使われていない，すたれた；時代［流行］遅れの；役に立たない，不用の」といった意味だ。将来的に削除予定のメソッドにつける属性を、期待する動作をするからといって付けてしまうのは美しくない。それを許したら、「警告を出す」という目的のために属性が使われてしまう。

何か他に良い属性は無いかと思い、MSDN のドキュメントを探してみたが、良さそうなものがない。Alert 属性とか Critical 属性とか Warning 属性とか、Danger 属性とか Notice 属性とかないのかなあ。syslog だとあと EMERG と ERR と DEBUG があるけど、それはいらないな。カスタム属性を作る? うーん、この一か所だけのためにそうするのは手間だなあ。

XML ドキュメントコメントの ///<summary> </summary> に警告文を書いておけば、インテリセンスには表示される。しかし、それだけだと XML ファイルが参照されなかったり、何らかの理由でインテリセンスが表示されなかったときに対応できない。2004-08-25 の「DataSet でインテリセンスが効かない」みたいな現象が起きたときに困る。

- #warning は期待する動作ではない

Google で 属性 警告 生成 C# を検索すると、@IT の文書がヒット。

連載：C#入門　第19回 プリプロセッサとドキュメント
http://www.atmarkit.co.jp/fdotnet/csharp_abc/csharp_abc_019/ ...

自作のエラーや警告を発する

込み入ったプログラムを記述していると、C#の文法エラーではないが、プログラムの意図として間違いだとプログラマに伝えたい場合がある。特に個人ではなくチームで開発していると、他のプログラマに間違った使い方をさせないために、このような措置が必要とされることがある。これを実現するために、C#のプリプロセッサには、警告を発する「#warning」と、エラーを発する「#error」が用意されている。以下はそれを用いた例である。

#warning ってのがあるのか。なになに、以下のようにソース中に書くと、続く文字列を警告してくれると。

#warning This is a sample warning.

よしやってみよう。警告文をソース中に埋めて、と。あ、VS.NET 2003は 警告文に下線まで引いてくれるのね。コンパイル。おおっ、ちゃんと警告が出たー! 警告文字列は日本語でも大丈夫なんだね。って、ちょっと待て。これって危険なメソッドを呼んだ方のソースのコンパイル時じゃなくて、元のソースがコンパイルされたときに警告されるわけじゃん。いや、私はこのメソッドの危険性はわかってるんだってば。このメソッドを含んだ DLL の利用者に警告を送りたいのに、これじゃ意味がない。

- もう Obsolete 属性でいいよ

MVP (Microsoft Most Valuable Professional) の C# を持ってる人に聞いたり、Web の文書を探してみたが、結局有効な代案を見つけられなかった。私は実利主義。仕方がないので結局 Obsolete 属性を付けることにした。ただ、///<summary> </summary> のコメントには、Obsolete 属性を付けてるけど削除予定はないよ、ということを記述した。

C# でクラスライブラリを開発することになった。テスティングフレームワークである NUnit を使ってテストコードを書きながら開発したい。

- NUnit を使うと何がいいのか

テストの結果を可視化しやすい。
NUnit というフレームワークに則ってテストできる。

上記二点がテスティングフレームワークを使う理由。

「テストコードを使って、自動的にテストができる」というのは、テスティングフレームワークの利点ではない。「コードをテストするためのコード」すなわちテストコードを書いてテストするというのは、プログラマなら無意識にやってるはず。

テスティングフレームワークは、テストコードの書き方とテスト結果の出力形式を規定してくれるだけ。些細なことに思えるかもしれないが、この規定するということは重要なことだ。テスティングフレームワークを使わずに独自のルールに則って書かれたテストコードは、テスティングフレームワークのルールに則って書かれたテストコードに比べると、書いた人以外には理解しにくい。テスト結果の出力形式についても同様。

テスティングフレームワークを使って書かれたテストコードは、その構造についてある程度予想がつく。テスト結果の出力についても、どこに注意を向ければよいかわかる。ルールに則って書かれてるんだから当たり前。それがテスティングフレームワークを使う理由だ。もちろん、テスティングフレームワークが提供する便利な機能を利用するのも理由の一つではある。

たとえば、ASP.NET を使わなくてもウェブアプリケーションは書ける。でも、ASP.NET を使うとフレームワークに則ったウェブアプリケーションを書ける。その結果、アプリケーションは共通の基盤に則った構造を持ち、構造と出力形式について予想が付く。

- NUnit のインストール

NUnit のインストールは超簡単。

NUnit - Home
http://nunit.org/

ダウンロードページから NUnit-2.2.0.msi http://www.nunit.org/downloads/NUnit-2.2.0.msi をダウンロード。Next 連打でインストール完了。

- NUnit の使い方の概要

NUnit がやってくれるのは、ルールに則って書かれたテストコードを実行してその結果を表示してくれることだけ。テストコードは NUnit が自動生成してくれるわけじゃないので、自分で書く必要がある。NUnit を使ったテストしながらの開発は、以下のような流れで進む。

テストコードを書く。
ここで NUnit でテストを実行。テストが失敗することを確認する。実装がないので、すべてのテストが失敗するはず。

適宜 NUnit でテストを実行しながら実装コードを書く。
全部のテストが成功すれば完了。

- NUnit の使い方の具体例

実装コード用のクラスとは別に、テストコードを記述したクラスを用意する。

テストコードを記述したクラスから、実装コードを記述したクラスを「プロジェクト参照」で参照する。
ソリューションエクスプローラ上にある、テストコードを記述したクラスの「参照設定」を右クリックして「参照の追加」を選択。「プロジェクト」タブから実装コードを記述したクラスを選択する。

テストコードを記述したクラスから、NUnit の DLL を参照する。
ソリューションエクスプローラ上にある、テストコードを記述したクラスの「参照設定」を右クリックして「参照の追加」を選択。「.NET」タブから nunit.framework を選択する。
テストコードを記述したクラスで using NUnit.Framework; を追加しておく。

実装コードを記述したクラスと、テストコードを記述したクラスの名前空間は同じものにしておく。

いちおうこれで準備完了。

- NUnit GUI の自動起動

デバッグ実行時に NUnit GUI が起動するように設定する。これをやらなくても NUnit を使うことはできるけど、やっておいた方が便利。

ソリューションエクスプローラから、テストコードを記述したプロジェクトのプロパティを開く。
構成プロパティのデバッグの開始動作のデバッグモードを「プロジェクト」から「プログラム」に変更して適用ボタンを押す。
デバッグモードが「プログラム」になると、スタートアプリケーションのパスを指定できるようになるので、NUnit GUI のパスを指定する。私は以下をコピー & ペーストした。

C:\Program Files\NUnit 2.2\bin\nunit-gui.exe

あとはテストコードを記述したプロジェクトを「スタートアッププロジェクト」に指定してデバッグ実行すると、自動的に NUnit GUI が立ち上がる。ただ、立ち上がるだけで自動的にテストを実行してはくれないみたい。自動的にやる方法はあると思うけど調べてない。

2005年06月15日追記。自動起動するように設定するよりも、NUnit GUI あらかじめ起動しておく方が私に合っていることに気づいた。2005-06-15 の「NUnit はテストコードの更新を自動検出してくれる」を参照。

- NUnit 用のテストコードの書き方の概要

[TestFixture] 属性を付けたクラスは、テストクラスとして NUnit に認識される。
[Test] 属性を付けたメソッドは、テストメソッドとして NUnit に認識される。
[Test] 属性を付けたメソッド中で NUnit.Framework.Assert() を使って値をテストする。

バイナリデータをテキストデータ化する時によく使われる Base64 についてのメモ。

- Base64 で使用する文字の種類

大文字と小文字の両方のアルファベットと、0から9までのアラビア数字、/ スラッシュと + プラス記号を主に使う。 = イコールは一行の文字数が足りないときのパディング(詰め物)として使う。

以下、使用する文字。

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789/+=

種類は (26 * 2) + 10 + 2 = 64。
あ、64種類だから Base64 なのか。= を入れたら 65種類だけど。

- Base64 エンコード後のサイズ

英数字と記号だけで表現しようとするため、Base64エンコード後のデータのサイズは、エンコード前のデータに比べて 3分の4倍、すなわち 約133%に増大する。

- Base64 についての RFC

Base64 について言及した RFC は、RFC 3548が最新の模様。

RFC 3548
http://suika.fam.cx/~wakaba/-temp/wiki/wiki?RFC%203548
一部日本語訳がある。

今となっては RFC 3548を参照する方が良いと思うけど、メモ。

RFC 2045 の 6.8 Base64 Content-Transfer-Encoding
http://www.akanko.net/marimo/data/rfc/rfc2045-jp.txt

6.8.  Base64 Content-Transfer-Encoding

    Base64 Content-Transfer-Encoding は、人間的に読みやすい必要のない
  フォームにおいてオクテットの任意のシーケンスを表すように設計されてい
  る。符号化と解読のアルゴリズムは簡単である。しかし符号化されたデータ
  は符号化されないデータよりほんの僅か、約33%大きくなる。RFC 1421 にお
  いて定義されたように、この符号化は、実質的に Privacy Enhanced Mail
  (PEM) アプリケーションに使われるものと同じである。

    US-ASCII のサブセットの 65文字を使い、6ビットが印刷できるキャラク
  タとして表すことを可能とする（余分の第65のキャラクタ "=" は、特別な
  機能処理を意味するために使われる）。

    注意事項:
      このサブセットは、それが全く同じに ISO 646 (US-ASCII を含む)
  の全てのバージョンの代表を務める重要なプロパティを持っており、そして
  サブセットにおける全てのキャラクタは、 EBCDIC の全てのバージョンにお
  いても全く同じく表される。マッキントッシュ binhex 4.0 [RFC-1741] 、
  及び base85 符号化は、Level 2 ポストスクリプトの一部として、
  エンコーディングのような他のポピュラーな符号化が uuencode ユーティリ
  ティによって使用したことを指定した。これらの資産を分配しないこと。そ
  して、メールのためのバイナリトランスポート符号化処理が満たさなければ
  ならないような可搬性の要求を満たしてはならない。

    符号化プロセスは、４つの符号化された出力文字列が、入力ビットの２４
  ビットグループを表現している。左から右へ処理し２４ビットの入力グルー
  プは、３つの８ビット入力グループのシーケンスにより形成される。

    これらの 24ビットは、4つの連結された 6ビットグループ (各々がbase64
  アルファベットにおける 1桁の数字に変換される) のように、その時扱われ
  る。base64 符号化を経たビットストリームを符号化する時には、ビットの
  ストリームは、最初、最も多く重要なビットによって命じられると推定され
  なければなりません。すなわち、流れの最初のビットは、高いオーダービッ
  トの最初の8ビットバイトであり、8番目のビットは、低いオーダービットの
  最初の8ビットバイトなどである。

    各 6ビットグループは、一連の 64個の印刷可能な文字へのインデックス
  として使われる。インデックスによって参照を付けられた文字は、出力文字
  列に配置される。下記表１に示したこれらの文字は、一般的に再提供可能な
  ように選択されて、セットは、特有の意味によって、RFC 2046において定義
  されたSMTP（例えば、"."、CR、LF）およびマルチパートの境界デリミタの
  文字を遮断する（例えば "-"）。


                    表１: Base64 アルファベット

        値 符号化      値 符号化      値 符号化      値 符号化
        0 A            17 R            34 i            51 z
        1 B            18 S            35 j            52 0
        2 C            19 T            36 k            53 1
        3 D            20 U            37 l            54 2
        4 E            21 V            38 m            55 3
        5 F            22 W            39 n            56 4
        6 G            23 X            40 o            57 5
        7 H            24 Y            41 p            58 6
        8 I            25 Z            42 q            59 7
        9 J            26 a            43 r            60 8
        10 K            27 b            44 s            61 9
        11 L            28 c            45 t            62 +
        12 M            29 d            46 u            63 /
        13 N            30 e            47 v
        14 O            31 f            48 w      (穴埋め) =
        15 P            32 g            49 x
        16 Q            33 h            50 y


    符号化された出力ストリームは、わずか 76文字しかない行で表されなけ
  ればならない。すべての改行、または表１に発見されなかった他の文字は、
  ソフトウェアで解読する際に無視されなければならない。base64 において、
  データ、表１以外のキャラクタ、改行、及び、他の空白文字は、おそらく伝
  送エラー(警告メッセージ、またはメッセージ拒絶さえも、いくらかの情況
  下に於いては適切だろう)を示す。

    もし最大 24ビットで符号化されたデータの終りに利用可能であるなら、
  特別な処理が行われる。完全なエンコーディング量は、ボディの終りで常に
  完成される。最大 24 入力ビットが入力グループにおいて利用可能であると
  き、ゼロのビットは、必須の数の 6 ビットグループを形成するために加え
  られる(右に)。データの終りのパディング(穴埋め)は、"=" 文字を用いて行
  われる。全ての base64 入力が必須の数のオクテットであるので、次の場合
  のみが起こるかもしれない: (1)入力を符号化することの最終の量は、24ビ
  ットの必須の倍数である; ここで、符号化された出力の最終のユニットは、
  "=" パディングなしの 4文字の必須の倍数であろう。(2)入力を符号化する
  ことの最終の量は、ちょうど 8ビットである; ここで、符号化された出力の
  最終ユニットは、2個の "=" パディング文字が続いている 2文字であろう。
  もしくは (3)入力を符号化することの最終の量は、ちょうど 16ビットであ
  る; ここで、符号化された出力の最終のユニットは、1個の "=" パディング
  文字が続いている 3文字であろう。

    それがデータの終りの穴埋めにのみ使われるので、あらゆる "=" キャラ
  クタの発生は、データの終りに到達した (通過における切頭なしで) という
  証拠として考えられるだろう。しかし、違う。送られたオクテット数が 3の
  倍数であり、どの "=" 文字も無い時には、そのような保証が可能である。

    base64 アルファベット以外のあらゆる文字は、base64 符号化されたデー
  タにおいては無視されねばならない。

    base64 符号化が直接正規のフォームに変換されなかったテクスト材料に
  適用されるならば、改行に適したオクテットを使うために注意が行われなけ
  ればならない。特に、テクスト改行は、base64 符号化の前に CRLF シーケ
  ンスに変換されていなければならない。重要な注意点として、これがいくら
  かの実装(インプリメント)における前の正規化ステップにおいてより、むし
  ろ直接符号化処理(エンコーダ)によって行われるかもしれないことである。

  注意事項:
    base64 符号化の時にハイフン文字は全く使われないので、マルチパート
  なエンティティ内の base64符号化ボディ中の潜在的な境界デリミタについ
  て悩む必要はない。

クラス図のオブジェクトの表記法さえ身に付いていないのでメモ。

┏━━━━━━━━━━━━━━━━
┃ クラス名
┣━━━━━━━━━━━━━━━━
┃ プロパティ
┣━━━━━━━━━━━━━━━━
┃ メソッド
┃
┃ アクセシビリティは + # - で表す。
┃
┃ + public method
┃ # protected method
┃ - private method
┗━━━━━━━━━━━━━━━━

私の技量だとアスキーアートで表すのはこれが限界。

インデントの置き方に、ハードタブとソフトタブという呼び方があるようだ。知らなかった。

- ハードタブ

ハードタブはタブ文字 \t を使ってタブを表現する。タブなんだから \t を使うのは当たり前だと思うんだけど、ソフトタブという概念があるので、その反対のハードタブという呼び方があるように思える。

エディタの設定によって幅を変えられるのが利点。

- ソフトタブ

ソフトタブはスペースを使ってタブというかインデントを表現する。どの環境で見ても同じ幅になるのが利点。スペースの数が一般的でないコードの場合、見る人に違和感を与える恐れがあるのが欠点。

私にとってタブとはタブ文字 \t なので、スペースを使って表現したインデントをタブと呼ぶのは非常に違和感がある。

- 私がハードタブとソフトタブという呼び名を知った文書

私がハードタブとソフトタブという呼び名を知ったのは、以下の Rubyist Magazine のインタビュー記事を読んだとき。

Rubyist Magazine - 0004-Rubyist Hotlinks
http://jp.rubyist.net/magazine/?0004-Hotlinks

タブの話

ささだ
ところで、インデント 3 でハードタブを使っていらっしゃいますが、あれはなんででしょう？

ただ
(略) で、ハードタブを使ってるのは、そうはいっても俺はやっぱ 2 タブじゃなきゃとか 4 タブじゃなきゃとか言う人はいるはずで、ソフトタブだと自分の好みを押し付けることになるので嫌だなぁと。みんなハードタブ使ってくれりゃあ俺は全てのコードを 3 タブで読めるのになぁと常々思ってるんですけども。

- 私のハードタブとソフトタブの使い分け

私のハードタブとソフトタブの使い分け方針。

既に存在するソースの場合、元のソースの方針に従う。当たり前だ。じゃないと diff ツールのオプション指定を調整する必要が出てくる。

新規に書くソースの場合は、そのとき使用するエディタによってどちらを使うかが異なる。VS.NET だと必ずタブを使う。自動整形が強力だし。Delphi 使ってたときは・・・どうだったか忘れちゃった。たぶんデフォルトのままだと思う。

タブの幅もエディタによって異なる。VS.NET だと4かな。

複雑なデータ構造を理解できたとき。
望みの出力を得られたとき。
今まで長い時間のかかっていた処理が、ロジックの改良により短時間で終わるようになったとき。
全くコードを書かなくても問題を解決できたとき。
わかりやすくモデリングできたとき。

Javaコードの診断: 「テスト可能な」アプリケーションの設計
http://www-6.ibm.com/jp/developerworks/java/020125/j_j-diag0 ...

http://itpro.nikkeibp.co.jp/members/NBY/techsquare/20030605/ ...