バグの入り込む隙間
大きな目的を遂行する際は、小さいパーツやフローを組み合わせて行う
プログラムは小さい関数の組み合わせだし、業務フローも小さいフローの組み合わせ
この、各パーツ同士を組み合わせる隙間にバグやエラーが入りがち
例え、個々のパーツ単体では完璧でも、それらを組み合わせる際にバグが入る
この感覚の解像度をもうちょい上げたいmrsekut.icon
そもそも隙間の数が多い
パーツ同士の組み合わせの数が多い
これ自体は問題ではない気がするmrsekut.icon
隙間を埋める際の、人間の判断が多い
関数型プログラミングは、この隙間が比較的小さく書ける感じがある
合致する組み合わせをすれば、基本合っている、みたいなイメージ
型のおかげなんだろうか
それもあるけどそれだけじゃないと思う
宣言的な書き方もそういうイメージ
インフラを、手動でGUIで設定するよりも、宣言的に設定を書いたほうが隙間が減る
手続き的に書くと隙間が増える印象
順序とか状態とかに依存する
目的以外も書かないといけないなら、それは注視すべきものが増えるということなので
Dockerでnetworkをごにょごにょするのはバグの入り込む隙間が多すぎる
Containerの起動ができているか、
Containerが起動できていたとして設定や読み込みが完了しているか
例えば、mysqlのでかいdump fileを読み込まして起動すると
起動は完了しているように見えるが、dumpをすべて読み込むまで数分かかる
この数分を待たずしてSQLを実行するとエラーになる
この時、そもそも設定がおかしいのか、待てばokなのかがハッキリしない
Container間の通信がうまくいっているか
etc.
棚卸を手書きでやるとか
在庫を数えて紙に記入し、それを別の人がシステムに入力する、という作業は隙間が多い
商品の数え間違い
数の紙への記入間違い
紙の紛失
記入済みの紙の読み間違い、誤読、字が汚くて読めない
読んだ数字のシステムへの入力ミス
flakyさがない、とか
動くなら動く、動かんなら動かん