個人サービスを最速でPHPからGoにリプレイスするためにやったこと・やらなかったこと / Replace from PHP to Go in Indie Development
by
itosho
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
個人サービスを最速で PHPからGoにリプレイスするために やったこと・やらなかったこと PHP Conference 2018 @itosho 1
Slide 2
Slide 2 text
■ 君の名は? 伊藤 翔 @itosho コネヒト株式会社所属 絶賛エンジニア募集中! Supership株式会社から出向中 PHPer兼マネージャー
Slide 3
Slide 3 text
インディー開発が趣味です ※インディー開発=個人でアプリやwebサービスをつくること 詳細は https://itosho.github.io をみてみてください! 3
Slide 4
Slide 4 text
今日はその中の一つを 「最速」でPHPからGoに リプレイスした時のお話 4
Slide 5
Slide 5 text
■ 免責事項 ・PHP下げ↓Go上げ↑ではありません!(どっちも好き) ・Goの話というよりもリプレイスの話がメイン
Slide 6
Slide 6 text
■ 免責事項 ・PHP下げ↓Go上げ↑ではありません!(どっちも好き) ・そもそも今日はGoの話というよりもリプレイスの話 ちなみに一番好きな言語はRubyです(小声)
Slide 7
Slide 7 text
■ リプレイス対象システム ・スマートフォンアプリ向けAPIサーバー ・規模: RESTベースのWebAPIが17本 ・技術スタック: PHP7系, CakePHP3系, MySQL, NGINX
Slide 8
Slide 8 text
何故「最速」でやる必要があるのか? 8
Slide 9
Slide 9 text
インディー開発の最大の敵 9
Slide 10
Slide 10 text
飽きる 10
Slide 11
Slide 11 text
取捨選択が必要 11
Slide 12
Slide 12 text
やらなかったこと 12
Slide 13
Slide 13 text
やらなかったことその① I/Fの抜本的な変更 13
Slide 14
Slide 14 text
■ 誘惑に負けない ・せっかくだから!と色々やりたくなってしまう ・GoだとgRPC, GAEなどなど ・今回は言語のリプレイスのみにフォーカス
Slide 15
Slide 15 text
やらなかったことその② 単体テスト 15
Slide 16
Slide 16 text
■ テストは大事 ・当時Goのテストの知識があまりなかった ・飽きが来るスピード > 単体テストを書くコスト ・単体テスト以外で品質を担保する
Slide 17
Slide 17 text
やったこと 17
Slide 18
Slide 18 text
やったことその① E2Eテスト 18
Slide 19
Slide 19 text
■ やっぱりテストは大事 ・E2E用のスクリプトを作成 ・基本的に既存のAPIと同じだったらOK ・新旧のシステムを同時に起動(ポート別)して、 それぞれに対して同じリクエストを送る テスト スクリプト Go API PHP API JSON JSON レスポンス比較! 同じリクエスト
Slide 20
Slide 20 text
やったことその② 段階リリース 20
Slide 21
Slide 21 text
■ 漸進的に前進していく ・1本APIが出来たらすぐリリースする ・NGINXを利用してリバースプロキシ先を振り分け ・少しずつでも本番環境で稼働させると最後まで頑張れる NGINX PHP API’s Go API’s /users/xxx /users/yyy /contents/xxx /contents/yyy
Slide 22
Slide 22 text
やったことその③ 郷に従う 22
Slide 23
Slide 23 text
■ さっきI/Fを変更しないと言ったがあれは嘘だ ・旧システムの面影が残ってると今後負債になる可能性 ・新システムの郷(Go)に従うことが大切 ・具体的にはDBのデフォルトのカラム名である、 created / modified を created_at / updated_at に変更
Slide 24
Slide 24 text
結果 24
Slide 25
Slide 25 text
■ 最速でリプレイス出来たかもしれない ・3ヶ月弱(ほぼ週末のみ)でリプレイス完了 ・大きな不具合はなし(軽微な不具合: 1件) ・レスポンスタイムが平均120msから平均90msに!
Slide 26
Slide 26 text
■ 最速でリプレイス出来たかもしれない ・3ヶ月弱(ほぼ週末のみ)でリプレイス完了 ・大きな不具合はなし(軽微な不具合: 1件) ・レスポンスタイムが平均120msから平均90msに! 拍手が欲しいです
Slide 27
Slide 27 text
まとめ 27
Slide 28
Slide 28 text
■ 2秒で分かるやったこと・やらなかったこと やったこと ①E2Eテスト ②段階リリース ③郷に従う やらなかったこと ①I/Fの抜本的な変更 ②単体テスト
Slide 29
Slide 29 text
■ インディー開発 × リプレイス作業 = 学び∞ ・取捨選択のセンスが磨ける ・普段の業務でも役に立つ(世にリプレイス案件は多い) ・手段を目的に出来る(学びたい技術を好きに使える) ・1つシステムをつくれば無限にリプレイス出来る!
Slide 30
Slide 30 text
皆さんもインディー開発しましょう! 30
Slide 31
Slide 31 text
31