不幸なブログ記事を読みました。

自社開発メガベンチャーをわずか半年で鬱退職した雑魚エンジニアの話｜JoanOfArc (note.com)

◆余談：設計下手、静的型付け言語にキレがち。

まず余談。読み飛ばしてよい。

ふだんお仕事でC#とかTypeScriptみてぇな静的に型が判る言語（≒静的型付け言語）を使ってるんですけど、別チームの同僚から「これこれこうで型がキツいしワケわからん」みたいな相談事を受けることがある。

どれどれと思って左手でチンポをシゴきながらコードを眺めてると、書いている関数の役割が明確じゃなかったり、扱おうとしてるデータの構造や変換がイカれてたりしている。自分で作った迷路に迷い込んで独りでキレている自縄自縛状態。

C#で言えばclassの切り方がド下手くそだったり切りわけがおかしいから名づけも狂っちゃってる。必須レベルの抽象化がされず何もかもが具体的。書いちゃダメな脆弱コードとか見慣れたアンチパターンを素朴に書いている。冗長すぎるコピーでメモリ領域を無駄に食ってるし処理の負荷も高い。

TypeScriptでいえば、処理の流れとか階層みたいな概念をガン無視した雪中行軍的コードを書いている場合が多い。C#からTypeScriptに入った人はclassの存在に騙されるし、JavaScriptからTypeScriptに入った人はこの令和の時代にコールバック地獄を生み出していたり。そもそも基礎となるJavaScriptがどういう流れで動いているのかってのを理解できてなかったりもする。JavaScriptは特殊な動き方してるから誤解も仕方がないところあるけど。

▼自動で動くはずのものが上手く動かないこと

とっちらかっている部屋があったとして、ルンバはそこで活躍できないわ。ルンバを手で持ってゴミを吸い取るようなことをしながら「ルンバって重くて不便」みたいに言っても仕方がない。部屋を整理整頓してルンバが通れるようにするか、ルンバを使わずに自分で散らかった部屋のゴミ拾いするかです。物事を便利に自動化したいなら、対象を綺麗に整理整頓せねばならない。

あるいは、人間に仕事を押し付けて自分は楽をしたいって言うのであれば、自分のしてきた仕事のアウトプットは理路整然と、見通せるようになっていなければならない。

思ったことをそのままコードに起こすようなスクリプター仕事なら、そりゃPythonでもJavaScriptでも使えばいい。誰だってそーする。おれもそーする。根本的にソフトウェアアーキテクト能力が低すぎて説明が面倒だったら、もう「無理にTypeScriptとか使う必要ないっすよ」とか言ってあげればいい。とはいえ、そうやって書かれたコードに俺は触れたくないね。型は定義であって、定義はドキュメントに起こせるのだから。翻って、型がなければ定義がないに等しい。定義がなければ属人性の霧の中を往くことになる。

だから、ルンバでも通れる道を整備するべきだし、静的型で変な困りかたをしない設計を整備してやらねばならんのです。テストコードを無理なく書けるコードを設計していますか。自動で動くテストコードを書くのが苦しいと宣うんなら、ほぼあなたの設計が間違ってます。機械的に走査できる成果物にしてくださぁい。

▼炭鉱のカナリア

関数を作った時に良い名前が付かないことがあるかと思う。そういう時はその関数の責務が、インターフェースがおかしい。扱おうとしているデータの形状がおかしいし、ひいては設計がおかしい。それと同じように型の扱いが苦しいときは往々にして設計が乱れている。

Stack Overflowだのでサンプルコードを見るとき、JavaScriptとかPythonのコードは本当に品質が低い。逆にC#とかRustのコードは一定の信頼性がある。これはひとえに、異常な設計に気づける言語を使ってきたかどうかで生まれる差なんだろう。型は設計に対するアラートをあげてくれる。型なき言語は使用者の設計能力を養わない（二重否定）。

◆未来志向

設計が乱れていることに気づけるかどうかは経験に依ってしまう。正しい設計がしたいみたいな考えが無ければ己のコードの乱れに気づけるわけもなく、設計おかしいよと指摘されてもピンと来るまでに三百年かかる。

