複雑度と単体テストケース数の相関関係 - プログラマの思索
garyoさんから、ソースの複雑度と単体テストケース数について有益なアドバイスを示唆してもらったので、メモしておく。 ◆SourceMonitor Version 2.4 SourceMonitorはフリーで、以下の言語のソースのソフトウェア複雑度（McCabeのサイクロマチック数）を測定できる。 例：C++, C, C#, VB.NET, Java, Delphi, Visual Basic (VB6) or HTML ◆McCabe's cyclomatic complexity SourceMonitorで求められる複雑度（McCabeのサイクロマチック数）は、モジュール内の分岐の数（＋ループの数）で計算される。 複雑度の数値は、下記の意味を持つらしい。 10 以下であればよい構造 30 を越える場合，構造に疑問 50 を越える場合，テストが不可能 75 を越える場合，いかなる変更も
Extended .NET 2.0 WebBrowser Control
Download demo project - 83.5 Kb Download source - 115 Kb Contents Introduction The goals, challenges, and solutions Handling Script Errors Blocking unwanted pop-ups Enabling functionality for tabbed browsing or MDI browsing Making sure that a window is closed when it is closed by script Creating the extended WebBrowser component Implementing IWebBrowser2 Implementing DWebBrowserEvents2 Using the c
Standalone Classes パターン : スパゲティにしない設計 | システム設計日記
たくさんのオブジェクトが、からみあってくると、ソフトウェアは手がつけれなくなる。 いわゆるスパゲティコード。 ・読みにくい（理解しがたい） ・テストコードが書きにくい（特に、セットアップ） ・変更がしにくい／こわくてできない ．．． スパゲティにしたいわけじゃない。でも、いつのまにか、そうなっちゃう。 こうならないために、どんな設計・実装をこころがけるべきか？ 「依存」を見たら、泥棒と思え 当たり前のように使っている、コードの中の依存関係。 ・インスタンス変数で他のオブジェクトへの参照を保持 ・メソッド内の一時変数で他のオブジェクトへの参照を保持 ・メソッドのパラメータで渡ってくる、他のオブジェクトへの参照 ．．． こういう「依存性」を、すべて疑ってかかる。 スパゲッティになりたくなかったら「全て」を疑う。 「ほんとうに必要か？」 「他のやり方があるのでは？」 参照やパラメータ渡しがあるか
しなやかな設計 : 小さく、はじめてみる | システム設計日記
Domain-Driven Design の１０章 Supple Design ( しなやかな設計 ) は、ドメイン駆動設計を実践していくための、設計・実装の基礎テクニック集なんだと思います。 ・ドメインをより深く理解して、ほんとうに役に立つソフトウェアを開発する。 ・隣接ドメインを含めて、より広い範囲の問題に取り組む。 この章の基礎テクニックを習得して、日々の設計・実装で、ふつうに使えるようになると、ドメインをもっと深く理解し、もっと広い問題に取り掛かる、土台がしっかりしてくる。 ソースコードが改良され読みやすくなり、開発者のドメイン駆動設計の実践スキルがしっかりしてくる。 どこから手をつける？ エバンスは、１０章の最後で、広い範囲を、一気に手をつけると、エネルギーが分散してしまう。まず、狭い範囲に絞って、そこで、じっくりと「しなやかの設計」の基礎テクニックを実践してみることを薦めていま
しやなかな設計 ( Supple Design ) はボトムアップで | システム設計日記
Supple Design （しなやかな設計)のパターンと設計スタイルは、主な適用範囲は、狭い範囲ですね。 ビジネスロジックのちょっとしたかたまりを、Money とか、 BusinessDate とか、PersonName とか、役割が単純で、独立した、プリミティブなドメインオブジェクトにカプセル化する作業。 こういう単純だけど、役割が明確なドメインオブジェクトが揃ってくると、全体のコードがわかりやすくなる。 その結果、もっと、大きなモデリングや設計の課題に取り組みやすくなる。 レイヤ構造 Supple Design を地道に実践していくと、ドメインオブジェクトの群れが、レイヤ構造になってくる。 上から、 アプリケーションサービス層 ドメインモデルを使う側、クライアントコードの置き場所 ドメインモデル層 問題領域の知識が豊富 ( knowledge rich )なドメインモデルの本体
継続的インテグレーションを再考 - プログラマの思索
「継続的インテグレーション入門」を読んでみて、もっと早く読んでおけば良かったと後悔した。 内容がとても素晴らしかったので、理解できたことをラフなメモ書き。 【元ネタ】 Togetter - 「SIerは自動化する対象が違っているのでは？」 Continuous Deliveryをポチッた - watawata日記 Continuous Delivery - haru01のめも アジャイルなインフラのつくり方とデータマネジメント - メソッド屋の日記 インフラやデータ移行の自動化～アジャイル開発の最後の問題: プログラマの思索 Continuous Delivery～TDDとCIの次に現れた自動化の概念: プログラマの思索 【1】「はじめに」に、キーボードに「Integrate」というボタンが貼られていて「こんなに簡単ならいいのに」という雑誌の広告から始まる。 この挿話は、ビルド＆デプロイの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer