[B! コードレビュー] JGEEMのブックマーク

「コードがむずかしい」からの脱却

コード品質向上のいろは - 先達に学ぶ実践例 Lunch LT https://findy.connpass.com/event/300912/

JGEEM 2024/02/10

一昔前に比べると「コードが難しいから工数かけて改善します」が理解されやすくなったと感じる。とは言え定量的な指標はほしいし、何よりむずかしくしない努力としての仕様の言語化／目的・意図の確認／モブワーク

リンク

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

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

JGEEM 2024/01/23

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

リンク

もう初回コードレビューはAIに任せる時代になった - CodeRabbit -

どんな人向けの記事？レビューによって心理的なダメージを受けやすい方非エンジニアだが、エンジニアチームがどんな機能を作っているか知りたい方業務が溜まっていて、レビューに割く時間を捻出するのに苦労している方コピペできるコードも公開します初回レビューをAIに任せると、いろんなロールの人の役に立つレビューは得意ですか？優秀なエンジニアしかいないチームであれば、PRは1トピックに絞って小さく明確なコミットによって作成され、適切な要約とともに提供されることでしょう。しかし、実際にはいろいろな制約から、PRが想定よりずっと大きくなってしまったり、関連トピックと異なるコードが混じってしまうこともあります。実際のところ、大きなPRを適切にレビューするのは難しいことです。また、自分が詳しくない領域のレビューを行わなければいけない機会もあります。今回の記事は、レビューを作成してくれるAI C