2+2 = 1+3
#
理論、思考、実装、モチベーション、リソース, 全部で勝負.
期間
mealiy, daily, weekly, monthly, yearly
すべての人に好かれることはできない
- 勘違いによる嫌われ
- 説明を聞いてもらう必要
- 嫌いになったら聞こえなくなるタイプ
- 考える気がない/られないタイプ
- ワラ人形タイプ
- 嫌われは別件批判の道具で真理に興味がない
- 勘違いが解消しても好きにはなってくれない
- 説明を聞いてもらう必要
ソフトウェア開発の立ち位置
原初的: 設定された問題をソフトウェアで解決する
「問題を解く」
現代的: 取り組むべき課題に対し、ソフトウェア開発を介して課題の明確化や問題解決を図りながらより良い回答を求めていく
「状況を改善していく」
プログラミングは曖昧さを扱うことが不得意
=> 自然と課題が明確になっていく
問題解決はより多くの問題を明らかにする
=> 素早いプログラミングが状況改善そのものを高速化する
状況に立ち向かう武器が「プログラミング」な人: ソフトウェアエンジニア
分離と汎化
entangled -> separated -> generalized
ごちゃごちゃのコードはそのまま汎化できない.
コードを整理して機能別にまとまりを作って、共通部分を汎化用インターフェースとして切り出す.
抽象化 -> 最上層: 複雑性↓、下層: 複雑性↑
汎化用インターフェース自体が複雑性を導入する。
それに勝る、上層部での複雑性低減が目的.
その前段階となる「まとまりの分離」というか「フローの整理」的なやつは複雑性を導入しない.
コード量も階層も増えず、ただ絡まった糸を解くだけ.
最初から絡まっていないコードを書くのがプログラマの腕.
"抽象化は道具であって目的ではない"
教条的なインターフェースはYAGNI
分離さえしておけば、インターフェースの導入は簡単に終わる（必要に合わせていつでも簡単に導入できる）
TypeScriptでデータフロー中心のプログラミングを実践する
論理
- 見通しの良さ（怠惰プログラミング）
- 状態分離 + 宣言型プログラミング
- データフロー定義 + ランタイム
- TSでの実装
データフロー定義
単純な関数連鎖
ランタイム候補
- ただの関数連鎖
- 独自のObserverパターン
- Redux
- FRP
- RxJS
- Bacon.js
定期data fetchから連鎖的に更新するタイプなら、関数連鎖だけで組むことが可能 （状態を持たなくても組めるので）.
stateを持つ必要があるなら、独自のObserverが一番小さいパターン
FRPはstateに対する型を用意して時系列操作とするので、結構抽象度が高い.
慣れればとても使いやすいけど、ここまで必要ない場合が多いという感触.
"速度最適化とatomic"とか考えだすと結構むずかしさがある.
tree型なら簡単だけど、DAGはやはり大変.
UIランタイム
宣言型UIライブラリ/フレームワークが処理系として動いてくれる.
Reactの場合はReactDOM.render()を毎回呼ぶことがランタイムcallに相当するのでとても楽 (Reactに閉じたアプリはあまり健全だと思えない).
楽なプログラミングに求められるもの -見通しの良さ、コード量、etc-
怠惰たれ。
怠惰たるために、楽にプログラムを書きたい。
そのために何が必要か。
背景 -書き方の工夫はできることを増やしはしない-
ある言語を使う限り、べたべたの命令型パラダイムで書いたコードとOOPやFPで書いたコードで、実行可能な内容は等しい。
あくまで、楽にコードを書けるかという違いしかない。
じゃあどういう「楽じゃなさ」を各技法がもたらしてくれるのかというのが本質
見通しの良さ
我々はコードを見た時、コードの計算結果を予測しながら読んでいる。
予測ができない場合に「これが何のコードか」を知るには、適当な入力を入れて出力の特性から振る舞いを予測するしかないが、普通はそんなことしない。明らかに我々はコーディング時に計算結果の予測をおこなっている。
この予測が難しいとき、プログラミングは格段に難しくなる。
予測に時間がかかればコードを読み書きする時間が増え、大変になる。
予測に頭を使うほどコーディング時の消耗は大きくなる。
プログラミングにおける「楽じゃなさ」の1つは「計算の予測=見通しの良し悪し」である。
“可読性”と同じ意図だが、”可読性”はあいまい
コード量
1行1行が極めて明快に書かれ、意図が明瞭で計算の予測が容易だとする。
そんな優れた1行が100,000行あった場合、それを1人でプログラムするのは非常に困難になる。
コード量はそれだけで「楽じゃなさ」になる。
(高水準言語のいいところの1つ)
ドメインモデル -Godモデルは人間にとって早すぎる-
Godモデル: 対象の全ての情報を正確に含んだモデル
このモデルさえ上手く扱えれば全ての用途において全員が単一モデルが利用できるため神。
→
残念ながら、良く設計された数千の属性をもつモデルは人の手に余る…扱えない…
「Godモデルの○○属性の処理についてなんだけど」「○○属性…ああ、うん？△△属性と同じ感じで扱われている…すまない、ちょっと待ってね（わかっていない）」
コンテキストに分割してコンテキスト内でのミニモデルを作る。
コンテキストを切り替えながら話を進める
コンテキストごとに対象の表現（モデル）は違うけど、実体は同じわけで、コンテキスト間でモデルがどういう関係を持つか（マッピング）
