Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
オブジェクト指向で類型化するコードレビュー
akkie76
June 29, 2022
0
230
オブジェクト指向で類型化するコードレビュー
akkie76
June 29, 2022
Tweet
Share
More Decks by akkie76
See All by akkie76
Crashlytics と Android の連携で トラブルシューティングを効率化する
akkie76
0
140
アプリアーキテクチャを明文化しチームの開発効率をアップ
akkie76
1
420
こんなコードレビューは嫌だ
akkie76
0
420
アプリアーキテクチャを明文化しチームの開発効率をアップ
akkie76
1
870
チームの設計力を高めるためのTIPS
akkie76
0
510
明日からできるコードレビューの心構え
akkie76
0
300
これで失敗しない! JUnit 5 へのマイグレーション方法
akkie76
0
220
アーキテクチャを明文化して開発に臨んだ話
akkie76
0
530
レビューガイドラインで技術力を見える化する
akkie76
0
710
Featured
See All Featured
Fontdeck: Realign not Redesign
paulrobertlloyd
74
4.3k
For a Future-Friendly Web
brad_frost
166
7.7k
The Art of Programming - Codeland 2020
erikaheidi
35
11k
Intergalactic Javascript Robots from Outer Space
tanoku
261
26k
Building Applications with DynamoDB
mza
85
4.9k
Stop Working from a Prison Cell
hatefulcrawdad
263
18k
Building a Scalable Design System with Sketch
lauravandoore
451
31k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
182
15k
How GitHub (no longer) Works
holman
298
140k
KATA
mclloyd
12
9.7k
How To Stay Up To Date on Web Technology
chriscoyier
779
250k
Code Review Best Practice
trishagee
50
11k
Transcript
〜 チームで育てるオブジェクト指向 〜 オブジェクト指向で 類型化するコードレビュー Akihiko Sato オブジェクト指向 LT 会
vol.4 #ooltjp
自己紹介 Akihiko Sato / 株式会社ラクス Lead Engineer SaaS 開発 (Backend,
Frontend) / Mobile 開発 (iOS, Android) 上流工程、コードレビュー、チームの課題改善など 読書 / コーヒー / HHKB / 縄跳び
今日伝えたいこと コードレビューを通して オブジェクト指向をチームで育てよう!
レビューの取り組み 現在、私のチームではレビューガイドラインを明文化して、 レビュアーはガイドラインに従ってコードレビューを行ってます。
私が join した当時の課題 ・実装のセオリーが分からない ・レビューの観点が分からない レビューがしっかり行われていない体制だった モバイル開発経験者が少なく実装のノウハウがない
その結果・・・ ・技術力がなかなか伸びない ・定期的にバグが発生する
レビュー指摘を類型化できないか? チームメンバーの弱点を表せないか? どうやって課題を改善するか ガイドライン(明文)を作って、レビューコメントを類型化しよう! ( レビュー指摘は財産 )
ガイドライン作成にあたって 基本的なアウトラインを決めよう! 7 つの観点でレビューコメントを類型化することに
観点について ① 指摘の観点を 7 つに分類 1. Design (設計) 2. Simplicity
(理解容易性) 3. Naming (クラス、メソッド、変数名などの命名) 4. Style (コードスタイル)
観点について ② 指摘の観点を 7 つに分類 5. Functionality (機能を充足しているか) 6. Tests
(自動テストが適切である) 7. Document (コメント、ドキュメンに関連)
観点について ③ オブジェクト指向の観点で重要な項目 ・ Design (設計) ・ Simplicity (理解容易性) ・
Naming (クラス、メソッド、変数名などの命名) ・ Style (コードスタイル)
Design (設計) システムにとって適切な責務、振る舞いになっているか。システムと してアーキテクチャを遵守できているか。また、システム全体として 一貫性ある設計になっているか。 ・関心の分離(≒単一責任の原則)違反 ・密結合 ・低凝集 ・ DRY
原則違反
Design (設計) class SummerDiscountManager { lateinit var manager: DiscountManager /**
* 商品を追加する */ fun add(product: Product): Boolean { if (product.id < 0) { // バリデーション ① throw IllegalArgumentException() } if (product.name.isEmpty()) { // バリデーション ② throw IllegalArgumentException() } val temp: Int = if (product.canDiscount) { // 条件分岐 ① discountMmanageranager.totalPrice + manager.getDiscountPrice(product.price) } else { manager.totalPrice + product.price } return if (temp < 3000) { // 条件分岐 ② manager.totalPrice = temp manager.discountProducts.add(product) true } else { false } } } 「良いコード / 悪いコードで学ぶ設計入門」より
Simplicity (理解容易性) システムとして可読性あるコーディングになっているか。処理ができ るだけシンプルな振る舞いになっているか。 ・ネストが深い if 分 ・複雑な三項演算子文 ・ stream,
filter, map を多用した Object 整形文
Simplicity (理解容易性) 分岐が多い if 分例 val hitPointRate: float = member.hitPoint
/ menber.maxHitPoint var currentHealthCondition: HealthCondition = HealthCondition.NONE if (hitPointRate == 0) { currentHealthCondition = HealthCondition.DEAD } else if (hitPointRate < 0.3) { currentHealthCondition = HealthCondition.DANGER } else if (hitPointRate < 0.5) { currentHealthCondition = HealthCondition.CAUTION } else { currentHealthCondition = HealthCondition.FINE } return currentHealthCondition 「良いコード / 悪いコードで学ぶ設計入門」より
Simplicity (理解容易性) コメントでの指摘例 val hitPointRate: float = member.hitPoint / menber.maxHitPoint
var currentHealthCondition: HealthCondition = HealthCondition.NONE if (hitPointRate == 0) { return currentHealthCondition = HealthCondition.DEAD } if (hitPointRate < 0.3) { return currentHealthCondition = HealthCondition.DANGER } if (hitPointRate < 0.5) { return currentHealthCondition = HealthCondition.CAUTION } return currentHealthCondition = HealthCondition.FINE
Naming (クラス、メソッド、変数名などの命名) 変数やクラス、メソッドに責務を意図した明確な名前が付けられて いるか。英語文法に誤りがないか。 typo もこれに含まれる。 ・振る舞いと一致しない変数名、関数名 ・責務と一致しない関数名 ・英文法の誤り
Style (コードスタイル) コードスタイル言語仕様に準拠しているか。 ・静的解析違反 ・不適切なアクセス修飾子 ・表記違反(スネーク、キャメルなど) ・公式( Apple 、 Google
等)が公開しているガイドライン違反
具体的な利用方法 指摘例 MUST ( Design ):ドメインロジックが Controller クラスに実装されてます。 domain 層の対象
package に新しくクラスを作成して実装を移してください。 コメントの prefix として利用する。
[ 発展編 ] prefix を付けたコメントを集計 GitLab API ( Note API
)を利用してコメントを集計します。 具体的な方法は、 ラクス Advent Calendar 2021 ( 12/23 ) 「 GitLab API で Merge Request のコメントを一括取得する方法」 をご覧ください。
まとめ レビューガイドラインを明文化すると ① コードレビューでオブジェクト指向が学べる ② 苦手分野が明らかになる ③ スキルアップのためのアクションプランが検討しやすい チームでの導入を検討してみてはいかがでしょうか
オンラインイベントや中途採用を積極的に行ってます! 最後に
ご清聴ありがとうございました