自分で新しいコードを生み続けてメンテをしない人間がいたら、己の設計のヤバさに気づける機会は永劫にしてこないのかもしれない。属人性MAXのコードを生んでも誰も指摘してくれないのだから。

幸か不幸か、コードは書けば動く。でも、その動くコードを他者が読めるかどうかはまた違う話になってくる。読んで理解して安全に修正できるかどうかは、動くかどうかと別の次元にある。だから我々は要件を巧く抽象化し、処理の構造を設計して整然としたコードを残しておかねばならない。

さもなければコードの確からしさを客観的に評価できない。テストも書けない。この先生きのこれない。コードのリーダビリティはスケーラビリティに直結する。和訳すると、認知ビリティはビジネスの拡大ビリティに直結する。認知負荷の低いシステムは一般的に拡張可能性が高く堅牢。リーダブルならスケーラブルでエクステンシブルでデュラブル。

やべぇコードはやべぇ事態を引き起こす時限爆弾である。修正に変なコストとリスクが発生する迷宮であり、人をアサインするにも迷宮を歩かせるんだから無駄に時間がかかる。短期的に見たら優秀であっても長期的に見たら負債でしかない。

裏を返せば、プロダクトコードでも2年くらいで捨てるなら設計もそんな絞らなくても良いと言える。のではないか？機械学習界隈のことを詳しく知らんけど。とはいえ来年捨てるコードであっても俺はクソコードのプルリクを1片たりとも通しません。いや1片くらいなら日常的に通してるけど。設計にかかる部分はさすがに通せない。

◆コードと人間

以下のようなツイートもあったりする。ブログ記事の筆者の置かれている状況を純粋に想像できてないんだけど、想像できない人がいるのもそれはそれで仕方がない。

いきなり「リファクタリングした」とかいって意味不明なコードをpushしてくるような人も居るよね。それは誰からしてもよくない。

元のブログについて、筆者の素行が悪いのにさほど重大に書かれていない箇所がある。

そこで、頭の至らない私にとって選択できる解決策はあまり思い浮かばず、「第三者に判定してもらおう」と思い、ソースコードの一部を私の部の slack に共有し「このコード、率直にどう思いますか？」とお伝えしました。

自社開発メガベンチャーをわずか半年で鬱退職した雑魚エンジニアの話｜JoanOfArc (note.com)

あかんて笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑犬笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑笑

ひとつだけ「笑」じゃない文字が含まれているよ。わかるかな。

いきなり社内Slackにコードを提示して「どう思う？」とか、よくないことだわ。

書いたコードと自尊心が密結合しちゃってるザコのほうが社会には多いので、気を付けたし。俺は盾突かれたらワクワクしてくるけど、コードの不備を指摘された時点で不機嫌になる人のほうが断然多いよ。だから新人さんはリファクタリングの提案をするにも相手のオッサンのメンタルコントロールをしなはれ。そしてそもそも、新参者は大抵の場合プロジェクトの経緯や状況を理解できてないわけだから、おいそれとリファクタリングの提案すんな。人間関係が危ねぇ。

とはいえ、リファクタリングの実施は早ければ早いほど経済的ではある。そういう提案を（やるにせよやらないにせよ）真剣に捉えず蔑ろにして部下を潰したほうも悪い。使えない部下を使えないのは自分が使えないからだ。潰すほうも潰されるほうもどっちも悪い。さらに言えば、人ひとり従えるカリスマすらも持っていない一兵卒の下にフォローなく雑兵をぶら下げた無能も悪い。メンバーというものはリーダーたる器を持つ人格に当てがってあげないと潰れて居なくなる。人間を簡単に潰すなよ。目的意識をもって潰せ。

◆結

ML.NETってそういえばどうなったんですかね。

ML.NET のチュートリアル – ML.NET | Microsoft Learn

なんだかやれること増えてそうな気がする。気のせいだろうか。機械学習もやってみたい気がしないでもないが、それを活かしたい困りごとが思いついてないから手が出ない。強いて言えばエロ画像のモザイク加工を元に戻すとかだろうか。