エンジニア経験5ヶ月の新人がDDDやTDD_コンポーネントを駆使してクソコードを改革してきた話

新人エンジニアとして入社してから5ヶ月。クソコードと向き合って5ヶ月。スタートアップというスピードが求められる環境で、DDD的アプローチやTDD、Vueコンポーネント等を用いて小さいところから少しずつクソコードを綺麗なコードになおしてきた時の考え方や具体的な方法をお話します。

Transcript

1. エンジニア経験5ヶ月の新人が DDDやTDD、Vueコンポーネントを駆使して クソコードを改革してきた話
2. GVA TECH株式会社 CPO兼エンジニア PHP/JS/Vue.js/CakePHP/Laravel/AWS/heroku/Docker/MySQL/Python 香月 宜浩(かつき　よりひろ) ピーターパン@CPO&エンジニア (@hukuzatsu)
3. プライベート
5. お仕事
8. 今日の話 画面リニューアルで簡易的にDDDをやってみた 1000行あったctpファイルをVueコンポーネントに置き換えた 非同期処理のAPI作成をTDDでやってみた
9. 画面リニューアルで簡易的にDDDをやってみた 1000行あったctpファイルをVueコンポーネントに置き換えた 非同期処理のAPI作成時にTDDでやってみた
12. 一つの条文に２つ以上の評価 右側をホバーするとここがハイライト表示 ビジネス的判断が必要な条項
13. 修正例が立場に応じて最大3種類に 登録していた自社の条文も表示
14. 不利・やや不利だけまとめたサマリ
15. 既存コード
16. Tableから直接取得 配列で要素を追加
17. テーブルから取得したデータの中身を直接変更 Tableから直接取得
18. ここでもデータの中身を直接変更
19. if文で判別して同じような処理を書いている 引数がなんなのかよう分からん
20. ネスト の中でネスト 画面表示に不要なプロパティ が多数 不要なプロパティ 全てpublicだから書き換え放題
21. 既存コードのつらみ ・DBから取得している多重の階層構造をもつデータ ・をコントローラーで直接編集 ・処理途中で要素の追加や編集を縦横無尽に 変更すべき箇所が見つけづらく、変更するのが怖い
22. モチベーション ・コードをスッキリさせたい ・画面変更時の修正箇所を限定したい ・データ構造、アウトプットの形を保証したい ・でもあまり時間をかけたくない DDD(ドメイン駆動設計)のドメインモデルを用いて解決出来ないか
23. DDD (ドメイン駆動設計)とは ‘’ドメイン駆動設計（英: Domain-driven design, DDD）とはソフトウェアの設計手 法であり、「複雑なドメインの設計は、モデルベースで行うべき」であり、また「大 半のソフトウェアプロジェクトでは、システムを実装するための特定の技術では なく、ドメインそのものとドメインのロジックに焦点を置くべき」であるとする。’’
24. DDD (ドメイン駆動設計)とは 顧客の問題領域 = ソフトウェアの対象 = ドメイン 顧客やその領域の専門家としっかり話して 共通で使う言語を定義 ドメイン　→　モデル化
25. togetterデビュー達成
26. DDD (ドメイン駆動設計) 今回の課題 引用： https://codezine.jp/article/detail/9546
27. ドメインモデル 引用： https://codezine.jp/article/detail/9546
28. 値オブジェクト：ドメイン特有の型を表現 ・リスク(0 ~ 5の6段階)をint型にした場合 あってはならない変更が可能 リスクに関する処理が色んなところに分散
29. 値オブジェクト ・リスク(0 ~ 5の6段階)をRisk型にした場合 あってはならない値を避けられる リスクに関する処理は Riskクラスにまとめられる
30. エンティティ：ドメイン特有の型 エンティティ ・一意に識別 ・可変 集約 ・外から直接操作するエンティティ
31. やってみた
32. 条文 リスク リスク文言 コメント 条文種類 要素抜き出し = 用語の定義 評価結果
33. レコメンド条文 自社条文 要素抜き出し = 用語の定義
34. 構造整理 リスク コメント 条文種類 リスク 文言 修正例 リスク コメント 条文種類 リスク 文言 自社条文 レコメンド条 文 自社条文 レコメンド条 文 自社条文 レコメンド条 文 自社条文 レコメンド条 文 評価結果 評価結果 修正例 条文 条文内容
35. 構成 Controller Table Controller Component Domain Object Table Cakeの Entity Cakeの Entity
36. Risk：値オブジェクト privateなので外から変更不可 コンストラクタでriskの値を保証 リスクに関する処理を このクラス内に集める 関連するconstもここに定義
37. EvaluationResult：エンティティ 指定したリスクに該当するか FixExampleという値オブジェクト
38. FeedbackProvision：集約 (エンティティ) 集約を通して中のエンティティを操作 コンストラクタで エンティティをプロパティにセット このエンティティがnew出来た = 必要なデータが適切な構造で揃っている
39. Component 集約を生成 ドメインモデルはCakeのEntityに依存させたく無いのでプリミティブ な型にして渡す 集約のみ使う (値オブジェクトやメンバのエンティティは使わない ) CakeのTableオブジェクトをロード
40. Controller Componentを使うのみ リスクを指定して 特定リスクに該当する条文のみ取得
41. 結果
42. 結果：Controler Excellent Kuso
43. 結果：データ構造 Excellent Kuso
44. 結果 データの構造がスッキリ 変更箇所がドメインモデルに限定され変更箇所が特定しやすくなった ドメインオブジェクト単位でテスト書けるようになった DDDの一要素を使うだけでも完璧ではないが キレイで変更箇所を特定しやすいコードになった
45. 画面リニューアルで簡易DDD的アプローチをやってみた 1000行あったctpファイルをVueコンポーネントに置き換えた 非同期処理のAPI作成時にTDDでやってみた
46. 既存コード
47. 約１０００行 Kuso
48. ・1000行 ・全ての要素に対するJSの処理が同じファイルに書いてある 既存コードのつらみ
49. ・ビューを要素毎に分けたい (JSの処理も分けたい) ・変更箇所を分かりやすくしたい モチベーション
50. Vue.jsの単一ファイルコンポーネントで要素単位でファイルを分けた
53. 結果 要素と関連するJSロジックを分離出来た 変更箇所が特定しやすくなった
54. 画面リニューアルで簡易DDD的アプローチをやってみた 1000行あったctpファイルをVueコンポーネントに置き換えた 非同期処理のAPI作成時にTDDでやってみた
55. 自社の雛形の条文を修正例として 表示するかどうかを非同期で設定 条文を編集出来る
56. 条文内容を保存
57. ストックした条文を編集 ストックした条文を修正例に 表示するかどうかを設定
58. ・全て非同期処理 ・画面が出来てない状態でサーバーサイドの実装だけ進めたい ・ちゃんとアウトプット保証した状態で実装を進めたい モチベーション
59. TDDっぽくやってみた
60. テストを書く 処理を書く テストで失敗する テストを通す処理を書く テスト通る
61. Controller単位のテストだと認証とかいろいろ面倒なので Component単位でTDD Controller Component Table この部分のinput/outputを保証するテストを作成 ビジネスロジックがちゃんとコンポーネントに入っていれば ある程度テストも書きやすい
62. Controller単位のテストだと認証とかいろいろ面倒なので Component単位でTDD Controller Component Table テスト用のコネクションを作って Fixtureでテストデータを定義
63. テスト書く APIの定義があるはずなので assertも書ける
64. 処理書く　-> テスト実行 こんなメソッド無いので 当然テストはこける
65. エラーを解消するよう処理書く 処理書いてテスト実行 書いたら即テスト実行 出たエラーを解消していく
66. テストが成功したら完成
67. 結果 TDDで実装していくと実装が終わる頃にはテストが出来ている 実装途中のテストを自動化出来るので確認コストが下がった 安心して実装を進められた 先に出したい結果を定義するので実装の見通しが立てやすかった
68. まとめ ・DDD、Vueコンポーネント、TDD等完璧に出来なくても一要素を実践してみるだけでも効 果はありそう ・登壇が決まると勉強する。勉強すると知らなかったことを知れる。すると今のコードがク ソコードに見えてくる。 クソコード改革は永遠に不滅です
69. GVA TECHでは 一緒にプロダクト開発する仲間を募集しています 【みんなで作った開発組織のクレド】 ・問題の解決に向けて、技術・デザイン・プロダクトの視点に立って、貪欲に自由な挑戦を続けます ・躊躇なく領域を超え、自分たち事化して困難な問題に立ち向かいます ・一人一人がお互いの仕事・人格・考え方に敬意を持って、行動で示します ・ユーザーが抱える本質的な課題を明らかにするために、最適なプロセス・組織を追求します ・本質的な課題解決を繰り返すことで、世界で誇りを持てるリーガルサービスを生み出す意識と責任感を育みます