設計」カテゴリーアーカイブ

MVVM+MVCパターンを発注視点で分割する

MVVM+MVCパターンを大規模システムにスケールする | Moonmile Solutions Blog で書いた「大規模プロジェクトを発注視点で分割する」の項目をもう少し掘り込んで、思考実験してみましょう。 何故、発注視点を先にやるのか? もし、ソフトウェア開発が車の購入のように、買ったその日から使えるとすれば(既存のシステムや、クラウド上にあるシステムに沿うならば、「即日」も可能ですよね)、開発している途中の都合は問題ではありません。機能的な価値よりも、機会損失を加味して早期導入によるメリットのほうが大きいパターンを考えてみます。実際には、開発期間が0日であったとしても、実際に使う期日はもっと先にあって、しばらく使わないという塩漬けな状態があったりするのですが、できることなら、すべてを0日で揃えるのが一番価値の高いものでしょう。 そう考えると、ソフトウェア開発における要件定義のまとめ … 続きを読む

カテゴリー: 設計 | コメントする

MVVM+MVCパターンを大規模システムにスケールする

大規模プロジェクトで MVVM を導入するときの注意 | Moonmile Solutions Blog をもう少し突っ込ん考えてみます。大規模といっても、みずほみたいにできあがらなくて破綻したパターンもあれば、特許庁の場合のように設計時で破綻した場合もあれば、豊洲のように作ってからそもそも破綻しているのもあるわけで、常々プロジェクトの成功率は30%程度なので、大抵は破綻します。まあ、途中でプロジェクトとしてうまく失敗させる(一気に解散する)か、うまくプロジェクトを軟着陸できずにだらだとお金をつぎ込んで「失敗」させることがことができず終わる二百三高地になるやもしれません。 さて、それなりの資源(人と金)をつぎ込んでペイができるかどうかのバランスを保つ場合(公共事業の場合は、バランスを保たなくてもよい場合もあるので別)、「失敗が許されない」パターンがあります。しかし、失敗が許されないの対偶を … 続きを読む

カテゴリー: 設計 | コメントする

アリスはプラダに猫がいることを知らない

ありぷらなネタ的には、weekpointer あたりをカプセル化して、LINQ の遅延実行風に、実際の参照時に中身を取ってくることができる。例えば、ストリーム的に流れてくる計測データの大半を捨てて、UI の都合で定期的にピックアップ表示する感じ。 — Tomoaki Masuda (@moonmile) 2016年9月14日 な感じで、内部データを遅延して持って来る例を作ってみる。 実行するとこんな感じ 意味合いとしては、アリスはプラダのバックを3つ持っている(pradaRed、pradaBlue、pradaYellow)んだが、中に猫がはいってるかどうかは分からない。どの順番で開ける猫がいるかわからないし、猫がいるかどうかも知らない。でも、開けると猫が入っているか、また猫が入ってないかわかる。というシュレディンガーなプラダな猫の話。 cats は最初から用意されているので、外部データとし … 続きを読む

カテゴリー: 設計 | コメントする

データ指向で画面設計をする手順

ここでいう「データ指向」というのは、古くはホストコンピューターの時代から連綿と続いているIBM 内の秘伝のタレ(かな?)のことで、昨今の O/R マッピングの話が出る以前の設計と実装手順のことです。20 年以上前ってことになるかなぁと。 テーブル構造を作成する テーブルへアクセスするCRUDを記述する テーブルを連結して一覧する方法を記述する 画面を設計する いきなり、テーブル構造(データ構造)から始めているのが「データ指向」の所以です。オブジェクト指向の場合は、どのデータが「存在するのか」を調べた後に、どのまとまり(クラス)にするのか、という整理の仕方(オブジェクト図からクラス図の設計の流れがそれ)をしますが、データ指向の場合は、まず、まとまったデータがいきなりあって、そこからスタートします。 そして、データ指向で実装をする場合には、後戻りをしませんッ!!! ここは重要です。データ指向を … 続きを読む

カテゴリー: 設計 | コメントする

データ指向設計でプロジェクトを成功に導けるのか?

思考を廻しておくために、ちょっと続きを オブジェクト指向設計とプロジェクトの成功とは無関係なのか? | Moonmile Solutions Blog http://www.moonmile.net/blog/archives/2527 「○○設計」や「○○手法」を使う場合、因果関係は薄いよからスタートすると、「じゃあ、何を使えば成功率は高くなるのか?」ってな話になります。まぁ、直接的な利益追求の話でいえば、直近のプロジェクトが云々ということになり、では先行きの学習のほうは?ということなりますが、まぁ、直近のプロジェクトを優先してみるという仮定で。 明確な形になっているかどうかは別として、要求定義→設計→実装→試験な、感じでソフトウェア開発工程が流れていくのは確かなことで、これがサイクル的に極めて早いか(アジャイル的に)、遅いか(ウォーターフォール的に)の違いはあるものの、程よく分けておく … 続きを読む

