#jjug_ccc #ccc_f1 広告システム刷新の舞台裏 - PHPからJavaに変えてみました
•
3 j'aime•2,573 vues
JJUG CCC 2016 Springの以下のセッションで発表した際の資料です。 http://www.java-users.jp/?page_id=2396#F-1
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à #jjug_ccc #ccc_f1 広告システム刷新の舞台裏 - PHPからJavaに変えてみました
Similaire à #jjug_ccc #ccc_f1 広告システム刷新の舞台裏 - PHPからJavaに変えてみました (20)
Plus de Yahoo!デベロッパーネットワーク
Plus de Yahoo!デベロッパーネットワーク (20)
#jjug_ccc #ccc_f1 広告システム刷新の舞台裏 - PHPからJavaに変えてみました
- 2. 自己紹介 YJ入社前 Sierな世界の住人でした。 受託案件をこなす業務システム開発 のエンジニア。 YJ入社後 BtoBなWebサービス開発へ。 Web系と言いつつエンタープライズ 系っぽいシステムの開発に携わる。 • 名前：森下大介 • 年齢：41 • 職歴：2011年にYJに中途入社 • 言語：C/C++/Java/PHP/Node.js
- 5. 5P本日の内容 • バックグラウンド • 取り組んだこと • やったことその０：体制づくり • やったことその１：プログラミング言語を変える • やったことその２：テストができるアーキテクチャに • やったことその３：テスト向けDSL (Spock) • やったことその４：CI/CD, 静的解析 • やったことその５：インタフェース定義言語 • 振り返っての所感
- 6. バックグラウンド
- 7. 7P入社当時のシステムの特徴：利用言語、道具 • 言語： – PHPメイン – たまにバッチ系にPerl – 一部のライブラリはC + PHP Extension • 道具： – ほとんどの人がvim, emacs等を使用 – IDEはほとんど使われていない – テストはほぼブラックボックステストのみ
- 8. 8P入社当時のシステムの特徴：システム構成 • システム構成 – FE/BEは明確に分離、BEはWebAPI化 – マイクロサービスほどでは無いが分散システム化 • このおかげで・・・ – 機能ごとにスケールができた – 機能ごとにアップデートができた
- 12. 12P例２：結合がつらい なかなかつながらない・・・ 特にAPIIFドキュメントが - 手書きだし、書き方が統一されてない - 書き手と読み手でお互いに認識がズレてる - ドキュメント通りに実装されない
- 14. 14P何が起きていたのか？ 考察１：「大規模」で「複雑」に。 サービスが育った結果・・・ - 道具の助け無しで - 人手と記憶と努力と根性で - がんばれる規模をこえている
- 15. 15P何が起きていたのか？ 考察２：道具とやり方が合ってない ちゃんとデータを扱いたいのに - 型宣言が無い - コンパイラに頼れない - 単体テストを仕掛けられない
- 17. 17P何が起きていたのか？ 考察４：チーム同士が良くも悪くも独立 分散システム化によって・・・ – 担当機能毎にチームの独立性が強い – 技術／知識／事例の共有がされない – 助け合う、融通しあう意識が弱い
- 18. 18P当時のエンジニアの心中 このままだとヤバイのは薄々感じてる。 感じてるけど・・・ – 目の前の巨大システムは売上を現実にあげている – ビジネス拡張のための案件はひっきりなし – 変えるには根本的な手当が必要・・・ – どーすりゃいいのこれ？
- 20. 20P目指したこと システム刷新は「結果」 • 自分の変化がアウトプットを変える。 • でも結果を出すことも重要。 • 結果で証明する。 変わるべきは「自分達」 • ３倍早く • やりやすく • 確実に 開発できる強いエンジニアになること。 「３倍早い開発スピード」
- 21. 取り組んだこと
- 22. やったことその０ 体制をつくる
- 33. 33Pプログラミング言語を変える これで得られたもの • コンパイルできる • 厳密な型定義ができる • 優れたメモリ管理(GC) • 実行時最適化(JIT) • デバッガ、解析ツール 副次的なものとして • 豊富なOSS • 統合開発環境の活用 • 優れた静的解析ツール
- 35. 35Pテストできるアーキテクチャに 「テストできない」とはどういう状況？ • 動かす準備が大変 • CI/CDの中で実行できない • ブラックボックステストになる • etc…
- 37. 37Pモノリシックなコードの例 これらは一見するとA, B, Cというクラスに分 割されているように見えるが・・・ public class A { public void x() { B b = new B(); b.y(); } } public class B { public void y() { C c = new C(); c.z(); } } public class C { public void z() { DB操作とか } }
- 38. 38Pこれにテストケースを仕掛けてみると・・・ public class A { public void x() { B b = new B(); b.y(); } } public class B { public void y() { C c = new C(); c.z(); } } public class C { public void z() { DB操作とか } } TestCaseA (A, B, Cの複合テスト) Class AにテストケースつくるとB, Cも必ず くっついて来て単独テストにならない。 TestCaseB (BとCの複合テスト) TestCaseC (これはまだ単独)
- 39. 39Pテストできるアーキテクチャに ポイントは、 「呼び出し先の実装クラスを自分でnewしていること」 これだとクラス同士が密結合する。 この状態で無理にテストケースを仕掛けたとしても、 • 実行条件が増える • バリエーションが掛け算で増加 • メンテ、問題箇所の特定が困難
- 41. 41PDI(JavaでSpringFramworkの場合) public class Aimpl implements A { @Autowired private B b; public void x() { b.y(); } } public class Bimpl implments B { @Autowired private C c; public void y() { c.z(); } } public class Cimpl implements C { public void z() { DB操作とか } } 実装クラスとインタフェースを分離、コール先のインタフェースのみ認識 し、実装インスタンス(Dependency)は外部から注入(Injection)。
- 42. 42Pこれにテストケースを仕掛けてみると・・・ public class Aimpl implements A { @Autowired private B b; public void x() { b.y(); } } 今まではA単独のテストができなかったが、依存するBをモック化するこ とでテストしたい処理だけに対して確認を行えるようになる。 class TestCaseA { def testA() { def a = new Aimpl() //モック注入 a.b = Mock(B.class) //テスト実行、assert a.x() } }
- 47. 47Pテスト向けDSLの採用 final SampleDao dao = context.mock(SampleDao.class); final List<Sample> expected = Arrays.asList(new Sample()); Expectations mockConfig = new Expectations() { { oneOf(dao).findBySelector(with(new TypeSafeMatcherSimple<SampleSelector>() { @Override protected boolean matchesSafely(SampleSelector item) { assertEquals(ids[0], item.getIds().get(0)); assertEquals(ids[1], item.getIds().get(1)); assertEquals(userStatuses[0], item.getUserStatuses().get(0)); return true; } })); will(returnValue(expected)); } }; context.checking(mockConfig); JMockを利用した テストコードの一部。 つらくないですか？
- 50. 50Pテスト向けDSLの採用 Junitの上に構築されたものだが、記述言語は、JVM言語の「Groovy」 その上にテストを記述するためのDSL(ドメイン固有言語)が構築されている。 主な機能としては • テスト実行 • BDD的なテスト記述文法 • 柔軟なモック／スタブ生成 • テストパターンデータの記述 特に良いのが、Groovy自体がJava よりも色々省略して書けること。 テストコードはJava言語では書き たくない。
- 51. 51PSpockによるテストコード例 class SampleSTest extends Specification { def “データ更新テスト(#testname)”() { given: def service= new SampleServiceImpl() def dao = Mock(SampleDao.class) 1 * dao.update(_) >> response serivce.dao = dao when: def result = service.update(request) then: assert result == response where: testname | request | response “パターンA” | “foo1” | “bar1” “パターンB” | “foo2” | “bar2” } } テストケースで以下のようなブロックに区 切ってコードを書ける。 • givenがテスト対象のセットアップ • whenがテスト対象の実行 • thenがテスト結果の確認 • whereがテストデータ Mockの生成とその挙動も全てテストコード の中で記述できるのが良いところ。 テストデータを複数件かけばその件数分で 全体をループして実行してくれる。 Groovyの型推論や省略記法も楽で助かる。
- 54. 54PCI/CD, 静的解析 CI/CDの中では以下の様なテストや解析を実施 • SpockによるSテストケース実行 • Cloverによる詳細なカバレッジ計測 • Coverity QualityAdvisorによるコード解析 • Coverity TestAdvisorによるテスト解析 • Frisbyを使ったWebAPIのSmokeテスト
- 58. 58Pインタフェース定義言語 APIを「提供」する側では、 • 人がAPIIFを考えて • それを頑張ってドキュメントとして書く。 • それを元に実装する。 APIを「利用」する側では、 • 人がAPIIFドキュメントを読んで理解して、 • そのAPIを利用する処理を実装する。
- 62. 62Pインタフェース定義言語 当初はOSSの以下あたりを使えないかと検証したが、 • Googole ProtocolBuffer • Apache Thrift 以下の理由から断念 • 入力値バリデーションが表現できない • ドキュメントが生成できない
- 63. 63Pインタフェース定義言語 一から以下を行いました。 • 定義言語自体の文法設計 • コンパイラ開発 • Javaコード・ドキュメントジェネレータ開発 • ドキュメント表示サーバー開発 • 入力値バリデーションエンジン開発
- 68. 68Pインタフェース定義言語 IDLから生成されるJavaコードは以下。 • Context (データ操作のコンテキスト情報) • Entity (Pojoデータオブジェクト) • Enum (Enum系項目の値定義) • Error (エラーコード一覧) • JAX-RSインタフェース(APIエンドポイント)
- 69. 69Pインタフェース定義言語 //IDLファイルの例 namespace entity sample.entity; entity Sample { field Long id { valid min 1; valid max 100; } field String name { valid max 100; valid pattern ”^[a-zA-Z0-9¥¥-_]+$”; } } //生成Javaコードの例 package sample.entity; public class Sample implements Entity { @CheckNumber(min=1, max=100) private Long id; public void setId(Long id) { …. } public Long getId() { …. } @CheckString(max=100, pattern=“^[a-zA-Z0-9¥¥-_]+$”) public String name; public void setName(String name) { …. } public String getName() { …. } } IDLコンパイラで Javaコード生成 IDLで記述したデータ構造(entity)のJavaコード生成例。 この場合はバリデーション用アノテーション付きのPojoが生成される。
- 70. 70Pインタフェース定義言語 //IDLファイルの例 namespace service sample.jaxrs; service SampleService { path /SampleService; operation Response add(Sample sample); operation Response set(Sample sample); } //生成Javaコードの例 package sample.jaxrs; @Path(“/SampleService) public interface SampleService { @Path(“/add”) @POST public Response add(Sample sample); @Path(“/set”) @POST public Response set(Sample sample); } IDLコンパイラで Javaコード生成 IDLで記述したWebAPIエンドポイントのJavaコード生成例。 この場合はJAX-RSのアノテーション付きインタフェースが生成される。
- 71. 71Pインタフェース定義言語
- 72. 72Pインタフェース定義言語
- 73. 73Pインタフェース定義言語
- 74. システム刷新を 振り返っての所感
- 75. 問題検出はできるだけ前工程に。
- 77. 77P問題検出はできるだけ前工程に 開発者の手元を離れる直前まで、やれる事をやる。 • IFを結合前に安定させられるIDL • コンパイルと型宣言 • テストを書いて手元でもCI/CDでも実行 • Coverityの静的解析。
- 78. テストを阻む要因を潰す
- 86. 部門長サポートと仲間が大事