↑会社的にブログ頑張っていくぞ～～みたいなムーブメントあったので、便乗して記事書いた。この場末のブログに書くなんかよりは、PVもそこそこあった感じ。
それはそうとして、この技術の文脈をどう捉えていくかみたいなのは我々新参者には結構深刻な問題だと思う。
例えば今自分が所属してるプロジェクトで、キャッチアップが難しかったなぁと思える技術を上げていくと…
- Clean Architecture
- Zenject
- UniTask
- UniRx
- gRPC
で、これらの技術をどうやって理解していったかって、やっぱり表面じゃなくて、そもそもこの技術は何を解決したいんだっけ？ってのを歴史から紐解くのが一番分かりやすかったんですよね。
Clean Architectureなんてその最たる例で、あの同心円状の図から入るとかは最悪ですよね。レシピを覚えることにあまり意味はなくて、レシピに至るまでの道を理解することが大事で、そこから発展させる必要があるのだけど、レシピで止まってしまうエンジニアも少なくない…。かくいう私もそのレシピに弄ばれた一人ですが。
別にこれは、採用してる技術だけではなくて、今私達が書いてるソフトウェアにも当てはまる話で、何でうちのソフトウェアこんなアーキテクチャしてるんだっけ…？って気づいたら誰も知らないなんて良くある。そこでチームの最古参のメンバーが「昔々かれこれこういう理由で…」と紐解くと、なるほどなーとなったりする。他にもgit blameから古代のPRを引っ張って読み解いたり(これを考古学と呼んでる)
そういう語り継ぐ人が残ってるのは幸運な例なのかなとは思ってて、現実としてコンテキストが喪失してるなんてことも良くある。つらい。いつ消えても大丈夫なように、ドキュメントは書こう。
なので、ソフトウェアの昔ばなしというものがとても面白いなあと思うようになってきた。もっとソフトウェアの歴史知りたい。