スタートアップと大規模サイトの JavaScript 柳澤 直
リクルートホールディングス (住まいカンパニー出向) 新卒2年目 (23さい) 柳澤 直 (やなぎさわ なお) アプリケーションエンジニア (Webフロント◎、サーバー○、インフラ△) 2012/03: 人材DBベンチャー(アルバイト) クビに...
JS Conf 2016 JSのためにアイスランドへ出張
JSのスター数 115 / 201 結構JSのことは好きかもしれない、、 ///
大規模 ※ 現時点でのやなぎさわの主観です ※ だいたいです ※ 勝手にロゴ使ってすいません、ダメだったら連絡くださいw ※ 他にもいくつかありますが一般公開されてるサイトということで 急成長ベンチャー0 -> 1 ソースを読んだことがあるサイ...
注意 ・所属組織等は関係なく全部僕個人の考え方です。 ・まだまだ若造です。 経験はそれなりにあるつもりですが会社でも問題児扱いさ れたりして、まだまだ足りない視点がいくつかあるっぽいのでお気づきの際はこ っそり教えてください笑 ・技術とビジネス...
0 -> 1 フェーズで感じたこと Wordpressから自社システムへの移行案件 ・0 -> 1 なので少ない工数でのビジネス的仮説検証がメイン ・お金のことをもっと身近にというコンセプトのお金に関するメディア ※ 現在絶賛開発中でWordp...
ジョイン時のアーキテクチャ 本体、API Rails 一般ユーザー 管理画面 フロント React API ライター
MVPのプロダクト のためにAPI作る 必要性って？ 週１、２ヶ月 という短納期 管理画面そんなに かっこいい必要な い。。 React Redux 触るファイル多いし やっぱ面倒かも、、
変更後のアーキテクチャ 本体、管理画面 Rails 一般ユーザー ライター
・仮説を検証するだけのMVPにマイクロサービス的な高尚な ものは不要なのでは ・Reactよりどう考えてもjQueryの方が簡単。設定とか諸々 あるし工数はReact等を採用すると上がる ・0 -> 1のフェーズの場合はjQueryでいいじゃん
エンジニア的に楽しい（新しい技術使いたい的な）と ビジネス要求は時に異なる 最初ノリで作ると後で本当に後悔するから技術選定は たとえ副業でもちゃんとやる、、、
大規模急成長ベンチャー0 -> 1 とはいえ、、 多分ここら辺でお金を投入して一気にスケールさせるタイミングとかくる
とはいえ、、、 ・チャットワークにみるScala再構築事件とか、、 ・ベンチャーで数万UUくらいの規模のサイトだったらそんなに機能もないだろう し、シリーズA, Bくらいの調達のタイミングで丸っと作り直しとかあり？ ・マイクロサービスアーキテク...
大規模プロダクトのJSで思ったこと ・世界１の売り上げの不動産検索サイト ・住む場所を探している人に情報を提供している不動産メディア ※ 開発に携わったことがあるのはPCサイトの賃貸
ソースを読む人が異常に多い (実装者以外や他のチームの人も参照したりする)
Linterやformatterをフル活用 コードレビューもかなり入念にやる
共通部分がサワレナイ、、、 -> 影響範囲が大きすぎる
E2Eテストなど、なんらかの方法でコンバージョン までの導線を自動テストする 何がどこにあるのかすぐわかるようになっておく → 影響範囲の把握 → フォルダ構成がかなり重要
E2Eテスト Nightwatch.jsWebdriverIO JSでかける、、、 ///
テストケースの設計 -> 何をテストするのか とはいえE2Eむずい
何をテストするのか リスク E2Eの コスト 手動テスト コスト ログ 高 低 高 検索機能 中 低 低 ... ... ... .. リスクが高くて E2Eテストのコストが低くて 手動テストのコストが高いもの からやる
CIに組み込むのが大変 → ブラウザ動かすの大変 とはいえE2Eむずい
DockerHubにあるWebdriverIOのコンテナ構成 E2Eコンテナ Hubコンテナ ブラウザコンテナ (Firefox) ブラウザコンテナ (Chrome) Webサーバー ブラウザコンテナ (...) コンテナ多い、、、 リソース足...
当たり前だけど大規模サイトは難易度が高いこと を要求されることが多い 大規模サイトのJSは慎重に開発をする必要がある → 当然スタートアップとは違った開発になる
まとめ ・0 → 1の段階のプロダクトは凝ったことしないで仮説検証のために本当に必要 最低限の技術で最小工数の実装 ・シリーズA, Bらへんで開発リソースに余裕が出てきたら徐々に新しい技術を検 討すると技術を生かしてプロダクトがグロースできそう...
Upcoming SlideShare
Loading in …5
×