カテゴリー: 設計, プロジェクト管理 | コメントする

オブジェクト指向設計とプロジェクトの成功とは無関係なのか?

ちょっとリハビリテーションがてら徒然に。 結論から言うと、オブジェクト指向設計を導入したからといって、プロジェクトが成功するとは限らず、逆にプロジェクトが失敗したからといって、オブジェクト指向設計を導入しなかったから、というには言えません。当たり前ですが…因果関係はそれほど強くない。 「○○設計」なり「○○手法」というものがあって、それを導入したからと言って必ず成功するとは限らない。言えるのは、成功する確率が上がるということしか言えない。逆パターンもあれば、導入すると失敗するとは言えないけれども、失敗する確率が上がる(成功する確率が下がる)パターンもある。これは、何を言うのかというと、「○○手法」を導入する場面、場所(人員も含む)、規模など諸々の条件があって、それが有効に働く場合と、働かない場合、むしろマイナスに働いてしまう場合もある、ということ。 が、かといって「○○設計」な … 続きを読む

カテゴリー: 設計, プロジェクト管理 | コメントする

フェイルセーフなコードを書くには?

フェイルセーフというのは、機器故障しても安全なほうに倒れるシステムの組み方で、原発の制御棒(BWRはフェイルセーフに反しているが、PWRはそれが解消されている)が重力で落ちるようになっていたり、原子炉自体が半分以上地下にあったり、冷却水が上から下へ流れるようになっていたり(これもBWRはフェイルセーフに反している)する仕組みです。 フェイルセーフ – Wikipedia http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A7%E3%82%A4%E3%83%AB%E3%82%BB%E3%83%BC%E3%83%95 ちなみに、フォールレトラントのほうは、故障が起きても処理を継続できる仕組みで、フェイルセーフのように「問題が起きても大丈夫」という点では一緒なのですが、問題発生の後が異なります。 フェイルセーフは、問題発生→安全に機能停止 フォ … 続きを読む

カテゴリー: 開発, 設計, UIDD | 2件のコメント

コードを短くすると単体テストが楽になる、の検証編

さて、リファクリング前とリファクタリング後のソースコードがありますが、これがどの程度「安全」にコーディングができるのかを検証していきます。 検証するためには、何らかの定量的な手法が必要です。 # ちなみに「定性的な手法」は「ああ、コードが短くなったね」という感想が根拠になりますw コードの複雑度を測定するのに、if 文などの制御文や使われている変数の数を勘定する方法がありますが、ここではもうちょっと簡単に、「変更できる箇所」を数え上げていきます。変更できる箇所というのは、コーディング時に間違えやすいところ/間違える可能性があるところで、≒テストが必要なところ、と言えます。 具体的には ・制御文でカウント ・比較文でカウント ・変数の宣言でカウント ・メソッド呼び出しでカウント ・メソッドの変数でカウント のように、ちまちまと数えていきます。 で、数え上げたのがこれ。 ▼リファクタリング前 … 続きを読む

カテゴリー: 開発, 設計 | コメントする

コードを短くすると単体テストが楽になる、の再実装編

前回の記事 コードを短くすると単体テストが楽になる、の実装編 | Moonmile Solutions Blog http://www.moonmile.net/blog/archives/2160 で実装上の間違いが発覚したので、やり直し。 ■根本的に何をやりたいかを考え直す のところで、全ての列をコピーするために dest.Rows.Add( r ) なんてことをしていましたが、この変数 r は既に src のテーブルで使っているので Add できないんですよねぇ…というバグが。 ちょっと、動作確認(というか xUnit)していないのがバレバレです。 そんな訳で、 のコードが冗長なので、 のように「全ての列をコピーしたい」というところから再スタートします。 ■根本的に何をやりたいのかを考える。 さて、 のところは、全ての列の値をコピーしているところなので、かなり冗長です。 … 続きを読む

カテゴリー: 開発, 設計 | コメントする

コードを短くすると単体テストが楽になる、の実装編

前回は理論的なところを説明したのですが、では具体的どうするのか?ということで。 コードを短くすると単体テストが楽になる、の証明 | Moonmile Solutions Blog http://www.moonmile.net/blog/archives/2157 最初に、こんなコードがあるとします。 何をやっているかというと、元のデータテーブル(src)から年齢(age)が20才以上の人を、別のデータテーブル(dest)にコピーしています。 分かり易いといえば分かり易いような(事実、これを分かり易いと主張する方も多いので)、分かりにくいと言えば分かりにくいというような微妙なコードです。 なので、個人的な視点から「わかりやすい」か「わかりにくい」かというのは生産的ではないので、業務の視点や保守の視点から、このコードを変えていきます。 コードをうまく整理すると、コード上の情報が消えて(見えな … 続きを読む

カテゴリー: 開発, 設計 | 2件のコメント