他人がはやく読めるコードを書く ために

2023年8月NE * Linkage合同勉強会セッション

[shingo-sasaki-0529]

フィーチャーベースの構造が依存関係がわかりやすく捨てやすいのはよくわかるけど、フレームワーク側が Opinionated なディレクトリベースの挙動を持ってる以上はそれに逆らわないほうが良い派。

[rgfx]

helperやserviceやrepositoryやmodelやlibやらを文脈(つかfeature)ごとに探して回るのに疲れた人向けの手法でしょ？「似てるけど違うfeature」の辛さはビジネス側で要件が整理できてない問題であってコードとは別かな。

[kmaebashi]

これってつまり「賽の目状アーキテクチャー」なのでは。https://minekoa.hatenadiary.org/entry/20100116/1263657955 /まあでもこの方がわかりやすいのでは、と思ってしまう時は私もある。

[uxlayman]

package by featureを突き詰めていく(依存をAPIのみ、リポジトリ/デプロイ単位を分けるetc)とマイクロサービスになる。目的は読みやすさというか独立性確保による開発効率UPだが

[manimoto]

package by feature、featureディレクトリ毎に使用するモデルがあるように見えるが、「同じArticleなのにfeatureごとにビジネスロジックが異なる」とか生じてツラそう。

[nunulk]

これなー、自分も1回やってみたけど懐疑的。コード追うのは大部分を IDE にお任せできるので、各レイヤーの下を（必要なら）機能で分割していくほうがわかりやすい気がする

[kiyo_hiko]

今の仕事やってるとむしろ他人のコードを速く読む技術がほしい

[asiamoth]

“他人がはやく読めるコードを書く”人は発表にスライドなんて使わない、説（すべてたんなる画像なのでコードをコピペ/検索できない、リンクが機能していない）を推していきたい。

[stabucky]

要点が何か見つけにくいスライドだった。要点が何か分かったがその具体的なやり方が書かれていない。

[ya--mada]

ﾅﾆｺﾚ?歴史遺物PHPerのコードをリファクタリングした事をネタにしたスライド？

[mayumayu_nimolove]

本末転倒

[remonoil]

機能ごとにコピペで量産していく古の手法なのでは？

[ghostbass]

一度に認識しなければならない量を減らす/ 個々のFeature内部でカオスになったりDRYから遠く離れることになりがちではある

[ikkitang1211]

こういう分割もあるんなー。学び。