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

スポンサードリンク

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

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


本の内容から

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

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

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


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

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

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

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


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


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

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

関連記事

  1. 吉祥寺 ああ吉祥寺 吉祥寺(吉祥寺.pm28に途…

    吉祥寺.pmしなやかさと発表内容の幅広さがいい勉強会 い…

  2. プロジェクト管理強化読本 〜PMOがいる組織とい…

    セミナー受講のまとめです品質管理担当+PMOの方のセッションで…

  3. Account Code 5でZaの極意と社内契…

    【計数管理業務xIT】Account Code業務系システムから…

  4. 匠らじお塾に参加 #takumijyuku

    匠塾 半年に一度参加しているイベント匠methodをちゃんと学ん…

  5. たたかう、にげる、ぼうぎょ でチーム力向上

    沢渡あまねさん著の「ドラクエに学ぶチームマネジメント」を発売日に購入…

  6. イシューからはじめよのワークショップに参加

    イシューから始めよ 知的生産性のシンプルなの本質2010年の本だけど…

  7. 「便利屋斎藤さん、異世界に行く」が楽しい

    Twitterには漫画がたくさん流れてます斜め読みするの…

  8. #BPStudy 162〜アジャイルな組織のつく…

    bpstudy毎月開催しているビープラウドの勉強会今回は…

PAGE TOP