2024/8/30

/icons/hr.icon

大規模開発においていかに認知負荷を下げるか

最近の関心事。

とにかく考えることを減らしたい。ベロシティ高い開発チームとソフトウェアを作りたい。

私、思うんですけど、大規模開発ってそもそも人類にとって難しいと思うんですね。静的な型チェックも、大規模なものに対して、「なんとか対応するにはどうしたらいいか？」みたいなアイデアのうちの1つだと思うんですけれども、そもそも避けることができるなら避けたいなというのが正直なところなんですね。

何かというと、ソフトウェアの規模がデカくなると、ある程度必然的にチームの規模もデカくなる傾向があって、チームの規模がデカくなると開発速度が下がるんですよね。ベロシティって呼んでいますけれど。

そうすると良くないんですよ。関わっている人がたくさんいると調整しなくちゃいけないことや、コミュニケーションのコストがどんどんかかっていく。そうすると、ソフトウェアを作っているんだか調整しているんだか会議しているんだか、だんだんよくわからなくなってくるわけですね。それは駄目かなと思うわけです。

作りたいものに対していかに早く完成させるかというところがソフトウェア開発においては正義で、それを達成するためのツールであれば、たとえRubyを使ってもTypeScriptを使ってもHaskellを使ってもRustを使ってもいい。どんな言語を使うかよりも、ベロシティを達成することそのもののほうが重要だと私は思うんですね。

それを達成することを最初の目標にしなくちゃいけないと私は考えますので、チームサイズが大きくなればなるほど調整が大変になりますし、コミュニケーションに関わる人が増えれば増えるほど、文書化の量や、あるいはルールで縛らなくちゃいけないものが増える。複雑になるんですね。

なので、一遍に考えるべきことを減らし、ソフトウェア開発のために構成要素みたいなものを減らして、ベロシティを上げるのが大事じゃないかなと思うんですね。

GH Actionsのキャッシュについて

こちらはAndroid版だけど参考になるので読んでおく。

ざっくり理解したら公式docsも読む。

同作者がiOS版も書いてた。

GH Actionsで同一Workflowのcancelをするには

code:setting.yml

concurrency:

group: ${{ github.workflow }}-${{ github.head_ref || github.ref }}

cancel-in-progress: true

複数appが同一URL Schemeを使った場合

If multiple apps register the same scheme, the app the system targets is undefined. There’s no mechanism to change the app or to change the order apps appear in a Share sheet.

呼び出し先アプリの定義が未定義になり、呼び出されるアプリはランダムで決定する。

Zedが気になる