Download as PDF, PPTX
毎日が越境だ！
- 1. 毎日が越境だ！ エンジニアの学習と成長 有限会社システム設計 代表 ギルドワークス株式会社 取締役 増田亨 DevLOVE201 越境ジャーニー
- 2.
- 3. エンジニアの学習と成長 3 Special thanks to 慶應義塾大学湘南藤沢キャンパス 井庭研究室 http://learningpatterns.sfc.keio.ac.jp/index.html
- 4.
- 5. 分析設計のスキル：私のアプローチ • Modularity モジュール性 –高凝集 疎結合 • 「型」によるモジュール化 – データとロジックのカプセル化 – 小さなインタフェース、少ないインタフェース • ドメイン固有の「型」の発見と実装 – 金額型、数量型、日付型、… – 顧客区分、商品区分、在庫区分、… • ドメインロジック（ビジネスルール）の発見と整理の技法
- 6. モジュール性の探求＝分析設計スキル 第３章 モジュール性 第５章 オブジェクト技術への道 第10章しなやかな設計 第14章 モデルの整合性 第15章 蒸留 第12章 大きなリファクタリング 第15章 部品から全体へ 第３章 業務ロジックの整理 第４章 ドメインモデル 第８章 アプリケーション間の連携 6
- 7. 私の越境：学習と成長の軌跡 – 原価計算シミュレータ（表計算ソフトのマクロ、製造業の管理部門） – グループウェア(自社プロダクト,Unix,C） – データベース中心の世界へ (Oracle, SQL, DOA) – インターネットバブル (Java as better C) – eコマース専業のソフトウエアハウスの雇われ社長 • 大炎上プロジェクトの火消し役 – 人に「善い設計」を伝えることの難しさ – リファクタリング、ドメイン駆動設計との出会い • 善い設計の模索 – 人材領域 （求人、転職、人材紹介などで、２０くらいの似て非なるサービス） – ISPサービス （レガシーとの戦い） – 成功したスタートアップ （大きな泥団子との戦い） – 30年物の販売管理システム再構築（歴史ある中堅商社の情シスとの遭遇） • 現在進行形 – 善い設計の探求、そのための分析スキル、そのための業務知識 – 善い設計の考え方・やり方の言語化と普及活動
- 8.
- 9.
- 10.
- 11.
- 12. 昨日と同じ、明日も同じ 昨日と変わった、明日はもっと変わる • 経験値がワンポイントあがった • 安定性が増した •方向が明確になった • 逆境への耐久力が増した • 思考停止の病が悪化した • 自分への嘘が増えた • 衰えた
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26. インクリメンタルな設計 • アップフロントの設計よりも、インクリメンタルな設計を – 最初から良い設計は見つからない –「これで完成」という設計はない • ざくっと設計してみる – 書いてみてフィードバック – 動かしてみてフィードバック – 改善ネタが見つかったら実験してみる • 繰り返す – 毎日が設計 自分がアップフロントの設計にとらわれていることを自覚する
- 27.
- 28. ビジネスルール • 業務アプリケーションの複雑さの根源 • 事業の運営が複雑なことの反映 •システムの構成要素として、ビジネスルールを独 立させると、新たなシステム開発の道筋が見え てくる – ビジネスルールのモジュール – ビジネスルールの分析・設計・実装の活動 – ビジネスルールのスコープ／品質／進捗の管理
- 29. ビジネスルール 従来の設計スタイル • 入出力中心の設計 – 画面定義 –データベース設計 – 機能設計＝入出力処理 • ビジネスルール記述の重複 – 入出設計と機能設計の中に埋 め込む – 重複記述 • 暗黙知 – if code == 13 then flag = 1 これからの設計スタイル • ビジネスルールに焦点 – ビジネスルールの発見と整理 – 入出力設計／機能設計から独 立させる • 記述の一元化 – ビジネスルールを表現する データとロジックをカプセル化 – モジュールとして独立させる • コードで表現 – if メーカー直送 then 送料請求 29
- 30.
- 31.
- 32.
- 33. モジュール性の向上 従来の設計スタイル • 分解のしやすさ • 機能単位のモジュール化 •データの正規化/一元化 • 概念と実装の分離 • 「既存」を変更しない 増築/外付けでがんばる くさいものにふたをする これからの設計スタイル • 組み立てやすさ • データとロジックのカプセル化 • ロジックの正規化／一元化 • 概念と実装の連続性 • 変更（組み立て直し）を続ける 変更の影響の局所化 日常的に変更する 33
- 34. モジュール性の向上＝分析設計スキル 第３章 モジュール性 第５章 オブジェクト技術への道 第10章しなやかな設計 第14章 モデルの整合性 第15章 蒸留 第12章 大きなリファクタリング 第15章 部品から全体へ 第３章 業務ロジックの整理 第４章 ドメインモデル 第８章 アプリケーション間の連携 34
- 35. 独自のデータ型の設計者になる ©有限会社システム設計 35 数値 日付判定結果 コレクション 汎用の型 int long BigDecimal LocalDate boolean 配列 List<T> Map<K,V> アプリケーション 固有の型を用意 して記述する 金額 数量 単価 年齢 日数 ポイント 期限 予定日 誕生日 確定日 顧客種別 割引可否 送料区分 年齢区分 価格表 カタログ 在庫表 履歴 スケジュール 売買契約
- 36. ビジネスルールを記述する型の設計 • 計算ルールを記述するための型 – 値オブジェクト：金額型、数量型、日付型、… •計算の元データと計算結果を表現する型 • 内部に計算ロジックを持つ • 判定ルールを記述するための型 – 区分オブジェクト • 分岐条件(input)としての区分 – 顧客区分、商品区分、地域区分、… • 判定結果(output)としての区分 – 出荷可否、配送方法、料金区分、… ©有限会社 システム設計 36 本日の演習の中心テーマ ・イベントの区分 ・状態の区分
- 37.
- 38. 型によるモジュール化 • 汎用のデータ型だけで記述するスタイル – データクラス（データ構造体） –機能クラス（トランザクションスクリプト）：処理単位にモジュール化 – ビジネスルールの暗黙的な記述 – ビジネスルールの記述の重複 • 固有の型を設計して記述するスタイル – ビジネスルールの結果（目的）を「型」で明示 • 計算結果 • 判定結果 – ビジネスルールで扱う値と計算ロジックを「型」で明示 • 金額型、数量型、日付型、… – データとロジックを「型」（クラス）という単位にモジュール化する – ひとつのビジネスルールの記述を特定の型に一元化できる ©有限会社 システム設計 38
- 39.
- 40.
- 41. ソースコード as ドキュメント •クラス名、メソッド名、パッケージ名という説明 • 式の型、メソッドの型、引数の型という説明 • アノテーションという説明 • 図や一覧がほしかったら自動生成する ソースコードをドキュメントとして活用する工夫を積み重ねる
- 42.
- 43.
- 44.
- 45.
- 46.
- 47. 鳥の眼、虫の眼 A Bird's- &Bug's-Eye View 俯瞰して全体を見ることと、詳細に部分を見ること。 この二つの視点を行き来する。 全体と部分は同時には見れない だったら行ったり来たりすればよい 俯瞰と詳細の行ったり来たりを習慣にする そうすると、 俯瞰から詳細が見え 詳細から俯瞰が見える ようになる
- 48.
- 49.
- 50.
- 51. エンジニアの学習と成長 51 Special thanks to 慶應義塾大学湘南藤沢キャンパス 井庭研究室 http://learningpatterns.sfc.keio.ac.jp/index.html