実践 ICONIXプロセス : コメントは危険な兆候

プログラムに書くコメントは悪い習慣です。設計やコードが破綻する危険な兆候です。

ドメインモデルから出発して、ユースケース記述を元に洗練させてきたクラス図は、ドメインオブジェクトのクラス名、メソッド名は、意図が明確で、分かりやすい名前になっているはずです。

フレームワークなど実装の足場クラスに関連するクラス名やメソッド名も、意味の明確な名前になっているはずです。(フレームワークの意図が理解していることが前提)

十分の検討されたクラス構成だと、ひとつのクラス、ひとつのメソッドはシンプルになります。
マーチンファウラーの「リファクタリング」や、Kent Beck の Implementation Patterns を一通りマスターすれば、ローカル変数名やプライベートな下請けメソッド名も、意図が明確になっているはず。

コメントを書く必要があると感じたら、設計やコーディングを再検討してください。

・クラスやメソッドの役割はシンプルで明確か?

答えが No なら、クラスやメソッドの分割を考えましょう。

・クラス名、メソッド名、変数名は意図を表しているか?

答えが No なら、名前をより分かりやすく変えましょう

・ロジックがシンプルで分かりやすいか?

答えが No なら、リファクタリングや Implementaion Pattern を勉強して、ロジックを単純明快に改善するテクニックを学びましょう。

いずれのケースも、わかりにくさを改善するポイントは、設計であり、命名であり、コードです。
コメントで説明しようとしてはいけません。

良いコードとは、極端にコメントが少ないけど、読みやすいコードになっている、ことです。

実践 ICONIXプロセス : コーディングは設計レビューである

コーディングは設計レビューです。

ドメインモデルから出発し、ユースケース記述、ロバストネス分析、シーケンス図作成をして完成させた詳細設計(詳細クラス図)の妥当性を実証するために、コードを書く。

アーキテクチャを検討して、フレームワークの選定やレイヤやパッケージ構成の妥当性を検証するためにコードを書く。

コード書きは、設計の不備を見つけ出す最も効果的な手段です。

設計もアーキテクチャも、実装前は、非常に脆弱です。
どんなに設計レビューを行っても、動くソフトウェアで実証しない限り、多くの不備と結果を残しています。

コードを書いて、実際に動かしみることで、設計の脆弱性を検出し、修正して強靭な設計に改良しつづけましょう。

実践 ICONIXプロセス : コードと設計の不一致

コードと設計の不一致

コードを書き始めると、設計の不備が見つかることがあります。

設計とコードの同期を必ずとりましょう。
ICONIXプロセスでは、こういう不備はそれほど頻発しないはずです。それほどたいへんな作業にはなりません。

コードと設計の不一致を見つけたら、まず、設計不備の発生原因を考え、プロセスの実施方法の改善の手がかりにしましょう。

プロセスの改善

なぜ、その設計の不備を、コードを書く前に検出できなかったのでしょう?

・詳細設計レビューで見逃した?
・予備設計レビューで見逃した?
・要求レビューで見逃した?

同じような設計不備を防ぐためには、どこでどんなことをすればよいか、メンバーでいっしょに考えましょう。
こういう地道なプロセス改善活動が、今後の開発活動を楽にしてくれます。

コードが複雑になってきた

あるユースケースの実装が、数時間で簡単に終わらないとしたら、立ち止まって考えましょう。
設計になにかおかしいところがあるはずです。

ICONIXプロセスでは、クラスも、メソッドも名前が決まって、オブジェクト間の協調動作もモデル化をした後でコードを書きます。

それなのに、ひとつのメソッドが10行を超えたり、大量の下請けメソッドを設計しなければいけないとしたら、設計が単純すぎた可能性があります。

ビジネスロジック

複雑なビジネスロジックを実装するために、何時間もコードと格闘しなければならないとしたら、ドメインモデルの設計が不十分な証拠です。

ビジネスロジックは、業務の知識です。業務の知識を整理したものがドメインモデルです。ですから、ドメインモデルがしっかりしていれば、その実装は、簡単なメソッドの組み合わせになるはずです。

業務の知識の整理(=ドメインモデルの作成)に立ち返りましょう。
けして、コードとの格闘で乗り切ろうとしてはいけません。

