「Terraform Module Designs 思考の引き出しを増やすモジュール設計のヒント」がめちゃ良い
「Terraform Module Designs 思考の引き出しを増やすモジュール設計のヒント」という Speaker Deck のスライドを見ていた。
Terraform という IaC ツールに関するスライドなのだが、この中で出てくる数々の言葉は、システム設計、プログラマの美徳、組織作りやプロジェクトマネジメント、仕事術などに通じる内容が豊富に含まれていたので、自分が特に感銘を受けたモノを以下に引用させていただく。
- 限りなくシンプルなデザインというのはなかなか教えられるものではなく、大方経験を重ねて覚えるものだ - Evan Priestley
- この「判断力」は、プログラマーにとって非常に重要なのだが、そう簡単に教えられるものではない。ぼくが知る限り、判断力をつける一番の方法は、自分で設計したシステムを長い間メンテすることだと思う
- どれだけ頑張って設計しても何回かしくじる。一定期間、自分で運用しないと上手にならない
- 何かをしないのも立派な設計判断
- 実際に偉大なプロダクトが完成するまでには、とてつもない量の妥協 (トレードオフ) が必要なんだ - Steve Jobs
- アーキテクチャのあらゆる問いに共通する答えは「場合による」のだ。答えはデプロイ環境やビジネスドライバー、企業文化、予算、期間、開発者のスキルセット、その他多くの要因に依存する。環境や状況、問題点はそれぞれ異なるものだ - ソフトウェアアーキテクチャの基礎
- 良い戦略はさまざまな要素の相互作用を考慮し、全体をコーディネートするという意味で、選択や意思決定より設計に近いと考えられる。システム設計の大半は、サブシステムの相互作用、別の言い方をすればトレードオフを見極めることにある - 良い戦略、悪い戦略
- ソフトウェアはエントロピーのようである。掴むことが難しく、重さはなく熱力学の第二法則に従って常に増大している - Norman Augustine
- 標準プラクティス : 認知負荷を下げるため、特にこだわりがなければ準拠しておく
- 公式ドキュメントは「思考の出発点」。とりあえず取り入れてみてイマイチに感じたポイントはあとから変えよう
- 公式ドキュメントで知見の共有を促進しよう。外部の形式知はコミュニケーションを楽にする
- 公式ドキュメントを土台にしておけば仮に「異なる設計判断」をしても楽ができる。この場合は差分だけ言語化し、暗黙知を減らそう
- 成果をあげる人とあげない人の差は才能ではない。いくつかの習慣的な姿勢と、基礎的な方法を身につけているかどうかの問題である - Peter Drucker
- 個々のプログラムは1つのことをしっかりやるようにせよ - Doug Mcllroy
- API で公開しているすべてのものが誤用される可能性 : API の設計を経験した時間が長いほど、公開するものが少なくなっていく - API デザインの極意
- プロダクトの Core となるビジョンがないままに、ただユーザの声を聞き続けるプロダクトは発散する - プロダクトマネジメントのすべて
- あらゆるエッジケースをサポートしたくなる。しかしこれは典型的な思考の放棄であり単なるトレードオフからの逃避である
- 品質特性は考慮漏れしやすい : セキュリティや信頼性、スケーラビリティなどは忘れてもとりあえず動く
- しくじった時の影響が大きい、改善には根本的な見直しを要する
- モジュールでは「品質特性をカプセル化」しよう
- 全体最適が促進されるため組織全体の当たり前レベルが向上する
- 入力パラメータは少ないほどよい : 入力パラメータの数が増えると利用者の認知負荷が上がる
- オプションなら OK という設計思想は、思わぬ副作用を生む可能性 : トレードオフの判断をサボった、パラメータの増殖を招く恐れ。設計者の思考停止を誘発しやすい
- 抽象化は失敗する。抽象化がそれを意図されているほどには私たちの生活を楽にはしてくれない - Joel on Software
- ひとたび問題が発生すると抽象化は引っ剥がす必要がある
- 抽象化は我々が作業する時間を節約してくれるが我々が学ぶ時間までは節約してくれない
- 英知は受け売りで身につくものではない、自分自身で発見するものなのだ - Marcel Proust
コレまで自分が色々と考えてきたことに通じる話が、分かりやすく一言でまとまっていて、自分の語彙力のなさを痛感する。
- 過去記事 : 事前のアドバイスは届かない・経験しないと分からない
- 過去記事 : 内発的な動機がない限り、人が変わることはない
- 「どれだけ頑張って設計しても必ずしくじる」「判断力は大方経験を重ねて覚えるもの」「英知は受け売りで身につくものではない、自分自身で発見するものなのだ」。まさにそういうこと
- 「後進には自分のような失敗はスキップして先に進んでもらいたい」という親切心が湧く一方、「その人にはその人で『自由に失敗する権利』がある」とも思えるようになってきた。急ぎ仕事を進めないといけない時とかはせっかちな自分はトロい周りを見てイライラしがちだけどｗ
- 過去記事 : 巨人の肩の上に立つ
- 「公式ドキュメントは思考の出発点」。公式や権威に従うというのは、独自にドキュメンテーションする範囲も減らせるし省力化に繋がるし、「認知負荷」も減らせると思うんだけどね
- 過去記事 : CoC が苦手な奴、認知資源が乏しいだけ説
- コードを読む、システムや組織を理解する時の「認知負荷」に通じる話。作ったり書いたりしている本人は、自分の「認知資源」の中からモノを作るので、他人が感じる「認知負荷」を小さく見積もりがち
- 過去記事 : 新しい技術は楽にならないし基礎知識の範囲は広がる一方
- 過去記事 : 発展途上のデファクト・スタンダードが辛い
- Joel on Software は過去に読んで大好きな本。「抽象化は我々が作業する時間を節約してくれるが、我々が学ぶ時間までは節約してくれない」っていうのはまさにそのとおりで、仮想化だとか抽象化による作業効率化を狙ったツールというのは、既に知識を持ってる人が作業する時に、「旧来の原始的なやり方」と比較して作業時間を短縮できる、ということを狙っているワケであって、別に学習コストが少なく済むワケではない、ということだ
組織で何かやる以上、ある程度は思想や言動に統制を図って、組織が目指す方向に合わせられないと厳しいところもあるんだけど、結局人間って人それぞれ考え方も経験量も違うモノなので、そうそう上手くはいかないし、全てを厳しく型にハメても期待するほどの効果はないのかもな。
コーディングは型付け大事だけど、組織構成や学習過程においては as any や Union 型や // eslint-disable-next-line も適材適所で使った方が良いってこったな。…違う？ｗ
