diary日記2017-11-03チームとフレームワークについてフレームワークとは設計思想の観点を大事にして考えると、フレームワークとは設計思想の柔軟性を犠牲に、チーム内の設計思想を調整・統一するコストを下げる働きを持つ仕組みである。便利機能を抽象化して車輪としたライブラリと異なる点は思想の強制性である。設計思想がないとき共通認識となる思想がないシステムをチームで作るときは、何を実装するにしても設計・実装の方針が合わないことがある。Reduxを使って状態をどこで管理するかというありふれたテーマですら、実装する内容によって状態の持ち方で議論になる。*1たしかに議論を繰り返してチーム内での認識を徐々に揃えていけば最小のコミュニケーションコストで「いい感じ」に開発していくことは可能なのだけども、この時にできあがっているのは属人化された暗黙知でできたチームである。チームとしてのスケーラビリティなんてものはない。DDDを読む私は読んだのだけども、一人で読んだら意味がなかった。業務で時間を取ってチーム全員が咀嚼できるまで読書会をして初めて意味がある。読書会ですら書いてある内容の解釈を巡って暗黙知を育てていく過程があることは自明で、これは別の意味で「フレームワーク」を導入したことになる。チーム全体で実装されるコードとしては何らかの合意された思想に基づいた、コードとしてのフレームワークには依存しない「よい設計」の成果が出てくるのだが、これもまたスケーラビリティには難がある。言語化でも銀の弾丸にならないチーム内の思想を言語化してドキュメントに落とし込めばよい。よいのはよいが、読書会で解釈の補強をする議論が必要なことと同じように言語化されたもので暗黙知を網羅することは難しい。*2当然無いよりは相当マシではあり何もないよりはスケールするはずだが、人の流動に弱い点には代わりがない。フレームワークと生産性のトレードオフフレームワークは何故必要なのかに立ち戻ると、「コミュニケーションコストを下げるために少ない人数(一人)で作ったほうがよいのでは」という仮説が出てくる。常人の100倍の生産性を持った設計・実装スキル抜群の超人が居たとしても、思想の統一された集団には長期的に勝ち目がない。ここで言う「統一された思想」とはコードとしてのフレームワークでもよいし、何らかの読書会で議論を重ねた結果でもよい。よって、営利活動として収益を求めて競争をする限りにおいて組織はあったほうが強いし、組織内ではフレームワークが効率化に寄与するのである。*3安いフレームワークそして、「コードとしてのフレームワーク」と「チームで議論した結果のフレームワーク」のどちらを重視するかという問題が残るが、これは各組織の現実に合わせて解く問題である。*4作るシステムの規模が大きく関わる人が多いのならば後者の議論を行うコストが相当高くなるし、関わる人間が少なくてすむ要件のシステムを作るのなら他人の作ったフレームワークの制約は不便なものになる。*5最も基礎的なフレームワーク勉強・教養と呼ばれるものになる。「計算量の計算ができるかどうか」「計算機で命令が実行される仕組みを知っているか」など。ここまで書いて気づいたが、思想と知識を峻別する意味はないような気がする。思想が古くなり広範な合意が得られれば知識である。した古典と呼ばれる知見は、より望ましい「チームで議論した結果のフレームワーク」を下支えする基盤であり、つまり古典の勉強は重要というありふれた結論が得られる。古典を無理やり教えてくれるのが大学であり、ちゃんと学んだ結果の学位は強いのである......。*1:GUIアプリケーションの設計方針にはReduxの制約でもまだ足りない。実際世界には様々なスタイルのReduxで書かれたアプリケーションがある。*2:ドキュメントすぐ陳腐化する問題*3:OSSとかlinuxはメーリスやissueで散々議論積み重ねてますね。それに設計にケチをつける独裁者もよくいる。20...2018-06-21ある日、「最新技術を使いたいが、ベストプラクティス(定番の手法)がなくて困る」的なことを耳にした。昨日ののあとに考えていた雑感。Mode雑感イラスト、プログラミング、文章などは意図...redux-sagaのall([fork])パターンは、即座にfinallyに突入してしまうであること、できること、すること月別アーカイブはてなブログをはじめよう!non_117さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。