「読みやすいコード」を依存グラフで考える

DBの中の振る舞いに踏み込まないコードで書かれたアプリは、バグり難くても使う側に有難みが薄いものになりがちなので、読みやすさを追求するあまり及び腰にならないようにしたいもの。ただ不要な複雑性はいらない。

クソ面白い。KISSだのDRYだのいう説明はこうやるべきだった。抽象度レベルを一定にして読めないコードは、頭の中で強烈なバックトラックを発生させている。

関数に簡潔にして完全な仕様の記述をつけること。そのような記述を書きにくいときはその関数は分かりにくく設計が問題含みである可能性が高い

「この順番で理解していく必要がある」という関係性を有向グラフで考えると強連結成分はまとめて理解する必要があって成分が大きいと大変。あと弱連結の部分はトポロジカルソート順に書いてあると読みやすいよね。

OSSで依存グラフの表示するツールってどこらになるのかな。

面白い。ただ「mutableの問題点は依存がループするから」の説明はmutable限定では無いので何かおかしい。mutableな変数は静的なソースコードの依存グラフで表せない「過去の状態への依存」が存在するから難しいと思う。

DBはプロセス、コードの寿命を超える特大変数、これすき..

これいいなぁ。コードレビューの時に常にこの図が欲しい。

“が身につき、その理由を自信を持って説明できるようになるはずです。 ”

“巨大なスコープを持つ mutable な変数は、依存グラフ上で広範囲を巻き込んだループを作り出します”"宣言的なコードは関連箇所が局所的かつ明示的になるので、読みやすくなる"

参照透過を確保して状態をコード(宣言)から定めるから宣言型なんだけど、みんな"宣言ぽい"で宣言型を書いてる

面白い発想

視覚化大事だなー。

“読みやすいコードは、整然とした　○->○　構造を持つ。この依存グラフでプログラミングを視覚的に理解。疎結合なクラスタは矢印を減。高凝集なクラスタは内部理解が易。 宣言的コードは値を返さないつまり単方向”