WEB+DBvol74
種別：紙
プロジェクト：仕事
開始１：2018/03/04
終了１：2018/03/04
開始２：yyyy/mm/dd
終了２：yyyy/mm/dd
メモ
設計と学び
- 事前の設計に時間をかけてもコードを書く中で考え直しは避けられない
- しかし悲観的に捉えないこと。
- 神ではないのだから最初から完璧な設計はできないと割り切りましょう。
上記、すごいありがたい言葉。。 まぁ、だからといって考えきったといえるところまでやることは必要だけど
保守できないコードに意味はない
保守できるコードとは
- 人が読んで理解できる
- 一部の変更が全体を壊さない
保守性の阻害要因
- 依存関係が複雑なこと
- コード中の概念や名前が通じないこと
参照依存性
コードの分割を行う- 依存性の判断は量ではなく、質で行うこと
- 依存する方向を一方向にする
- 安定する方へ依存する
- 依存する数を減らす
実行順依存性
- 不変性
- 参照透明性
コード重複依存性
コード分割
命名大事
という話が合った。本当そう
抽象化と設計
- コード量が減る(共通処理を統合できるから)
- 安定した部分(変更されにくい部分)を分離できる
- 命名によりメタファを使える
「要するに」メソッド
このクラスは、このメソッドは「様子するに」何をしてしようとしているのか、という視点、自分への問いかけ。
責任を持つ原則とかあったな。更に単一責任の責任の法則とかUNIXの思想とか
設計でも同じかも知れない。
- 要するにこの文書のこの部分は何を説明しているのか
- 要するにこのファイルは何を説明しているのか
- 進んでどういう実装を想定しているのか
設計の分類
私も知ってる。設計を
- 分割統治
- 名前付統治
で分類する。抽象化するという卓見
過剰な抽象化
ex)言語構文で用意されている機能レベルを抽象化してコードを肥大化させる
ただし、このへん、DDDではむしろやれって感じ。あれも抽象化の話で結果が違うだけだ。 うむ。学び。
ex)電話番号を文字列で持つな、クラスにしろ → これは適切な抽象化
コード量が多くなるというだけで過剰な抽象化と断じることはできない
クラス設計
いろんな名著をかいつまんでくれているので、すごいこの特集ありがたい。
アジャイルソフトウェア開発の奥義 :変更理由
この本も読まなければならないな。。
- クラスの一部を変更した時、同時に変更が発生するのは同じクラスにあるのが良い
- 同時に変更が発生しないコードは別のクラスに合ってよい
この方法だけを突き詰めるとクラスひとつになるやんか問題、次節
実践的な方法論
- 名前で分ける
- 拡張ポイントを作る
- 中間層を作る
- 使う側の視点で考える
王道を進め
概念、役割、言葉の王道は小手先のデザインパターンよりも優先される
クラスの分割基準
1
- 大きいクラスは分割する
- 変更が必要なクラスは分割する
2
- 下請け処理を分ける(ユーティリティ、ヘルパー)
(me:どこかで否定されていなかったけ？) - 複雑な部分を分ける
- システム境界を分ける
- ユーザーインタフェース
- データベースアクセス
- ネットワーク処理
- ファイル処理
最終目標=拡張言語層の確立
夢。ユーザーが好きに定義できるUIがあるなにか。
集計とかこれに当たるのか
(kintoneとかこれTに当たるのかな？使ったことないからわからない。IFTTとかも？)
この筆者はドメイン駆動に懐疑的
原理主義的にドメイン駆動したらだめだろうけど、「現場で〜」方式なら有用だと思う。 また、あの本の言いたいことと結局おなじになるのではないか？
アウトプット
この文章、仕事。。。 何度もよみなおしたい。
NEXT
現場で役立つシステム設計の原則
LOG
- 2018/03/04 15:02 commit
- 2018/03/04 15:32 commit