mixiの大規模案件の話

Yokohama.pm #8

2011/11/18

自己紹介

自己紹介

• 名前：星野　将（ホシノ　マサル）

自己紹介

• 名前：星野　将（ホシノ　マサル）
• id ：masartz（マサルツ）

自己紹介

• 名前：星野　将（ホシノ　マサル）
• id ：masartz（マサルツ）
• 所属：mixi, Inc.

自己紹介

• 名前：星野　将（ホシノ　マサル）
• id ：masartz（マサルツ）
• 所属：mixi, Inc.
• 会社ではLT部に所属してます

自己紹介

• 名前：星野　将（ホシノ　マサル）
• id ：masartz（マサルツ）
• 所属：mixi, Inc.
• 会社ではLT部に所属してます
• 育ちは横浜です

自己紹介

• 名前：星野　将（ホシノ　マサル）
• id ：masartz（マサルツ）
• 所属：mixi, Inc.
• 会社ではLT部に所属してます
• 育ちは横浜です
• 横浜ベイスターズをよろしくお願いします > DeNAさん

自己紹介

• 名前：星野　将（ホシノ　マサル）
• id ：masartz（マサルツ）
• 所属：mixi, Inc.
• 会社ではLT部に所属してます
• 育ちは横浜です
• 横浜ベイスターズをよろしくお願いします > DeNAさん
• Yokohama.pmは全参加

自己紹介

