設計/コードレビューで"常に"心がけるポイント - little hands' lab

株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。

[nunulk]

"ユニットテストを書こうとしたときに、多くのクラスを組み合わせないとテスト観点が意味をなさないような場合は設計に問題がある可能性があるので、"

[yo-iida]

責務！テスト！責務！テスト！

[morimarii]

責務の観点とテストの観点はまじ大事、というか、この記事にある通りそこさえ抑えられていればあとは些末な話だから。。

[JGEEM]

できればテストを書きやすいか、ではなくテストが書かれており網羅性は十分かという観点で確認したいがそれはまた別の話とすれば、見るべきは「レイヤ責務に沿うか／高凝集・疎結合か」

[hiroki23]

“レビュー”

[youko03]

“責務！テスト！責務！テスト！” これは名言かも。

[yasu-osu]

少し視点は異なるが、組織論の話としても示唆を得た。そのタスクをやるべき人がやれているか。結果が検証しやすい状態になっているか。組織に技術的負債を生まない秘訣もそこにあるのかもしれない。

[tofu-kun]

コードをどこに書くべきか

[yamadar]

直近で使いそう。

[wazly]

レビュー依頼が積み上がってくると実装コードはほとんど見なくなる。バグがあっても後からすぐ直せるから。その代わり制約から逸脱してないか、インターフェイスは適切かどうかは穴があくほど見る

[n314]

内容に反対はないけど“高凝集/低結合”は別の話では。これは型を手抜きせずに設計しろということだよね。凝集度が高くても技術駆動パッケージングにするかどうかとか、考え出すとややこしい。

[remonoil]

これを連呼しなくても維持・推進できる方法を知りたい。

[katsuyayamada35]

あああ

[letsspeak]

触ってないデータまで渡しちゃうコードほんとよく見る。依存関係がわからなくなるからやめて欲しいね〜

[sander]

なんかレビュアー任されそうになってる某お嬢に届け!

[jay-es]

レイヤーの責務、高凝集/低結合、ユニットテストを書きやすいか

[rin51]

> 「責務！テスト！責務！テスト！」

[sznm347975]

見てます

[odan3240]

"責務！テスト！責務！テスト！"