最適化の原則 - Strategic Choice
最適化の原則磨く前にプロトタイプを作れ。最適化する前にプロトタイプが動くようにせよ。どういうこと？最初にプロトタイプを作るようにすれば、ごくわずかの成果のために多すぎる時間をつぎこむのを防ぐことができます。ボトルネックが何かがわかる前に最適化に走ると、設計を台無しにします。透明性や単純性を犠牲にしてスピード、あるいはメモリやディスクスペースの節約にこだわったあげく、コードが無理なものになったり、データレイアウトがわかりにくくなったりします。それらは、多くのバグを生み、莫大な作業を浪費します。そうしてまで得られたものはといえば、デバッグにかかる時間と比べてはるかに安い、リソース使用量のわずかな節約にすぎません。部分に対する半端な最適化が、全体の最適化の妨げになることもよくあります。設計を半端に最適化すると、「設計全体にわたった大きな効果が得られる変更」ができなくなるので、パフォーマンスが低い
アプリケーションとアーキテクチャのための戦略シナリオ2010
アプリケーションには、昨今の激変するビジネス環境下において、業務効率化への貢献のみならず、企業のビジネス目標の達成に沿った戦略的価値への貢献と、変化に対する柔軟性の獲得と資源の最適化の両立という緊急課題への対応が求められている。こうした課題の解決に対する圧力は、これまで以上に強くなっている。 すなわち、企業にとってどのようにITとビジネスを直結させ、ITをビジネスに貢献させるか。そしてビジネスを取り巻く環境に変化が生じ、その変化への対応が求められたとき、それを支えるITがいかに敏速に対応できるかが非常に大きな課題になってきているのである。 これまでアプリケーションといえば、個別の業務機能の実装および変更に対する対応などに焦点が当たっていた。だが最近のトレンドは、ビジネスそのものの目標に対し、どれだけ直接的に貢献できるかという方向に向かってきている。その文脈においては、企業はアプリケーション
システムの稼働時間について利用部門と取り決めを行う工程は？
問題 問32 あるシステムの開発において、システムを24時間連続稼働させることになった。稼働時間について利用部門と取決めを行う工程はどれか。 ア システム結合テスト イ システムテスト ウ システム要件定義 エ ソフトウェア方式設計 解説と解答 システム開発の上流で行われる工程には、システム要件定義、システム方式設計、ソフトウエア要件定義、ソフトウエア方式設計、ソフトウエア詳細設計などがあり、基本的にはこの順番で行われます。「システムを24時間連続稼働させる」という稼働時間に関する運用要件は、開発対象システムにおける最も基本的で、かつ非常に重要な要件です。 そのため、システム開発の最初の段階で利用部門と協議し、システム要件として明確に定義し取り決める必要があります。したがって、稼働時間について利用部門と取決めを行う工程は、システム開発の最上流に位置するシステム要件定義です。 よって、正解は
Value Objects と Immutable - かとじゅんの技術日誌
おつかれさまです。そろそろ、プログラミングに関するエントリも書かなければw DDDの勉強を開始するにあたって、一番最初にEntitiesとValue Objectsに出会う。 今回は、まず先にValue Objectsと関連が深いImmutableについて、考えてみよう。なぜ、Value ObjectsかというとOODの基礎をなすからだ。基礎が弱いとその上の建造物ももろいものとなってしまう。だからValue Objectsがまず先。なーんだ、ただのJavaBeansなんでしょ、と思うと痛い目にあうよw 値を表すのがValue Objects。説明することが目的のオブジェクトである。ここに説明されているとおり。 ● Value Objects（値オブジェクト）パターン エンティティとは逆に、たとえば「色」や「量」のように、その属性だけが重要で、アイデンティティを考えることに意味のないオブジェ
設計と実装の両輪 - かとじゅんの技術日誌
自分がC/C++で飯を食っていた 2001年ごろに某ゲーム機メーカでお手伝いすることなり、現場にいた外注メンバーもできる人ばかり。その同僚からデザインパターンとかって耳慣れない話を聞く。コンボジットとか、デコレータ作ってみましたとかいってるｗ 意味わかんねーよ的な迷い子ｗ 帰宅後必死に調べる。そして、GoF本がしばらくバイブルとなり典型的なパターン厨となる。 新たな気づきとしては、オブジェクト指向言語の実装機能(カプセル化、継承、多態)を理解した程度では、複雑な要件を実装していくことは困難だと体感した。何が必要かというと、デザインパターンなどを加味した上でのオブジェクト指向設計の力。 設計と実装の両面での考え方が必要 実装力というのは、クラスのAPIをどのように使いこなすかであって、設計力というのはクラスの構造や関連をどのように構成するかを決める能力だと思っている。設計は戦略であり、実装は
UIは正規化しない方がいいと思う - 六の日記はこっちになったぞ
曰く、「データ構造をこれこれこうすれば共通化できるでしょ。そうすると、この画面とこの画面とこの画面と・・・は同じデータを見る事になるんだから、分ける意味が判らない、意味がないでしょ。だから画面をひとつにしろって話でblur blur blur」 いやー、それ分けた方がいいと思います。 「えー？じゃあ、この画面とこの画面とこの画面・・・・と、何が違う？」 アクターが違う、ユースケースが違う、サブシステムからして違う、他色々考えるとあれもこれも違ってくると思う。というか、唯一違わないのがデータ構造、ただそれだけ。 そりゃ「出来る限りは」正規化というか共通化した方がいいと思うけど、データが正規化出来るという事実「だけ」を根拠にUIの正規化を正当化するのはおかしい。 稼働し始めると、ユーザーさんからどうせ「フォーカス順はこうした方が」「入力欄の並び順が」「この場合これが必須なので」とか、アクターや
［実践編］最初からSOAだった
BIGLOBEのファクトリー化には，最初から具体的なシナリオがあったわけではない。最終ゴールとして，ラインでいろいろなサービスやシステムを大量に作る体制や，ノンプログラミングかつ組み立て式で開発しているイメージはあったが，実際に事業活動をする取り組みの過程で，今の形が出来上がってきた。今回は，そういった過去の取り組みの歴史と，実際現場を運営するにあたっての現実問題について説明する。 最初からSOAだった BIGLOBEは，PC-VANというパソコン通信サービスとmeshというインターネット接続サービスを統合して立ち上げた。既にある会員管理システムや課金請求システムとWebのシステムをつなぐということが必要となった。 問題となったのが，どういう機能分担で，どういうインタフェースでつなげば，うまくいくだろうかということだった。Webサイトを担当している部門は多数あり，個々の部門から「会員情報の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
higaさんによるダイコン時代の設計方法 - tpircs