• 名前：星野　将（ホシノ　マサル）
• id ：masartz（マサルツ）
• 所属：mixi, Inc.
• 会社ではLT部に所属してます
• 育ちは横浜です
• 横浜ベイスターズをよろしくお願いします > DeNAさん
• Yokohama.pmは全参加
• スピーカー2回(#3,#4)

自己紹介

• 名前：星野　将（ホシノ　マサル）
• id ：masartz（マサルツ）
• 所属：mixi, Inc.
• 会社ではLT部に所属してます
• 育ちは横浜です
• 横浜ベイスターズをよろしくお願いします > DeNAさん
• Yokohama.pmは全参加
• スピーカー2回(#3,#4)
• 飲み会幹事も2回(#5,#7)

自己紹介

• 名前：星野　将（ホシノ　マサル）
• id ：masartz（マサルツ）
• 所属：mixi, Inc.
• 会社ではLT部に所属してます
• 育ちは横浜です
• 横浜ベイスターズをよろしくお願いします > DeNAさん
• Yokohama.pmは全参加
• スピーカー2回(#3,#4)
• 飲み会幹事も2回(#5,#7)
• あやうく飲み会要員になる所だったので、今日は頑張って喋ります

Agenda

• mixiの大規模案件とは
• 名前空間、モジュール設計
• 単体テスト
• CI(Jenkins)
• プロジェクトを通じて個人的な振り返り
• まとめ

mixiの大規模案件とは

mixiの大規模案件とは

• mixiページ作った時の話です

mixiの大規模案件とは

• mixiページ作った時の話です
• http://alpha.mixi.co.jp/blog/?p=3712

mixiの大規模案件とは

• mixiページ作った時の話です
• http://alpha.mixi.co.jp/blog/?p=3712
• 弊社の中でも比較的大きなプロジェクトでした

名前空間、モジュール設計

名前空間、モジュール設計

• ひとつのリポジトリで世界が構成されている場合

名前空間、モジュール設計

• ひとつのリポジトリで世界が構成されている場合
• 名前空間の衝突はリアルに気をつけるべき問題

名前空間、モジュール設計

• ひとつのリポジトリで世界が構成されている場合
• 名前空間の衝突はリアルに気をつけるべき問題
• 命名規則もトップレベルはサービスを表現できるように

名前空間、モジュール設計

• ひとつのリポジトリで世界が構成されている場合
• 名前空間の衝突はリアルに気をつけるべき問題
• 命名規則もトップレベルはサービスを表現できるように
• Mixi::Page? Mixi::Pages? Mixi::Town::Page?

名前空間、モジュール設計

• ひとつのリポジトリで世界が構成されている場合
• 名前空間の衝突はリアルに気をつけるべき問題
• 命名規則もトップレベルはサービスを表現できるように
• Mixi::Page? Mixi::Pages? Mixi::Town::Page?
• 配下の構成は周りと整合性があるように

名前空間、モジュール設計

• ひとつのリポジトリで世界が構成されている場合
• 名前空間の衝突はリアルに気をつけるべき問題
• 命名規則もトップレベルはサービスを表現できるように
• Mixi::Page? Mixi::Pages? Mixi::Town::Page?
• 配下の構成は周りと整合性があるように
• Entry.pm? Model.pm? Object.pm?

名前空間、モジュール設計

• ひとつのリポジトリで世界が構成されている場合
• 名前空間の衝突はリアルに気をつけるべき問題
• 命名規則もトップレベルはサービスを表現できるように
• Mixi::Page? Mixi::Pages? Mixi::Town::Page?
• 配下の構成は周りと整合性があるように
• Entry.pm? Model.pm? Object.pm?
• 認識合わせとタスク分担のために結構ガッチリ決めた

名前空間、モジュール設計

名前空間、モジュール設計

• そんなんやっても大体は仕様追加／変更で思い通りならない

名前空間、モジュール設計

• そんなんやっても大体は仕様追加／変更で思い通りならない
• とりあえずでつけた名前でそのまま進んだり

名前空間、モジュール設計

• そんなんやっても大体は仕様追加／変更で思い通りならない
• とりあえずでつけた名前でそのまま進んだり
• 変更しようと思えば出来るけど、大抵そのまま

名前空間、モジュール設計

• そんなんやっても大体は仕様追加／変更で思い通りならない
• とりあえずでつけた名前でそのまま進んだり
• 変更しようと思えば出来るけど、大抵そのまま
• この辺踏み切り方がわからない

名前空間、モジュール設計

• そんなんやっても大体は仕様追加／変更で思い通りならない
• とりあえずでつけた名前でそのまま進んだり
• 変更しようと思えば出来るけど、大抵そのまま
• この辺踏み切り方がわからない
• 今回の教訓としては「最初にガッチリ決めるもんじゃない」

単体テスト

単体テスト

• レイヤごとに適切なテストがある

単体テスト

• レイヤごとに適切なテストがある
• 今回はController/Model/DB-Access それぞれで書き分けた && 方針決めた

単体テスト

• レイヤごとに適切なテストがある
• 今回はController/Model/DB-Access それぞれで書き分けた && 方針決めた
• 開発人数も多かったので、誰の修正がどこで影響するか読みづらい

単体テスト

• レイヤごとに適切なテストがある
• 今回はController/Model/DB-Access それぞれで書き分けた && 方針決めた
• 開発人数も多かったので、誰の修正がどこで影響するか読みづらい
• テストがより大事になる

単体テスト

• レイヤごとに適切なテストがある
• 今回はController/Model/DB-Access それぞれで書き分けた && 方針決めた
• 開発人数も多かったので、誰の修正がどこで影響するか読みづらい
• テストがより大事になる
• 個々人によるテスト精度のムラを減らしたかった

単体テスト

単体テスト

• DB-Accessクラスのテスト

単体テスト

• DB-Accessクラスのテスト
• DBとの接続
• SQLを直で書いてます

単体テスト

• DB-Accessクラスのテスト
• DBとの接続
• SQLを直で書いてます
• アイコンきもい人でもORM使ってないですよ！

単体テスト

• DB-Accessクラスのテスト
• DBとの接続
• SQLを直で書いてます
• アイコンきもい人でもORM使ってないですよ！
• hashref(のarrayref)の生なデータをやりくりするので、ここを固く書いた

単体テスト

単体テスト

• select系はis_deeplyで取得結果全体チェック

単体テスト

• select系はis_deeplyで取得結果全体チェック

「SELECT member_id , status , create_datetime 
   FROM member WHERE member_id = ? AND service_id = ?」
  $sth->execute( $sql , $service_id , $member_id) 

単体テスト

• select系はis_deeplyで取得結果全体チェック

「SELECT member_id , status , create_datetime 
   FROM member WHERE member_id = ? AND service_id = ?」
  $sth->execute( $sql , $service_id , $member_id) 

• Insert系もInsert行をSelectしてis_deeplyで全体チェック

単体テスト

• select系はis_deeplyで取得結果全体チェック

「SELECT member_id , status , create_datetime 
   FROM member WHERE member_id = ? AND service_id = ?」
  $sth->execute( $sql , $service_id , $member_id) 

• Insert系もInsert行をSelectしてis_deeplyで全体チェック

「INSERT INTO member 
    SET member_id = ? , service_id = ? status => ? , create_datetime =? 」
  $sth->execute( $sql , $service_id , $member_id , $status , $create_datetime)  

単体テスト

• select系はis_deeplyで取得結果全体チェック

「SELECT member_id , status , create_datetime 
   FROM member WHERE member_id = ? AND service_id = ?」
  $sth->execute( $sql , $service_id , $member_id) 

• Insert系もInsert行をSelectしてis_deeplyで全体チェック

「INSERT INTO member 
    SET member_id = ? , service_id = ? status => ? , create_datetime =? 」
  $sth->execute( $sql , $service_id , $member_id , $status , $create_datetime)  

• これらの実現のために社内で作成したFixtureモジュールを使用

単体テスト

• select系はis_deeplyで取得結果全体チェック

「SELECT member_id , status , create_datetime 
   FROM member WHERE member_id = ? AND service_id = ?」
  $sth->execute( $sql , $service_id , $member_id) 

• Insert系もInsert行をSelectしてis_deeplyで全体チェック

「INSERT INTO member 
    SET member_id = ? , service_id = ? status => ? , create_datetime =? 」
  $sth->execute( $sql , $service_id , $member_id , $status , $create_datetime)  

• これらの実現のために社内で作成したFixtureモジュールを使用
• 最近ではDataFactoryも使用しはじめてる
• 似てるかも http://d.hatena.ne.jp/shiba_yu36/20111028/1319810431

単体テスト

単体テスト

• Controllerクラスのテスト

単体テスト

• Controllerクラスのテスト
• 実は社内の一番泣き所

単体テスト

• Controllerクラスのテスト
• 実は社内の一番泣き所
• 今回は手探りな中 Plack::Test::test_psgi を使用してみた

単体テスト

• Controllerクラスのテスト
• 実は社内の一番泣き所
• 今回は手探りな中 Plack::Test::test_psgi を使用してみた
• Controller自体は現状はPSGI化されてないApache2依存

単体テスト

• Controllerクラスのテスト
• 実は社内の一番泣き所
• 今回は手探りな中 Plack::Test::test_psgi を使用してみた
• Controller自体は現状はPSGI化されてないApache2依存
• テスト用に上手くやる

単体テスト

• Controllerクラスのテスト
• 実は社内の一番泣き所
• 今回は手探りな中 Plack::Test::test_psgi を使用してみた
• Controller自体は現状はPSGI化されてないApache2依存
• テスト用に上手くやる
• 結果凄く便利!

単体テスト

• Controllerクラスのテスト
• 実は社内の一番泣き所
• 今回は手探りな中 Plack::Test::test_psgi を使用してみた
• Controller自体は現状はPSGI化されてないApache2依存
• テスト用に上手くやる
• 結果凄く便利!
• 今後はどこまでやるかの境界線も考えたい

単体テスト

• Controllerクラスのテスト
• 実は社内の一番泣き所
• 今回は手探りな中 Plack::Test::test_psgi を使用してみた
• Controller自体は現状はPSGI化されてないApache2依存
• テスト用に上手くやる
• 結果凄く便利!
• 今後はどこまでやるかの境界線も考えたい
• チェックしてる : HTTP Status Code
• チェックしてない : テンプレートに展開する変数の中身

業務連絡

• ここで半分くらい？
• っていうのをYAPC::Asia 2011 でやってる人が多かったので真似してみた

CI(Jenkins)

CI(Jenkins)

• Jenkins?

CI(Jenkins)

• Jenkins?
• perl5の開発にも使われてる by miyagawa bookmark
• http://perl5.git.perl.org:8080/

CI(Jenkins)

• Jenkins?
• perl5の開発にも使われてる by miyagawa bookmark
• http://perl5.git.perl.org:8080/
• testを書く->ブランチにcommitする->自動テスト！

CI(Jenkins)

• Jenkins?
• perl5の開発にも使われてる by miyagawa bookmark
• http://perl5.git.perl.org:8080/
• testを書く->ブランチにcommitする->自動テスト！
• テスト結果をプロジェクトチャンネルにIRC通知

CI(Jenkins)

• Jenkins?
• perl5の開発にも使われてる by miyagawa bookmark
• http://perl5.git.perl.org:8080/
• testを書く->ブランチにcommitする->自動テスト！
• テスト結果をプロジェクトチャンネルにIRC通知
• エラー時の出力メッセージをIRCのキーワード登録しておくと、ピカピカ光る

CI(Jenkins)

CI(Jenkins)

• scoreboard

CI(Jenkins)

• scoreboard
• おまけで使える

CI(Jenkins)

• scoreboard
• おまけで使える
• commitのスコアを算出してくれるもの

CI(Jenkins)

• scoreboard
• おまけで使える
• commitのスコアを算出してくれるもの
• https://wiki.jenkins-ci.org/display/JENKINS/The+Continuous+Integration+Game+plugin#TheContinuousIntegrationGameplugin-Rules

CI(Jenkins)

• scoreboard
• おまけで使える
• commitのスコアを算出してくれるもの
• https://wiki.jenkins-ci.org/display/JENKINS/The+Continuous+Integration+Game+plugin#TheContinuousIntegrationGameplugin-Rules
• scoreのルール
• それまでbuildが成功していた所で、テスト落としてしまうと:-10pt
• 既に失敗している状態で失敗しても: 0pt
• テスト落とさずにbuild成功すると : +1pt
• 新しいテストが落ちると : -1pt
• 新しいテストが通ると : +1pt
• -> 1つの.tファイルの中に10個テストがあったら : +10pt

CI(Jenkins)

CI(Jenkins)

• 一番最後のリリースの時

CI(Jenkins)

• 一番最後のリリースの時
• プロジェクトメンバー全員が数ヶ月必死になって書いたテストが含まれたブランチをtrunkにcommitする

CI(Jenkins)

• 一番最後のリリースの時
• プロジェクトメンバー全員が数ヶ月必死になって書いたテストが含まれたブランチをtrunkにcommitする

CI(Jenkins)

CI(Jenkins)

• リリース後1ヶ月くらい経ってからのある日の状態

CI(Jenkins)

• リリース後1ヶ月くらい経ってからのある日の状態

CI(Jenkins)

• リリース後1ヶ月くらい経ってからのある日の状態

• いまだに一人勝ち状態！

CI(Jenkins)

• リリース後1ヶ月くらい経ってからのある日の状態

• いまだに一人勝ち状態！
• とってもソーシャルですよね！

プロジェクトを通じて個人的な振り返り

プロジェクトを通じて個人的な振り返り

• もっとコード書きたかったし書かなきゃいけなかったけど、書かなかった/書けなかった

プロジェクトを通じて個人的な振り返り

• もっとコード書きたかったし書かなきゃいけなかったけど、書かなかった/書けなかった
• 先のフェーズを見て、必要なことをする

プロジェクトを通じて個人的な振り返り

• もっとコード書きたかったし書かなきゃいけなかったけど、書かなかった/書けなかった
• 先のフェーズを見て、必要なことをする
• 色んな約束事を決めたりする

プロジェクトを通じて個人的な振り返り

• もっとコード書きたかったし書かなきゃいけなかったけど、書かなかった/書けなかった
• 先のフェーズを見て、必要なことをする
• 色んな約束事を決めたりする
• 環境構築周り

プロジェクトを通じて個人的な振り返り

• もっとコード書きたかったし書かなきゃいけなかったけど、書かなかった/書けなかった
• 先のフェーズを見て、必要なことをする
• 色んな約束事を決めたりする
• 環境構築周り
• アプリ運用さん（今回は主にbonnuさん）とごにょごにょする

プロジェクトを通じて個人的な振り返り

• もっとコード書きたかったし書かなきゃいけなかったけど、書かなかった/書けなかった
• 先のフェーズを見て、必要なことをする
• 色んな約束事を決めたりする
• 環境構築周り
• アプリ運用さん（今回は主にbonnuさん）とごにょごにょする
• ブランチコントロールしたり、リリースフローを調整したりする

プロジェクトを通じて個人的な振り返り

• もっとコード書きたかったし書かなきゃいけなかったけど、書かなかった/書けなかった
• 先のフェーズを見て、必要なことをする
• 色んな約束事を決めたりする
• 環境構築周り
• アプリ運用さん（今回は主にbonnuさん）とごにょごにょする
• ブランチコントロールしたり、リリースフローを調整したりする
• 必要なライブラリを先に書いたり、直したりする。けど、、

プロジェクトを通じて個人的な振り返り

• もっとコード書きたかったし書かなきゃいけなかったけど、書かなかった/書けなかった
• 先のフェーズを見て、必要なことをする
• 色んな約束事を決めたりする
• 環境構築周り
• アプリ運用さん（今回は主にbonnuさん）とごにょごにょする
• ブランチコントロールしたり、リリースフローを調整したりする
• 必要なライブラリを先に書いたり、直したりする。けど、、
• 間違いなくプロジェクトメンバーの中で一番コード書かなかった！!

プロジェクトを通じて個人的な振り返り

• もっとコード書きたかったし書かなきゃいけなかったけど、書かなかった/書けなかった
• 先のフェーズを見て、必要なことをする
• 色んな約束事を決めたりする
• 環境構築周り
• アプリ運用さん（今回は主にbonnuさん）とごにょごにょする
• ブランチコントロールしたり、リリースフローを調整したりする
• 必要なライブラリを先に書いたり、直したりする。けど、、
• 間違いなくプロジェクトメンバーの中で一番コード書かなかった！!
• 忙しさのピークな時も仕事拾えない

プロジェクトを通じて個人的な振り返り

プロジェクトを通じて個人的な振り返り

• 皆さんの中にはいませんか？

プロジェクトを通じて個人的な振り返り

• 皆さんの中にはいませんか？
• 時代は動いてるし

プロジェクトを通じて個人的な振り返り

• 皆さんの中にはいませんか？
• 時代は動いてるし
• 転職してる人も多いですよね
• DeNAとかDeNAとかDeNAとか

プロジェクトを通じて個人的な振り返り

• 皆さんの中にはいませんか？
• 時代は動いてるし
• 転職してる人も多いですよね
• DeNAとかDeNAとかDeNAとか
• 年齢も重ねてますよね
• Yokohama.pmが始まってから(2008/06/27)だけでも3年半ですよ！

プロジェクトを通じて個人的な振り返り

• 皆さんの中にはいませんか？
• 時代は動いてるし
• 転職してる人も多いですよね
• DeNAとかDeNAとかDeNAとか
• 年齢も重ねてますよね
• Yokohama.pmが始まってから(2008/06/27)だけでも3年半ですよ！
• 多分似たような人がいると思ってる

プロジェクトを通じて個人的な振り返り

• 皆さんの中にはいませんか？
• 時代は動いてるし
• 転職してる人も多いですよね
• DeNAとかDeNAとかDeNAとか
• 年齢も重ねてますよね
• Yokohama.pmが始まってから(2008/06/27)だけでも3年半ですよ！
• 多分似たような人がいると思ってる
• 発信してみてほしいです

プロジェクトを通じて個人的な振り返り

• 皆さんの中にはいませんか？
• 時代は動いてるし
• 転職してる人も多いですよね
• DeNAとかDeNAとかDeNAとか
• 年齢も重ねてますよね
• Yokohama.pmが始まってから(2008/06/27)だけでも3年半ですよ！
• 多分似たような人がいると思ってる
• 発信してみてほしいです
• Yokohama.pmだし

プロジェクトを通じて個人的な振り返り

• 皆さんの中にはいませんか？
• 時代は動いてるし
• 転職してる人も多いですよね
• DeNAとかDeNAとかDeNAとか
• 年齢も重ねてますよね
• Yokohama.pmが始まってから(2008/06/27)だけでも3年半ですよ！
• 多分似たような人がいると思ってる
• 発信してみてほしいです
• Yokohama.pmだし
• YAPC::Asia 2011 だって運用トークがベストスピーカーだし
• DepOpsな方は優秀な方達が近くにいるので、得るもの多いはず

プロジェクトを通じて個人的な振り返り

• 皆さんの中にはいませんか？
• 時代は動いてるし
• 転職してる人も多いですよね
• DeNAとかDeNAとかDeNAとか
• 年齢も重ねてますよね
• Yokohama.pmが始まってから(2008/06/27)だけでも3年半ですよ！
• 多分似たような人がいると思ってる
• 発信してみてほしいです
• Yokohama.pmだし
• YAPC::Asia 2011 だって運用トークがベストスピーカーだし
• DepOpsな方は優秀な方達が近くにいるので、得るもの多いはず
• リーダー／マネージャーさんのマネジメントな話も聞いてみたい
• もしくはそういうイベントあったら逆に教えてください

まとめ

まとめ

• 大規模開発にはそれなりの大変さ

まとめ

• 大規模開発にはそれなりの大変さ
• もちろん大規模だから何もかも凄い訳じゃない

まとめ

• 大規模開発にはそれなりの大変さ
• もちろん大規模だから何もかも凄い訳じゃない
• 例えばスピード感では全然負けてます

まとめ

• 大規模開発にはそれなりの大変さ
• もちろん大規模だから何もかも凄い訳じゃない
• 例えばスピード感では全然負けてます
• サービス品質だって、まだまだな部分もある

まとめ

• 大規模開発にはそれなりの大変さ
• もちろん大規模だから何もかも凄い訳じゃない
• 例えばスピード感では全然負けてます
• サービス品質だって、まだまだな部分もある
• CIツールはとっても便利ですので導入してみると良いと思います

まとめ

• 大規模開発にはそれなりの大変さ
• もちろん大規模だから何もかも凄い訳じゃない
• 例えばスピード感では全然負けてます
• サービス品質だって、まだまだな部分もある
• CIツールはとっても便利ですので導入してみると良いと思います
• CIツールが先か、テスト書くのが先か

まとめ

• 大規模開発にはそれなりの大変さ
• もちろん大規模だから何もかも凄い訳じゃない
• 例えばスピード感では全然負けてます
• サービス品質だって、まだまだな部分もある
• CIツールはとっても便利ですので導入してみると良いと思います
• CIツールが先か、テスト書くのが先か
• ガリガリコード書いてるぜ、とはちょっと言えないお仕事している人いませんか？

まとめ

• 大規模開発にはそれなりの大変さ
• もちろん大規模だから何もかも凄い訳じゃない
• 例えばスピード感では全然負けてます
• サービス品質だって、まだまだな部分もある
• CIツールはとっても便利ですので導入してみると良いと思います
• CIツールが先か、テスト書くのが先か
• ガリガリコード書いてるぜ、とはちょっと言えないお仕事している人いませんか？
• 次は「がっつりモジュール作った」みたいな話ができるようにがんばります

まとめ

• ご静聴ありがとうございました