Download to read offline
Example of exiting legacy system
- 1. GMOインターネット株式会社 ⽥中 ⾼進 新卒３年⽬が⽴ち向かった お名前.comでの 超巨⼤レガシーシステム脱却の事例 JJUG CCC2019 Fall #ccc_a6a
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9. 9 アジェンダ l お名前.comの紹介 l 今回のプロジェクトの概要と課題 l問題点ごとの解決策（仕様・実装・テスト） l 結果どうなったのか
- 10. 10 アジェンダ l お名前.comの紹介 l 今回のプロジェクトの概要と課題 l問題点ごとの解決策（仕様・実装・テスト） l 結果どうなったのか
- 11.
- 12. 12 アジェンダ l お名前.comの紹介 l 今回のプロジェクトの概要と課題 l問題点ごとの解決策（仕様・実装・テスト） l 結果どうなったのか
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26. 26 アジェンダ l お名前.comの紹介 l 今回のプロジェクト概要と課題 l問題点ごとの解決策（仕様・実装・テスト） l 結果どうなったのか
- 27.
- 28. 28 l 流⽤元の仕様に関するドキュメントなどがない l 複雑化している箇所があり、修正が困難 l単体テストのテストコードが存在しない 現状の問題点 問題点ごとの解決策（仕様・実装・テスト）
- 29.
- 30. 30 Ø 流⽤元の仕様に関するドキュメントなどがない Ø ソースを⾒ても、意図がわからない Ø微妙な実装があったとき、ソースが仕様通りな のか、バグなのか、わからない 問題点 問題点ごとの解決策（仕様）
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38. 38 l JDKの選定 l フレームワークの選定 lWeb API アーキテクチャの選定 採⽤アーキテクチャの選定 問題点ごとの解決策（実装）
- 39. 39 l JDKの選定 l フレームワークの選定 lWeb API アーキテクチャの選定 JDKの選定 問題点ごとの解決策（実装）
- 40. 40 Ø JDKの選定基準 Ø LTSで最新versionな物 ØAdoptOpenJDK LTS 11 Ø 選定理由 Ø 既存で動いているシステムで実績 JDKの選定 問題点ごとの解決策（実装）
- 41. 41 l JDKの選定 l フレームワークの選定 lWeb API アーキテクチャの選定 フレームワークの選定 問題点ごとの解決策（実装）
- 42. 42 Ø フレームワークの選定 Ø 欲しい要件 Ø組込Tomcat内蔵 & 標準的な実装にしたい Ø Play Framework OR Spring Boot フレームワークの選定 問題点ごとの解決策（実装）
- 43.
- 44. 44 l JDKの選定 l フレームワークの選定 lWeb API アーキテクチャの選定 Web API アーキテクチャの選定 問題点ごとの解決策（実装）
- 45. 45 Ø Web APIアーキテクチャ Ø 選定要件 Ø 参考にできるガイドラインがあること Ø 疎結合な実装にできること Ø テストコードが書きやすいこと Web API アーキテクチャの選定 問題点ごとの解決策（実装）
- 46. 46 Ø 最終的に決まったのが Web APIアーキテクチャの選定 問題点ごとの解決策（実装） 3層アーキテクチャ 参考:https://terasolunaorg.github.io/guideline/public_review/Overview/ApplicationLayering.html 参考:https://qiita.com/YutaKase6/items/7d88fa23f81366905270
- 47. 47 Ø 他のアーキテクチャは、検討しなかったのか Web APIアーキテクチャの選定 問題点ごとの解決策（実装） ØMVC ØMVCより、強度なアーキテクチャにしたかったため ØClean Architecture Ø学習コストが⾼いので、⼯数の関係上断念
- 48. 48 Application Layer • Controller •Resource Infrastructure Layer • Repository Impl • Entity (JPA) Domain Layer • Domain Object • Service • Repository Interface 3層アーキテクチャ ビジネスロジック です 問題点ごとの解決策（実装） Web API アーキテクチャの選定
- 49. 49 Application Layer • Controller •Resource Infrastructure Layer • Repository Impl • Entity (JPA) Domain Layer • Domain Object • Service • Repository Interface 3層アーキテクチャ 依存依存 Web APIのアーキテクチャの選定 問題点ごとの解決策（実装） Web API アーキテクチャの選定
- 50. 50 Application Layer • Controller •Resource Infrastructure Layer • Repository Impl • Entity (JPA) Domain Layer • Domain Object • Service • Repository Interface 3層アーキテクチャ 依存しない 問題点ごとの解決策（実装） Web API アーキテクチャの選定 依存しない
- 51. 51 Application Layer • Controller •Resource Infrastructure Layer • Repository Impl • Entity (JPA) Domain Layer • Domain Object • Service • Repository Interface 3層アーキテクチャ 各レイヤーごとに処理が分かれている Web API アーキテクチャの選定 問題点ごとの解決策（実装）
- 52. 52 Ø 疎結合な実装になること OK Øテストが書きやすいこと OK Web API アーキテクチャの選定 問題点ごとの解決策（実装）
- 53.
- 54. 54 問題点ごとの解決策（実装） l 意図が分かり難い実装 l ⽣のクエリが定義 l設定情報が⼀部、ベタ書き l クラスの責任
- 55. 55 問題点ごとの解決策（実装） l 意図が分かり難い実装 l ⽣のクエリが定義 l設定情報が⼀部、ベタ書き l クラスの責任
- 56. 56 意図が分かり難い実装 問題点ごとの解決策（実装） 意図が分かり難い実装 多重継承 class HogeA extendsBaseA implements IBaseA abstract class BaseA extends BaseB implements Ifb abstract class BaseB { //なにもしない } BaseB baseB = (BaseB) hogeA if(baseB instancOf BaseA){ } 意味がわからない
- 57. 57 if(str.equals("success")){ //なにかの処理 if(name != null){ for(条件A&& 条件B){ // なにかの処理 if(条件A || (条件B && 条件C)){ }else if(条件(B) && 条件(B)){ } else { } } } } 意図が分かり難い実装深いネスト 問題点ごとの解決策（実装） 意図が分かり難い実装 読みづらい
- 58. 58 Ø フレームワークに従った標準的な実装 Ø コードレビューの実施による属⼈化防⽌ Øコード品質向上 意図が分かり難い実装（解決策） 問題点ごとの解決策（実装） 意図が分かり難い実装 解決策
- 59. 59 問題点ごとの解決策（実装） l 意図が分かり難い実装 l ⽣のクエリが定義 l設定情報が⼀部、ベタ書き l クラスの責任
- 60. 60 ⽣のクエリが定義 問題点ごとの解決策（実装） // EXAMPLEテーブルのIDで検索 String EXAMPLE_SERCHID_QUERY= “SELECT * FROM EXAMPLE WHERE 〜“; ⽣のクエリが書かれている
- 61.
- 62. 62 問題点ごとの解決策（実装） l 意図が分かり難い実装 l ⽣のクエリが定義 l設定情報が⼀部、ベタ書き l クラスの責任
- 63. 63 設定情報が⼀部、ベタ書き 問題点ごとの解決策（実装） ENV_JA = “値1” ENV_US= “値2” 設定情報がプログラムにベタ書き、 外部ファイル化できていない
- 64.
- 65. 65 問題点ごとの解決策（実装） l 意図が分かり難い実装 l ⽣のクエリが定義 l設定情報が⼀部、ベタ書き l クラスの責任
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.
- 72.
- 73.
- 74. 75 Ø 今回使⽤したのは Ø Junit ØMockito 解決策 問題点ごとの解決策（テスト）
- 75. 76 アジェンダ l お名前.comの紹介 l 流⽤元として渡されたシステムがレガシーだった l問題点ごとの解決策（仕様・実装・テスト） l 結果どうなったのか
- 76. 77 結果どうなったのか l 仕様（ドキュメント化） l 実装（アーキテクチャの採⽤） lテスト（単体テストの改善）
- 77. 78 結果どうなったのか l 仕様（ドキュメント化） l 実装（アーキテクチャの採⽤） lテスト（単体テストの改善）
- 78. 79 Ø ドキュメント化 Ø Wikiにドキュメント Ø仕様が変更になったらUpdateする 仕様（ドキュメント化） 結果どうなったのか • チームで仕様を把握できるようになった • Wikiもメンテナンスが必要である
- 79. 80 結果どうなったのか l 仕様（ドキュメント化） l 実装（アーキテクチャの採⽤） lテスト（単体テストの改善）
- 80.
- 81.
- 82. 83 結果どうなったのか l 仕様（ドキュメント化） l 実装（アーキテクチャの採⽤） lテスト（単体テストの改善）
- 83.
- 84.
- 85. 86 Ø実際にテストできたのは Ø Controller &Service Ø Repository & Entity テスト（単体テストの改善） 結果どうなったのか ⼯数の関係上、 ⼆つのテストしか書けなかった。 残りは結合テストで確認。
- 86.
- 87.
- 88.
- 89.
- 90. 92 ［12/11（⽔）19時］渋⾕フクラス開業記念 GMO Developers Night Date:12/11(wed) 19:30-22:00 URL: https://gmo.connpass.com/event/156321/
- 91.