現場で役立つシステム設計の原則を組織に適用する仮説

スポンサードリンク

現場で役立つシステム設計の原則
増田亨さんの本
変更を楽で安全にするオブジェクト指向の実践技法と副題がついています

以前、TAGにて実施された勉強会に参加したところもっと知りたいと考え本書を購入


本の内容から

ifとswitchからみなおす
型を作って条件を埋め込む
nullを許さないテーブル設計

サブテーブルを作る(テーブルに引きずられない)
業務の理解が必須
三層+ドメインモデルで分離
画面は関心ごとで独立
開発プロセス、契約、マネジメントの話

などなど、詳細は本を読んでもらうとして
労働集約型システム構築からしなやかに
オブジェクト指向型に移行する方法
を妄想してみる


ここから仮説(妄想も含む)

(所属組織の今までのやり方や制約条件がありますが、書いてません。推測で埋めてください)

まずオブジェクト指向型言語に慣れる
業務知識抜群のエース級メンバーがコードを書けるようにする
設計、レビューだけではなく主になるロジックは理解者が書いた方が早い、伝言ゲーム不要
動くものでレビュー、合意できるような計画と契約(書面での合意はしんどい)
業務フローから同じ業務ロジックを抽出し大事な処理にエースを担当とする
ベースプログラムは必要だがコピーして使いまくるのは避けたいか、、、バランスが難しそう。非機能要件のみを実装したベースプログラムまででよいのか?
設計書の雛形をコピーして使うやり方も変えたい
機能単位担当を変えて業務ロジック単位に担当をつける.WBSも分ける
DB設計はメインテーブルとサブテーブルで分けることでやれるのか?
誰がどこまで詳細把握するか、重い、複雑な業務ロジックを作り込むメンバーと全体をみるメンバー両方にエース級を置く?
コードが具体的でみんなが読めれば把握の問題は解決するのかも
どこの層に何を書くかのチェック方法
経緯と決定の記録の関係者との共有、ソースの変更履歴(redmineやgit)
これができればいつのまにかマイクロサービス化も可能
役割、責任分担は分けるのではなく、重ね合わせる。または重ねている役割を作る

まだまだ出てきそうなので、
定期的に加筆するとして
効果が出そうなものは策を講じていこう


2019年5月11日に
レガシーをぶっつぶせ。現場でDDD!
とイベントにも参加するので
仮説をどう解決していったかの確認をするつもりです


第16回redmine.tokyoのみどころ&LT #redmineT

やりたいこと と できること

関連記事

  1. 価値からはじめるビジネスデザイン 匠Method…

    以前、要求開発アライアンスで匠Methodを知った…

  2. GCPUG TOKYO JUNE 2018に参加…

    GCPを学びたいなという思いが以前からあったので、GCPUGに初参加…

  3. 要求開発アライアンスでエンタープライズアジャイル…

    要求開発アライアンス以前から興味がありました毎月定例会を…

  4. 妻の応援でイオンモール川口前川へ

    蕨駅からバスに乗りイオンモール川口前川へ来た理由は妻がコ…

  5. テスト戦略を語る夕べ第5回に参加

    初参加思いつくままメモですプロジェクトのテスト戦略から組…

  6. 自分の得意なことが陳腐化する状態を考え、そうなら…

    2017年6月に行われたプロジェクトマネジメントDAYに参加しました…

  7. Baseball Play Study 2019…

    さあ、シーズンも開幕となるとBaseball Play Study…

  8. PMI日本支部 創立20周年記念セミナーに参加

    PMPに合格して約10年PMIの企画するセミナーに初めて参加しま…

PAGE TOP