フレームワーク

フレームワークを使うために、トリッキーで複雑なコードを書く羽目に陥ることがあります。ちょっとしたことを実現するために、XMLファイルと長時間格闘することもあります。

おそらく、フレームワークの使い方を間違っているか、今回のソリューションには不適切なフレームワークを選択している可能性があります。

アーキテクチャの検討作業をもう一度やりなおしましょう。
けして、コードとの格闘で乗り切ろうとしてはいけません。

実践 ICONIXプロセス : 設計をそのまま実装する

ICONIXプロセスでは、コードを書き始めるまえに、分析・設計とそのレビューに時間とエネルギーを使ってきました。本当に必要なことだけを、必要な時だけやる、というアジャイルの思想が徹底した実践的な分析・設計です。

設計をそのまま実装できるかどうかのバロメータは、コードを自動生成を試みること。

ドメインクラスは、文句無く自動生成できます。(メソッドの中身は空っぽですが)
シーケンス図作成時にクラス図に追加した MVC や 永続化のメカニズムのためのクラス群も自動生成できますね。

テーブル定義のDDL文も自動生成できます。

エディタでゼロから記述するクラスが必要だったら注意信号です。
なぜ、クラス図に、そのクラスの設計モデルがないのでしょう?

自動生成したクラスがそのままではコードとしては使えないとしたら注意信号です。
クラス図に何か不備があります。

ICONIXプロセスは、設計(モデル)をそのままコードにすることを追求した開発方法論です。
ですから、コードの自動生成には徹底的にこだわってください。

Enterprise Architect のように最近のモデリングツールであれば、モデルとコードを双方向で生成できるし、どちらかを変更した時に、同期をする機能もあります。

発想として「モデルをそのままコードにする」ことにこだわりましょう。

不十分な要件定義・分析・設計を、コード作成時にリカバリーすることはムリです。納期直前で、深夜残業、休日出勤の連続、あるいは、リリース後の障害の嵐、いずれにしても、デスマーチにまっしぐらですね。

ICONIXプロセスは、要件定義・分析・設計をきちんとやることで、速く楽にソフトウェア開発をしようという発想です。実際にこれに取り組み始めて、その実践的なやり方と、具体的な効果に驚きました。
モデリングの初期の段階から、コードでの実装をかなり意識していることがICONIXプロセスの特徴であり、良い点だと思います。

詳細設計まで終われば、コードを自動生成して、簡単なメソッドを記述して、はい完成、という感じですね。

実践 ICONIXプロセス : コードレビューとモデルの更新

ICONIXプロセスでは、コードとモデルは完全に一致することを目指します。

・モデル(設計)をそのまま実装します。
・そのために、できるかぎり、モデルからコードを自動生成します。
・コードとモデルの不一致を検出します。(コードレビューの実施)
・不一致があれば、コードまたはモデルを修正し、一致させます。

次の作業の土台づくり

コードレビューとモデルの更新作業は、後始末の作業ではありません。
次のユースケースの設計と実装の土台を作るための準備作業です。

動いているコードは価値があります。しかし、それが次ぎのステップの良い土台かどうかは別問題です。
次の開発に生かすために、コードを洗練し、モデルを更新すべきです。

コードの洗練

動いているコードを、丁寧にチェックし、問題があれば修正します。
実装パターンとして、次の作業の良い指針となるように、コードを洗練させましょう。

そうでないと、不良コードがじわじわと、システム全体を蝕んでいきます。

モデルの更新

設計(モデル)とコードの不一致があり、コードが正しいなら、モデル、特に詳細クラス図を徹底的に修正します。
詳細クラス図、特にドメインオブジェクトを更新し、洗練させます。問題領域の知識(の実装)を洗練させておけば、そのドメインオブジェクトの再利用のチャンスが広がり、効果が大きくなります。

後始末ではなく準備作業

コードのレビューとモデルの更新は、開発作業の後始末ではなく、これからの作業をもっと楽にやるための準備です。
この準備に時間をかけることは、十分な見返りを期待できます。

calendar
      1
2345678
9101112131415
16171819202122
23242526272829
3031     
<< July 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM