最近、エリック・エヴァンスのドメイン駆動設計て本を読んでるんですが、なんかグッと来たので覚えてるうちに書いておこ。まだ読み途中なんだけども・・・。難しい。。。
・ウォーターフォールは一方向
各工程を担当の人間がやるけど開発モデル上、後工程から前工程へフィードバックが無いよね。 「ソフトウェアを書き始める時、我々は対象を十分に理解しているわけではない」。メンバ間でフィードバックループ?して、継続的学習を実践しましょと。ウォーターフォールって各工程での分業を前提としてると思うんです。今までの経験上それは割とダメで、設計した人が実装した方がいいし、実装した人がテストした方がいい。ただ、一人で全部やるのはダメだと思う。その辺のさじ加減。。。
・ドキュメントはコード上の表現を補うもの
すでにコードが上手くやっていることを、ドキュメントでもやろうとするべきではない。コードはふるまいに関する正確な仕様書。ただし、設計ドキュメントとしてのコードにも限界はある。それは理解しやすいということではない。ドキュメントはチームの活動の役に立たなければならず、最新の状態を保たなければならない。コードの補足に絞る。
全てにおいて、コードを読めって事は自分はダメだと思ってるけど、会社で作ってる仕様書も意味ないと思ってる。無駄。確かにコードを補足するものとしてドキュメントを捉えれば、有意義なものが出来そうな気がする。ちょっとやってみよう。まぁでも、納品とかある場合は無駄なモン作んないとダメなんですけどね。それも給料のウチってやつか。契約時にどうにか出来ないもんか。その時に口出しできればいいんだけども。。。
・プログラマは設計
この発想は目から鱗的だった。確かにそう考えるべきですね。上手く説明できないんだけども。
「コードを生成する人々がモデルに責任を感じていない場合やアプリケーションのためにモデルを機能させる方法を理解していない場合、そのモデルはソフトウェアと無関係になってしまう」。なんかコレ、身に染みてわかる。
・利口なUI
最初これ、何言ってんのか分かんなかったけど、いわゆる、MVCでViewにロジック書くんじゃねー的な事ね。確かに利口なUIです。ただ、これが必ず悪ってわけじゃなくて、利点と欠点を理解してその場に応じてアプローチする。コレはダメみたいな思考停止すんなと。