役割駆動設計で巨大クラスを爆殺する - Qiita
大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、ドメイン駆動設計を基本思想とする「役割駆動設計」を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 小さくシンプルな構造に落とし込み、堅牢で変更容易性の高い設計へ昇華させる。 例１：筆者をモデリング 分かりやすくなるよう、まず私を例にモデリングしてみます。私は以下のような特徴があります。 IT企業の従業員 家族がいる(妻, 子供) 趣味でゲーム制作している ダメな設計 何も考えずに人クラスとして設計すると、よく以下のような構造になりがちです。 従業員として仕事をする、父親として家族サービスする、趣味としてゲーム制作する、それぞれのメソッドが備わってい
Git活用法 ー コードはいつも1行ごとにドキュメント化されている | POSTD
コードには1行ごとに隠しドキュメントがあります。 次のコードスニペットの4行目を書いた人は、何か理由があってDOMノードの clientLeft プロパティにアクセスしたのでしょうが、結果的に何もしていません。これはかなり不可解です。なぜこうしたのか、あなたは説明できますか？ 今後、この呼び出しを変更したり削除したりしても安全でしょうか？ // ... if (duration > 0) this.bind(endEvent, wrappedCallback) this.get(0).clientLeft this.css(cssValues) 私ではなく他の人があなたにこのコードを見せたとして、誰がこの行を記述したのか、どんな理由があったのか、このままの状態にしなければいけないのか、あなたはおそらく説明できないでしょう。ただし、プロジェクトを進めているときは大抵の場合、バージョン管理シス
伊藤直也氏が「Web開発は高度化している」と語る理由と、押さえておきたい3つの技術領域【2014年前半のインプットlog】 - エンジニアtype
KAIZEN platform Inc. Senior Technology Advisor 伊藤直也氏（@naoya_ito） 2002年に新卒入社したニフティでブログサービス『ココログ』の開発担当となり、一躍有名になる。その後、はてなで『はてなブックマーク』など各種サービスを立ち上げ、2010年にグリーへ入社。2012年に同社を退職して以降は、フリーランスとしてベンチャーの技術顧問などを請け負う。自身のブログ『naoyaのはてなダイアリー』が人気 「Webアプリの実装で差別化は無理」という考えが変わった 現在、KAIZEN platform Inc.をはじめ複数社の技術顧問を務めている伊藤直也氏。「普段から、アウトプットの目的なく技術の勉強をすることはほとんどない」という性分から、今年上半期は「顧問としてベストプラクティスを提供するために知っておくべき領域」にフォーカスして情報収集を
人員を増やさず，より多くのソフトウェアを提供するには
ソフトウェア製品やサービスに対するニーズの増加に伴って，企業の開発能力を向上させるための方法が求められている。多くの企業が選択するのは，人員の追加によるスケールアップだ。このアプローチに対して一部の人々が疑問を持ち，人員を増やすことなく，より多くのソフトウェアを提供する方法を提案している。 Robert Martin氏は"Horders of Novices (初心者の集団)"というブログ記事で，少数の専門家チームによるソフトウェア開発を提案する。 これ以上，初心者を増やす必要があるのですか？ 大して能力のない連中をさらに投入したところで，優れたソフトウェアが早く開発できるものでしょうか？ ソフトウェアの問題は，本当にマンパワーだけの問題なのですか？ コーディングはレンガ工事と同じなのですか？ 左官工の数が多ければ多くのレンガを積めるように，コーダが多数いれば，コードも多く書けるでしょう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
: _
