リファクタリングで抽象力をつけ、 結果的にコード力がついた話

Transcript

1. リファクタリングで抽象力をつけ、 結果的にコード力がついた話 @hayochan-man
2. リファクタリングとは 開発・運用しやすいように既存のプロジェクトコードを書き直すること
3. リファクタリングするに至った背景 有志の学習者向けチーム開発で、1ファイルでロジックを実装。 各GETのエンドポイントを実装した所、コードが600行あたりに... その後、Create, Update, Deleteも追加をする必要があった！！ このままだと、コードがごちゃごちゃになってしまう...
4. 今日のテーマ 初学者視点（当時、勉強4か月目）でどのようにリファクタリングをしたか経験談を紹介
5. リファクタリングでやったこと Ⅰ. 各役割をどこに集約するか決める Ⅱ. エンドポイントのフローをパターン化する
6. 各役割をどこに集約するか決める
7. 1. 現状の整理 現状： 1つのファイルで処理を纏めて行っているため、 仕様変更やエラーが生じた場合、どこを確認して修正するかの判断が困難！ 方針： 役割ごとにどのディレクトリでファイルを管理するか決める。 →今回は小規模プロジェクトでよく使われているレイヤード構造を選択。
8. 2. 各役割の定義をする プレゼンテーション層 コンバート層 ビジネス層 永続化層 データベース層（MySQL等） リクエスト レスポンス レイヤード構造とは、 技術によって分割された構造。 メリットは、 技術的面に集中してファイル管理をできること。 プレゼンテーション層： HTTP リクエストの受付と、 レスポンス返却のみを担当する。 コンバート層： リクエスト値を受け入れ可能な形式へ変換し、 値の正当性を保証する。 ビジネス層： 永続化層からデータを取得したり、 そのデータで、値の計算やデータの集約等を実行する。 永続化層：データの取得・保存・削除を担当する。
9. エンドポイントのフローをパターン化する
10. 1. エンドポイントのフローを役割で分割する ①コンバート層 入力されたIdが正しいか確認する。 ②永続化層 Idをもとに指定したテーブルから、 特定のレコードを抽出する。 ビジネス層はどこ？ 指定Idを取得するのみのため、 ②を呼び出すだけになる。 ただ、削除等は存在確認も行う。 ① ②
11. 2. 役割ごとにコードをまとめて管理する ①コンバート層 入力されたIdが正しいか確認する。 ②ビジネス層はどこ 永続化層を呼び出すのみ。 削除等は存在確認も行う。 ① ②
12. 3. 正常値・異常値で処理を考える 正常 正常 正常 異常 異常 異常 リクエスト～レスポンスは一貫して、 各処理ごとに正常か異常かを判断する エラーとステータスコードは対応し、 異常値内でもステータスコードで、 返り値をパターン化できると分かる。
13. 4. エラーおよび返り値のパターン化 返り値：｛data: …, error: …｝にする 正常値の場合、値をdataに入れ、 エラーの場合はerrorに入れる。
14. 5. 正常値と異常値をハンドリング関数作成 最終的に正常値か異常値かを判断する
15. 6. 正常値と異常値をハンドリング関数実装 エラーを抽象化し、 handleResultでハンドリングすることに成功 これはGETの処理以外すべてに適用できる。 関数は正常値・異常値が返ることに加え、 ステータスコードは他でも同様だから
16. 結果 機能追加の際も処理の追加が楽になった！！ 各エンドポイントに対して、実装速度を短縮できた。（体感倍くらい）
17. まとめ リファクタリング中は気づかなかったが、全体を通し、 処理を抽象化しているといえる（特にプレゼンテーション層）。 また、各エンドポイント単位で処理の類似性を観察すると、 正常値・異常値のハンドリングも抽象化できること学べた 。 （これを発展させると、 Railway Oriented Programingのような関数型プログラミングに繋がります。）
18. リファクタを加速させた教材：