仕事で設計の事を考える機会が多く、この実装は本当に良いものか悩みながらコードを書いている。
大体は答えが出なくて過去の経験から捻り出した答えにプラスアルファの知見を載せてコミットするわけなんだけど、それで何度も納得がいかない気持ちになってモヤモヤしてて、今日もそういう事を思いながらさっきまで仕事をしてた。
良いコードってなんだろうな
普通に考えればメンテナビリティがあって可読性の高いコードで、パフォーマンスが十分出る事なんだよなぁ、と。
でもそんなことは分かってるのに書けない。
何故かけないかというと、いつも向き合ってる問題は違ってて、メンバーの理想もみんな違ってるから。
じゃあ固定なら書けるのかというと、チームを固定しててもその難しさと戦うチームは見てきていて、どうもそういう問題じゃなさそうだぞ、と感じる。
向き合っている問題は本当に違うんだろうか？
これが本当にわかんない。
WEB システムとかだと正直やってる手順はいつも同じで、ロジックは多少違うかも程度にも思える。
リクエストを受け付けて、認証をして、入力のバリデーションをして、DB にデータを保存して、レスポンスを返す。
この繰り返しで、フロントは UI 側から API を叩いて UI にレスポンスを反映する程度なんだな。これだけ聞くとめちゃくちゃ繰り返しやんけという気持ちになる。
でも実際には状態が複雑に絡み合って、考えうる限りのケースに合わせたコードのチューニングが必要で、わりかしちょいちょい意味のわからんバグをみんな産んでる。
今日もそういうのを見てきたばっかり。
アーキテクチャの話
いつもやってる事をいつもと同じようにやるのはまぁ思考停止でできるからある種楽なんだけど、毎回変な辛さがある。
なのでみんなルールを開発に持ち込んで運用する事で、訳の分からん事を排除してなるべく安全にプログラムを書こうというのがアーキテクチャの正体なんだと最近思い始めた。
クリーンアーキテクチャとかレイヤードアーキテクチャとかの議論もいつもホットで、X でも毎日のように語られてる。
個人的には深追いしても仕方ない気がするので、ある程度嗜んだ後は誰かが引いたレールという名のルールを使ってチームのルールを作ってるんだと思う。自分がお手伝いで入ってる時もそんな感じ。
色々見たりやったりしてきた中で、自分のアーキテクチャへの感想は、コードレベルでは普通そんなにルールを決めることはないかもしれんな、ということだった。
いる？それ？みたいな。
フレームワークとかはルールに乗っかることで数多の疑問を考えなくして、楽に目的を達成できるけど、オレオレアーキテクチャはよほど考えてないと大体破綻する。
自分も何回も破綻した。
その上で経験を元にいうことがあるとすると、ルールは多すぎてもメンバーに理解されないし、適切に運用されなくなる。
大事なのはそのアーキテクチャで何を実現したいかだということ。
大体は自分のちっぽけな脳みそでもコードを書くのが辛くならない程度に問題が分離されてて、変なところに配慮しなくても良いところだと気づいた。
やらんでも良いことおおすぎ
GraphQL とかやってると、自動生成とかあって、便利そうに思うんだけど、やっぱ不便なんだよね。
Go + TypeScript で、スキーマ定義したら TS の型とエンドポイントのコール関数が生成されて、それを呼び出せば良いみたいなの、最初はおおって思うってはいた。
最初だけ。自動生成される事でコードの量はめちゃくちゃ増えるし、ビルドルール作らないといけないし、サーバーと疎通してスキーマ取得しないと生成しないし、開発手順ミスるとデッドロックみたいになる。
Go も自動生成系言語なのでどっちも大量に生成してて、生成 AI にコード書かせる並に何でビルドこけてんのか理解が追いつかない時も多々ある。
自動生成がダメじゃないんだけど、必要性はちゃんと考えたいし、不便を感じたり、速度が出ない足枷に感じるなら検討し直しも必要なんだなと思った。
とりあえず、モックと DI は極力なしでやれるアーキテクチャが自分にとって居心地のいい場所なんだなとか思ってる。