プログラムのコード行数の肌感

2017/10に自分が触っていた某リポジトリは7000行だった

要求が増えて、気づいたら15000行になっていた

実装力とか事情も色々あるが、

基本的には、10000行くらいを把握できると考えていいのでは

ライブラリとして切り出して抽象化していけば、行数は減る

ライブラリは、必ずしも実際のライブラリとしてではなく

リポジトリの中にはあるものの、ライブラリとして綺麗に切り出されている

という状況もあると思うので

そういう凝縮がうまくできて入れば、さらに把握できる行数は増える

書くのが下手くそでコピペみたいな助長さがあれば、頭は使わなくても行数は増える

行数が多い少ないは、直ちに良い悪いの判断はできないが

「この行数の多さはどこに起因するのか」を意識するとなんか良さげ

2024/1/27

直近のプロジェクト、大体7万行だった

チームで書いたので全部を把握してるわけではないが、半分以上は把握してたはず

なので、現時点では3~4万行くらい、と捉えておく

たぶんこの把握力は線形には増えない。対数的だと思う

だから、今後ひたすらプログラムを読み書きしても、10万くらいで頭打ちになると思っていたほうが良いだろう

オーダとしては数万、として良い。

観測数が少ないが、このような感覚で持っておく

初心者は数千L

センスがいいと最初から5000以上とか1マンに近づく？

逆に、仕事としてやっても2,3000Lを全然把握できないようなら、適性が無いから無理にやらないほうがいい、とか？

中級者以上は数万L

上級とかは、そもそも行数の話ではなくなる

なぜ対数的なのか？それは行が増えたら考えることは、行ではなく、行と行の関係に比例するからだろう

だから、適切なモジュールに分けられれば、耐えられる行数が増えるかもしれない

また、ライブラリは計測対象に含めていない

これは、ライブラリはそのインターフェース経由でアクセスして、関係性をとどめ、挙動のために必要な行を圧縮しているから、といえる

それよりも、他のアプローチを考えた方がいい

いかにして短く書くのか

いかにしてうまくチームで分担するか

要するに設計力

なんでこれを計測するのかというと、

自分が読み込める行数を把握しておけば、プロジェクト参画時のキャッチアップのアプローチが想定しやすいから

数千行の場合

さっさと全部読めば良い

数万行の場合

時間がかかるが読み込める

すぐには頭に入らないから、１ヶ月以上のなじませ期間を想定する

だから、

最初のプルリク、貢献はスコープが

小さく取り組みやすいものでなければならない

かつ、その過程でコードの読解を進める

数十万行の場合

経験したこと無いが

まず、全部の把握は無理なので、そもそもモジュール分割がうまくいっているかどうかを見る

うまくいってるなら

その範囲でどう頑張るか、という感じに

うまくいってないなら、

関係者に聞きまくるということが必要かつ大事になる

また、そこの範囲をきれいにするところも視野に入れる

個別の取り組み方自体は、いつでもそうすべきといえばそうなのだが、どのくらいの覚悟で挑むかの具合が変わる

クソデカリポジトリの全体をなんとかしようとするのは無理