Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
システム内製の原則 @tunemage
Slide 2
Slide 2 text
自己紹介 • つねまげ(@tunemage) • 現職(1年半) • 製造業の社内SE的なポジション(研究開発も少し) • 社内基幹システムの開発・運用がメイン • 前職(6年) • ERPパッケージ開発 • それ以前 • Webやスマホアプリなど色々
Slide 3
Slide 3 text
•昨年、スクラッチ開発の社内基幹システムをロー ンチしました •本日は開発の中で意識した「原則」についてお話 します
Slide 4
Slide 4 text
開発の流れ • 4〜6月(アーキテクチャ選定・基本設計・参照実装) • 2人体制(もう1人のメンバーがフロントエンドに明るくて助かりました) • 画面設計・DB設計・ライブラリの検証・クラウド環境の選定・最初の2画 面実装 • 7〜9月(機能実装) • 1.2人体制 • 4画面 ・共通コンポーネント・CI • 10〜12月(追加開発) • 1人体制 • 追加2画面・細かな要望&不具合対応・ユニットテスト導入
Slide 5
Slide 5 text
構成 • 機能 • 画面✕8 • 帳票✕4 • CSV出力✕2 • システム構成 • サーバーサイド • Kotlin (一部Java) • Spring Boot • クライアントサイド • TypeScript(結構JavaScript) • NuxtJS • プラットフォーム • GAE(一部Heroku)
Slide 6
Slide 6 text
•比較的少ないリソースの中で、曲がりなりにもリ リースにまで辿り着けた •その中で大事にした原則は2つ
Slide 7
Slide 7 text
原則①YAGNI( You ain't gonna need it ) • 手を抜ける箇所は絶妙に手を抜く • 変更コストの高い部分に集中 • ただし、単なる付け焼き刃はNG
Slide 8
Slide 8 text
原則②機構と方針の分離 「計算機科学における設計原則の1つ。機構(操作の認可と資源配分 を制御するシステム実装部分)は、どの操作を認可するかやどの資 源を割り当てるかといった決定を行う際の方針を表すべきでない (あるいは過度に制限すべきでない)という考え方である。 (Wikipedia)」 • よく分からんので具体例を(次ページ)
Slide 9
Slide 9 text
実際の例)簡易帳票エンジンの実装 見積データ 帳票エンジン Excel テンプレート 方針 機構 出力帳票
Slide 10
Slide 10 text
原則②機構と方針の分離 • 機構(エンジン)側は方針(条件分岐・レイアウト等)を意識し なくて良い • ハードコーディングによるif文地獄に陥らない • メンテナンス性向上 • 帳票エンジンの他にも、部署ごとに異なる作業工程の定義や権限 まわりでも応用しています
Slide 11
Slide 11 text
原則②機構と方針の分離(その他の例) 機構 方針 カードキー カードリーダー・通信プロトコル セキュリティサーバの権限データ Maven・npm等 実行エンジン pom.xml、package.json 会計システム 仕訳エンジン 勘定科目マスタ 承認申請機能 画面コンポーネント 権限マスタのデータ ワークフロー ワークフローエンジン ワークフローの定義
Slide 12
Slide 12 text
まとめ • YAGNIと称した付け焼き刃はNG • 可変ポイントを見極めて適切な役割分担を促す設計が重要 • 業務ドメインと技術ドメインの全体感を見る • まだまだ未対応の問題は山ほどあるので楽しみです
Slide 13
Slide 13 text
参考文献 • マルチパラダイムデザイン(ジェームズ・O. コプリン) • 機構と方針の分離(Wikipedia) https://ja.wikipedia.org/wiki/%E6%A9%9F%E6%A7%8B%E3%8 1%A8%E6%96%B9%E9%87%9D%E3%81%AE%E5%88%86%E9 %9B%A2