スタートアップと大規模サイトの JavaScript

2,304 views

Published on

スタートアップと大規模サイトの最適なアーキテクチャの違いなどビジネス的な視点から見たJSについて

Published in: Software
0 Comments
0 Likes
Statistics
Notes
no profile picture user

  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,304
On SlideShare
0
From Embeds
0
Number of Embeds
224
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • エンジニアとして楽しいということとビジネス要求って違うんだなと実感
    オーバースペックな技術を使ってもしゃーない
    -> css in jsとかクラス名ハッシュ化されてかなり嬉しいけどこの段階で命名かぶるとか滅多にないしそんなにメリットない 早い方がいい
  • やりすぎてgulpが3000行になった、、　やりすぎない程度にメタプログラミングしましょうw
  • 逆に言うとスタートアップとかだったら正直SRAとかどうでもいいから機能追加しまくった方がいい
  • 逆に言うとスタートアップとかだったら正直SRAとかどうでもいいから機能追加しまくった方がいい

    • スタートアップと大規模サイトの JavaScript

    1. 1. スタートアップと大規模サイトの JavaScript 柳澤 直
    2. 2. リクルートホールディングス (住まいカンパニー出向) 新卒2年目 (23さい) 柳澤 直 (やなぎさわ なお) アプリケーションエンジニア (Webフロント◎、サーバー○、インフラ△) 2012/03: 人材DBベンチャー(アルバイト) クビになる 2013/05: ソーシャルゲーム会社にて3Dランゲーム開発(アルバイト) 2014/10: 知り合いと起業 http://www.ineeza.com/ 2015/10: Youtuber向けポータルサイトUUUM Network開発 2015/05: フリーランス開業 海外スポーツ賭博自動化システムなどグレー なシステムの受託開発 2015/08: クラウドサービス口コミサイトBoxil開発 2016/02: 自動ネイティブアド生成第三者配信タグシステムの開発 2016/04: Recruit Holdings入社 RSC配属 SUUMOの開発 短期インターンとか含め関わった会社、プロダクト 好きな or 気になってる技 術
    3. 3. JS Conf 2016 JSのためにアイスランドへ出張
    4. 4. JSのスター数 115 / 201 結構JSのことは好きかもしれない、、 ///
    5. 5. 大規模 ※ 現時点でのやなぎさわの主観です ※ だいたいです ※ 勝手にロゴ使ってすいません、ダメだったら連絡くださいw ※ 他にもいくつかありますが一般公開されてるサイトということで 急成長ベンチャー0 -> 1 ソースを読んだことがあるサイトのプロット
    6. 6. 注意 ・所属組織等は関係なく全部僕個人の考え方です。 ・まだまだ若造です。 経験はそれなりにあるつもりですが会社でも問題児扱いさ れたりして、まだまだ足りない視点がいくつかあるっぽいのでお気づきの際はこ っそり教えてください笑 ・技術とビジネス両方好きで織り交ぜて話してます。純粋に技術の話を聞きたか った方はすみません。 ・JSって書いてありますがフロントエンドの話題が多いです。フロントに興味の ない方はすみません。
    7. 7. 0 -> 1 フェーズで感じたこと Wordpressから自社システムへの移行案件 ・0 -> 1 なので少ない工数でのビジネス的仮説検証がメイン ・お金のことをもっと身近にというコンセプトのお金に関するメディア ※ 現在絶賛開発中でWordpressから新システムへ移行中
    8. 8. ジョイン時のアーキテクチャ 本体、API Rails 一般ユーザー 管理画面 フロント React API ライター
    9. 9. MVPのプロダクト のためにAPI作る 必要性って？ 週１、２ヶ月 という短納期 管理画面そんなに かっこいい必要な い。。 React Redux 触るファイル多いし やっぱ面倒かも、、
    10. 10. 変更後のアーキテクチャ 本体、管理画面 Rails 一般ユーザー ライター
    11. 11. ・仮説を検証するだけのMVPにマイクロサービス的な高尚な ものは不要なのでは ・Reactよりどう考えてもjQueryの方が簡単。設定とか諸々 あるし工数はReact等を採用すると上がる ・0 -> 1のフェーズの場合はjQueryでいいじゃん
    12. 12. エンジニア的に楽しい（新しい技術使いたい的な）と ビジネス要求は時に異なる 最初ノリで作ると後で本当に後悔するから技術選定は たとえ副業でもちゃんとやる、、、
    13. 13. 大規模急成長ベンチャー0 -> 1 とはいえ、、 多分ここら辺でお金を投入して一気にスケールさせるタイミングとかくる
    14. 14. とはいえ、、、 ・チャットワークにみるScala再構築事件とか、、 ・ベンチャーで数万UUくらいの規模のサイトだったらそんなに機能もないだろう し、シリーズA, Bくらいの調達のタイミングで丸っと作り直しとかあり？ ・マイクロサービスアーキテクチャはシリーズA, Bくらいのタイミングで検討し 始めるのがいいんじゃなかろうか
    15. 15. 大規模プロダクトのJSで思ったこと ・世界１の売り上げの不動産検索サイト ・住む場所を探している人に情報を提供している不動産メディア ※ 開発に携わったことがあるのはPCサイトの賃貸
    16. 16. ソースを読む人が異常に多い (実装者以外や他のチームの人も参照したりする)
    17. 17. Linterやformatterをフル活用 コードレビューもかなり入念にやる
    18. 18. 共通部分がサワレナイ、、、 -> 影響範囲が大きすぎる
    19. 19. E2Eテストなど、なんらかの方法でコンバージョン までの導線を自動テストする 何がどこにあるのかすぐわかるようになっておく → 影響範囲の把握 → フォルダ構成がかなり重要
    20. 20. E2Eテスト Nightwatch.jsWebdriverIO JSでかける、、、 ///
    21. 21. テストケースの設計 -> 何をテストするのか とはいえE2Eむずい
    22. 22. 何をテストするのか リスク E2Eの コスト 手動テスト コスト ログ 高 低 高 検索機能 中 低 低 ... ... ... .. リスクが高くて E2Eテストのコストが低くて 手動テストのコストが高いもの からやる
    23. 23. CIに組み込むのが大変 → ブラウザ動かすの大変 とはいえE2Eむずい
    24. 24. DockerHubにあるWebdriverIOのコンテナ構成 E2Eコンテナ Hubコンテナ ブラウザコンテナ (Firefox) ブラウザコンテナ (Chrome) Webサーバー ブラウザコンテナ (...) コンテナ多い、、、 リソース足りなくて落ちたりする、、、 参考 https://hub.docker.com/r/casperlai/docker- webdriverio/
    25. 25. 当たり前だけど大規模サイトは難易度が高いこと を要求されることが多い 大規模サイトのJSは慎重に開発をする必要がある → 当然スタートアップとは違った開発になる
    26. 26. まとめ ・0 → 1の段階のプロダクトは凝ったことしないで仮説検証のために本当に必要 最低限の技術で最小工数の実装 ・シリーズA, Bらへんで開発リソースに余裕が出てきたら徐々に新しい技術を検 討すると技術を生かしてプロダクトがグロースできそう ・大規模なプロダクトは影響範囲を把握しやすくしておくことがかなり大事。ま たデグレの検知をする仕組みがかなりバリューを発揮しそう

    ×