リーダブルコード by DDD モデリングを起点に可読性の高いコードを実現する
モデリングを起点に可読性の高いコードを実現する2021/07/07 #readablelt Yoshiki Iidaリーダブルコード by DDD
View Slide
Yoshiki Iida (@ysk_118)エンジニアに始まり、スクラムマスター、プロダクトオーナー、マネージャー、執行役員を経験し、現場のチームビルディングから部署を超えた会社全体の改善など、アジャイルな組織づくりの推進を行ってきました。現在は株式会社ログラスにてソフトウェアエンジニアとしてプロダクト開発に携わっています。書籍「Scrum Boot Camp The Book 増補改訂版」コラムニスト。一般社団法人アジャイルチームを支える会 理事。$ whoami
ログラスについて は、事業進捗を可視化することで柔軟で高精度な経営推進を実現するプランニング・クラウドサービスです。
ログラスについて
● コードがリーダブルであることとDDDの関連● 実践プラクティスTopic
コードがリーダブルであるとは？
コードがリーダブルであるとは？他の人が最短時間で理解できること
理解できるとは？
理解できるとは？● 例えば、あるクラスが何をしているか理解できるとは？○ 何をしているのかわかる■ 状態/振る舞い○ 依存関係がわかる■ どこから呼ばれているか■ 何を呼んでいるか○ どんなビジネス的な意味を持っているかわかる
理解できるとは？● 例えば、あるクラスが何をしているか理解できるとは？○ 何をしているのかわかる■ 状態/振る舞い○ 依存関係がわかる■ どこから呼ばれているか■ 何を呼んでいるか○ どんなビジネス的な意味を持っているかわかるここまでは時間をかけてコードを読み込めばなんとかなるかもこれはコードだけではわからないかもしれない
理解できないとどうなるか？● 実装の手戻り● 実装の歪み○ その後の変更可能性を著しく下げる● 品質の低下○ 不十分なテスト観点● 低品質の再生産○ コピペによる増殖
システムを正しく作るためにはどちらも重要実装の理解しやすさ実装の目的の理解しやすさ
システムを正しく作るためにはどちらも重要実装の理解しやすさ実装の目的の理解しやすさ→ DDDというアプローチ
ドメインモデリングから始まる実装実装の理解しやすさ実装の目的の理解しやすさ ドメインモデリング実装 & リファクタリング
ドメインモデリングの位置付けビジネス的な一次情報● ユーザーヒアリング● ユースケースドメインモデリング● ドメインモデル図仕様・テストケース● 仕様● テストケース● 受入基準↑ビジネスとシステムをつなぐ最も重要なプロセス
ドメインモデリングのサンプル/*** コメント*/class Comment private constructor(val id: ID,val commentText: String,val isResolved: Boolean,val createdAt: DateTime,val updatedAt: DateTime,val createdUserId: ID,val commentType: CommentType,/** コメントの条件 */val condition: CommentCondition,) {companion object {fun create(commentText: String,createdUserId: ID,commentType: CommentType,condition: CommentCondition,): Comment {validationCommentTextLength(commentText)val createdAt = DateTime.now()return Comment(id = ID.gen(),commentText = commentText,isResolved = false,createdAt = createdAt,updatedAt = createdAt,createdUserId = createdUserId,condition = condition,commentType = commentType,)}}}/*** コメントの条件*/data class CommentCondition(val departmentId: ID,val projectId: ID,val yearMonth: YearMonth,)ドメインモデルを元に実装するデータの実例を併記しておくとわかりやすい
実装の目的の理解しやすさ● ドメインモデル図があれば登場する概念を一目で把握できる● ユースケースがあればそれらの概念がどう使われるのか理解できる● そこから仕様を導き出すことができ、その仕様を検証するためのテストケースを作成することができるここを最初に押さえていれば後からjoinする人も実装の目的は理解しやすい
余談: アンチパターン● 実装の目的が失われてしまったシステムは変更難易度が桁違いになる● 「なぜこの概念が必要なのか・・？」「この依存は必要なのか・・？」「この挙動でユースケースを満たしているのか・・？」○ コードを考古学して答えが見つかれば良いが最終的にエスパーで妥協しなければいけないケースもありうる
実装の理解しやすさ● 重要な要素○ 責務○ テスト○ リファクタリング
責務責務とは、そのクラスが行うこと/そのクラスが表すもの● 責務を1つに絞っていくことでリーダブルになること○ クラスの関心ごとが小さくなり理解しやすくなる○ テスト対象が明確になり、テストコード実装しやすくなる○ テストがあるとリファクタリングしやすくなり、コードがさらに読みやすくなる
責務例えば、ユースケース層では1クラス1パブリックメソッドにしていくと見通しが良くなるclass ProjectService(private val tenantSvc: TenantService,private val repo: ProjectRepository,) {fun list(tenantId: ID,projectId: ID): List {val projectList = ~~~return projectList}fun fix(tenantId: ID,projectId: ID) {repo.fix(tenantId, projectId)}fun create(tenantId: ID,projectParam: ProjectParam,): Project {return repo.create(tenantId, projectParam)}}class ListProjectUseCase(private val tenantSvc: TenantService,private val repo: ProjectRepository,) {fun execute(tenantId: ID,projectId: ID): List {val projectList = ~~~return projectList}}class CreateProjectUseCase(private val tenantSvc: TenantService,private val repo: ProjectRepository,) {fun execute(tenantId: ID,projectParam: ProjectParam,): Project {return repo.create(tenantId, projectParam)}}class FixProjectUseCase(private val tenantSvc: TenantService,private val repo: ProjectRepository,) {fun execute(tenantId: ID,projectId: ID) {repo.fix(tenantId, projectId)}}
テストリファクタリングしやすくなる。変更しやすくなる。テストは資産！● テストに関するコメント● テストデータの可視化● 日本語変数を活用する
テストに関するコメント● 本質的なテストコード以外を小さくし、何をテストしているのかわかりやすくする@Testfun `インサートしたデータが削除できること`() {// given:val comment = createComment()dataCreators.comment.create(tenant.tenantId, listOf(comment))// 事前確認: 件数が一件取得されるcommentRepository.findById(tenant.tenantId, comment.id).also { assertNotNull(it) }// when: ID指定して削除するとcommentRepository.deleteById(tenant.tenantId, comment.id)// then: ID指定で取得できなくなるcommentRepository.findById(tenant.tenantId, comment.id).also { assertNull(it) }}データ準備はprivatemethod化when, thenで何をした結果どうなるかを明確化
テストデータの可視化● 大きなオブジェクトのテストデータはコメントなどで表現するのは限界がある○ 割り切ってスプレッドシートリンクをテストコードに残すinternal class ComparisonFlatTreeV3ViewTest {/*** テストデータの可視化 : https://docs.google.com/spreadsheets/d/1Gd_xxx---xx_XX/edit#gid=xx*/@Testfun`対比表Viewの数値部分 _月毎`() {
日本語変数の活用● 英語にすると馴染みがなくて可読性が低くなるような場合は日本語変数もアリ○ テストコードなどでは有用val 当期純利益 = result.treeView.items.find { it.id == "XXXXXXXXXXXXX" }!!当期純利益.also { it ->val jan = it.data.find { it.periodKey == "2020-01" }!!assertEquals(expected = BigDecimal(10000), actual = jan.actual.sum)val feb = it.data.find { it.periodKey == "2020-02" }!!assertEquals(expected = BigDecimal(20000), actual = feb.actual.sum)val mar = it.data.find { it.periodKey == "2020-03" }!!assertEquals(expected = BigDecimal(30000), actual = mar.actual.sum)}
リファクタリング絶え間なく行う● 個人的によくやるもの○ 責務を細かく分割する○ プリミティブ型やタプルに対して名前をつけた型を用意する○ SLAPでメソッドの粒度を揃える○ ...
その他● 見た目の美しさ&統一はIDEとlinterに任せる● 命名はガイドライン化し認知コスト・思考コストを下げる● 参照実装のガイドライン化○ 真似して欲しいものとしてまとめておく● コメント○ 真似して欲しくないものをしっかり書く
命名のガイドライン化命名がブレやすいものは認知コストになるためガイドライン化。変更したければPullRequestベースで更新していく。
真似して欲しいものオンボーディング資料に参照実装として積極的に真似して欲しい実装をまとめてある
真似して欲しくないもの// TODO: TestXxxFactory実装に寄せるprivate fun mockDepartment(id: String) = Department.of(id = ID.from(id),tenantId = tenantId,code = Code.of(id),name = Name.of(id),externalSystemDepartmentCode = null)新たに汎用的な仕組みを作ったので古い書き方がコピペされないように機械的にTODOを埋め込むoverride fun insert(tenantId: ID, account: Account) {// TODO: バリデーションはドメイン層に委譲if (account.accountType.isAggregationType())throw BadRequestException("科目種別はSTANDARD_PL_AGGRには設定できません")insert(listOf(account))}このレイヤの責務でないものを明示
● 変更しやすいシステムの特徴○ リーダブルであること■ 実装を理解しやすいこと■ 実装の目的を理解しやすいこと● 実践アプローチ○ ドメインモデリングは実装の目的理解にダイレクトに有効○ 責務を意識し、テスト・リファクタを回していくことで結果的にリーダブルになっていく○ 参照実装などを充実させることでチーム開発がより効率化まとめ
yoshikiiida
mthiroshi00excite
hcrane
.png){kind=avatar}
headwaters
usamik26
tomokusaba
shintanimoto
akkeylab
yusukebe
kilometer
tomotaka_yamasaki
gpsnmeajp
3n
jeffersonlam
bryan
garrettdimon
danielanewman
morganepeng
mclloyd
aki_iinuma
sstephenson
samanthasiow
philhawksworth
maggiecrowley