Notices by カバ (yoto_3@qiitadon.com), page 91

何やら過分な評価をいただいておりありがたいことです

よと（仁）
やつは仁のものよ...

よと（天）
よと（地）
よと（人）←イマココ

私は人だったらしい

よと(人)

よき(斧)

レイヤーが遠くなればなるほど見なくてもよき(意味深)

レイヤーと言われてもコスプレイヤーの略語の方を先に思い出してしまうようになった

ご記憶にありますか？ #ご愁傷様です

そういうことが起こる時はだいたいやべー時です

conwayの法則の逆なんですけど、チームは分割されてるけど機能が分割しきれてないみたいな状態において最下流の担当者同士のコミュニケーションが激増するという場合があります。この場合はコミュニケーションパターンがシステムのパターンを作るんじゃなくて、システムのパターンがコミュニケーションのパターンを作ってしまうんですね。

分解されていない大きな桃が、どんぶらこ、どんぶらこと(ry

影響範囲を上流で分解しておいてくれ…頼む…

「読まなくていい」（知らなくていい）訳ではないというのは、どちらかというと、分離されている前提でコードを読むと、決めつけに惑わされて時間を浪費するので、そういう"先入観"なく素直にコードを読んだ方が良いよ、という事を言いたいだけだったりする。
全員が、文法レベルやコード解析レベルで必ずそういうバグを含まない環境で作業をしているなら良いけど、文法やコード解析で防がれていない場合は、ステート変えてるバグを踏む可能性があるから、ちゃんと読もうということ。
この手のバグは、パッと見は動くので、単体レベルで自動テストもスルーして、結合とかそれ以上のデータパターンの整合性を見るとか、そういうタイミングで露見して、一層時間を浪費することになったりする。

そもそも切り分けられてないじゃんというのは、全く正しいんだけど、「頑丈なものを作る」という意味でのエンジニア的ではないような気がしている。
ライブラリなんかは、そもそも切り取られているので、比較的そのようなバグは起きにくい。
ライブラリに対する関心の分離と、コーディングでの関心の分離は、本来はニュアンスが違うものであるべきと思う。

あああーいま唐突に、ようやく関心の分離の適切な言い換えがわかった
「知らなくていい」んじゃない、「単に影響範囲が少なくなる」んだ

今度からそう言おう、関心の分離は実装読まなくていいとかそういう事を言っているのではなくて、直接的な影響範囲を少なくしている(ので結果的に実装読まなくてよい場合もある)と

セッタゲッタみたいなものは、ステートの変更なので本質的な影響範囲は変わらないし、結合テストでバリエーション試さなきゃいけない的な意味で結局複雑度変わらないんだけど、まあそういうのを少なくするための工夫

上流がうっかりクソを下流に流した時に何が起こるかわかってない人間に上流やらせるの怖いんですよね。だから下流から上流へというキャリアパスができてしまう。本当は下流の達人と上流の達人が仕事するべきなんですよね…

ぼくはなんかこういう愛らしい存在ですおぼえてください

社会にビルトインされたシステムですからねー。キリスト教のチャリティーも同様の趣旨ですが感謝するしないはどうなんでしょうね？