Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

開発速度を支える技術 / The Techniques for Keeping The Dev...

開発速度を支える技術 / The Techniques for Keeping The Development Speed

Hiroki Nakashima

October 07, 2018
Tweet

More Decks by Hiroki Nakashima

Other Decks in Programming

Transcript

  1. 大学院理工学研究科卒業 大学院では、初期の Ethereum を触ってました 2017年エンジニア新卒1期生としてfreee株式会社に入社 現在は、エンジニアとして、会計フリーをメインに開発 Web フロント、Ruby on Rails

    のサーバサイドの開発をはじめ、Golang、 Kubernetes を使ったプロダクトのマイクロサービス化にも挑戦している。 趣味は 仮想通貨(概念が好き)、Pokemon Go、あと酔うけどVR Hiroki NAKASHIMA 中島 啓貴 freee株式会社 プロダクト開発 2
  2. 6 6 会計 請求書 経費精算 債務管理 債権管理 人事労務  バックオフィス業務の一番の無駄は、様々なツー ルに同じような情報を繰り返し入力する転記作業

    です。時間がかかる上、作業ミスの温床にもなって いました。  会計freeeでは請求書作成や債権債務管理など 経理業務に必要な機能を標準搭載。日々の経理 で入力した情報を自動で帳簿に反映し、転記作業 が極力不要な体制を実現します。 会計と経理を一体化 転記作業を排除し、管理が簡単に 6
  3. 11 大事にしている価値基準 本質的(マジ)で価値ある ユーザーにとって本質的な 価値があると自信を持って 言えることをする。 理想ドリブン 理想から考える。現在の リソースやスキルにとらわれず 挑戦しつづける。

    アウトプット→思考 まず、アウトプットする。 そして考え、改善する Hack Everything 取り組んでいることや持っている リソースの性質を深く理解する。 その上で枠を超えて発想する。 あえて、共有する 人とチームを知る。 知られるように共有する。 オープンにフィードバックし あうことで一緒に成長する。
  4. 19 Github を使った基本的な開発フロー Pull Request (PR) Develop Pull Request できました!

    レビューお願いします。 レビューします! • 根拠と実装の正しさ • 最適なコードなのか • 動作 などを確認、コメントする。 最終的に、問題が状態で Develop にマージする 開発者 レビュアー 開発者はコメントをもとに コミットを重ねる PR が提出されマージされる = 新しい機能が追加された
  5. 24 会計フリーの開発イメージ ├── app │ ├── assets │ ├── controllers

    │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets 静的な HTML や、ロジックは、 Rails で動作 機能開発単位でチーム開発、フロントとサーバに実装を加える API リクエストへのリクエスト Web のブラウザ上での振る舞い
  6. • SCSS 25 会計フリーの開発イメージ ├── app │ ├── assets │

    ├── controllers │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets • ES6 (ECMAScrip6) • JSX (React) • CoffeeScript モダンな JavaScript の規格や、DSL で記述
  7. 26 会計フリーの開発イメージ ├── app │ ├── assets │ ├── controllers

    │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets DSL は実行できないし、モダンな JavaScript は動作が保証されていない • ES6 (ECMAScrip6) caniuse.com
  8. 27 会計フリーの開発イメージ ├── app │ ├── assets │ ├── controllers

    │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets Webpack JavaScript や、CSS は 古いブラウザでも動作するよう トランスパイルし配信 ブラウザでは、動作が保証されていない nodejs のパッケージ
  9. 28 会計フリーの開発イメージ ├── app │ ├── assets │ ├── controllers

    │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets 超巨大なコードベース "*.rb" ファイル 数十万 行 "*.js" ファイル 数十万 行 "*.coffee" ファイル 数十万 行 (レガシーコード)
  10. 29 会計フリーに変更を入れるエンジニアのイメージ 新規作成などの データ入力 申告書類作成の データ出力 日常的な会計 処理 申告のチームの変更範囲 設立のチームの変更範囲

    会計のチームの変更範囲 メインに変更を加えている会計チーム以外も 機能開発単位で会計フリーには変更のPRがバシバシはいる環境 連携の関係で、変更に依存が生じる
  11. 30 ヘッドカウントが増えて起こっていたトラブル • キャッチアップコストの増加 ◦ 超複雑な開発環境の構築 ▪ 新しく入った人が動かすまで2日ぐらいかかっていた • コミュニケーションコストの増加

    ◦ レビューのペース低下、PR のマージまでのコメントの往復が増える ▪ コーディング規約・設計思想など基本的なミスの指摘 • 入り乱れるドメイン知識 ▪ すでに実装が存在するが再実装してしまう ▪ 他の機能への副作用に気が付かない実装してしまう 実際に生産性を上げるために行った取り組みを紹介する 人を増やしてもなかなか開発効率が上がらない状況
  12. Ansible による開発マシンの環境構築 34 Playbook Ansible 本来の Ansible の ユースケース サービスサーバ

    サーバの構成 を定義 開発マシン 最低限開発可能な環境構築を自動化 開発環境の構成 を定義
  13. それぞれのアプリケーションの実行環境が異なる 37 管理 App A 管理 App B v a.a.a

    2.x.x v b.b.b 2.z.z 2.y.y アプリケーションの実行環境がそれぞればらばらで バージョンを切り替えられるような環境を構築する必要がある
  14. CI を用いた Docker イメージの更新 38 管理 App A 管理 App

    B 依存アプリケーションの最新のイメージがECRに存在する状態を実現 CodeBuild Elastic Container Registory 管理 App A 管理 App B CI でソースコードから Docker Image を作成 最新のイメージとして保存
  15. Docker による実行環境の仮想化 39 管理 App A 管理 App B v

    a.a.a 2.x.x docker compose で依存関係とミドルウェアを定義
  16. Docker による実行環境の仮想化 40 管理 App A 管理 App B v

    a.a.a 2.x.x docker-compose 実行で最新のイメージが pull されそれぞれ副作用なく動作 Elastic Container Registory
  17. 42 コードの品質が下がりレビューの往復が増える Develop 開発ブランチの切り替え、動作確認、スイッチコンテキストなど 単純な作業時間以上に効率が落ちる Merge コメント 1. コメント確認する 2.

    ブランチを切り替える 3. コメントに対応する 4. 動作確認 5. レビューを依頼する 1. 依頼を受ける 2. ブランチを切り替える 3. コード確認 4. 動作確認 5. コメント
  18. ESlint は導入していた 44 precommit hook commit push precommit がうまく動作しない、ルールがうまく検知しないという問題 適切でなければ

    コミットさせない 適切でなければ マージさせない 設定が変更が降り積もり ルールの全貌が 把握できない 引っ掛けているはずなのに 何故かすり抜ける CI で検知される
  19. 47 会計フリーの開発イメージ ├── app │ ├── assets │ ├── controllers

    │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets 静的な HTML や、ロジックは、 Rails で動作 機能開発単位でチーム開発、フロントとサーバに実装を加える API リクエストへのリクエスト Web のブラウザ上での振る舞い
  20. 複数の機能がサービスが混在 48 モデルA モデルB モデルD モデルE モデルC サービス1 サービス2 Ruby

    on Rails のモデルの振る舞いがサービスと強依存 デグレの発生・影響範囲の見積もりの難易度が指数関数的に増加 モデルが数百個存在 API も数百個存在 API 中で複数のサービス が実行される場合もある
  21. のドメインを切り出した マイクロサービス ドメインを切り出し、単機能のマイクロサービスへ 49 モデルA モデルB モデルD モデルE モデルC サービス1

    サービス2 マイクロサービス サービス クライアント ドメインの疎結合により影響範囲の分離 今まさにプロジェクトとして動いている状況でまだまだ効果は未知数 インターフェイスを明確化