読者です 読者をやめる 読者になる 読者になる

モノノフ日記

普通の日記です

Developers Summit 2009 株式会社はてなの開発戦略 2/2

後半は、はてブのリニューアルしたときのお話でした。主にアプリの設計周りとテストの話だったので非常に面白かったし参考になりました。既存のフレームワークは便利だし素晴らしい設計だと思うけど、仕様をガッツリ変えちゃうこともあるしWAFに踊らされてる感が確かにあるので社内用途にあった物を自作するのは全然ありだと思います。

MVACで分けているのが冗長かどうか、という点が講演中に言われてましたがレイヤごとに完全に仕事を切り離してるので特にそうは思わなかったですね。逆にコントローラになんでもかんでも処理突っ込んで平坦なプログラムの方が保守性落ちて後から死ねる気がします。OOPで階層化すると若干構成が冗長気味になるのは仕方無いんじゃないかな。(OOP完全に理解しているとは言えないのでここらで自粛)

あとTDDは新規機能だとやりにくいってのには非常に同意してしまった。本当は駄目なんだろうけどw 自分の場合も実際に出来るかどうかパフォーマンスが出るかどうかプロトタイピングでやってしまっているところがあるので後からテスト書いてる感じです。もっと設計をしっかりするべきなんだろうか。

プレゼンに1点ツッコミすると「粗結合」じゃなくて正しくは「疎結合」です。

以下、講演時のメモ書きです。

はてなブックマークリニューアルへの道

  • 21.6万
  • 790万PV/日
  • 開発期間約9ヶ月
    • 8月から専属メンバーが4人
    • それまではid:naoyaが1人で

リニューアルについて

  • フルスクラッチする必要があるかどうか検討

旧システム問題点

  • 保守性、拡張性
  • テスタビリティ
  • 他サービスとの密結合

保守性、拡張性

はてなフレームワーク
  • 2002年製
  • 今使うにはちょっと古い設計
    • クラス継承ベースでのコントローラ
    • 1つの機能使いたいがために多重継承
    • 継承しすぎ or コピペしすぎ
    • 冗長なviewへのマッパクラスの作成
Ridge

テスタビリティ

はてなフレームワーク
  • テストが考慮されてない
  • 旧ブックマーク
    • ほとんどテストをしてない
Ridge/Moco
  • テストを書きやすく
  • (リニューアルなので)機能仕様は確定済
    • 完全にTDD
  • 新機能の場合
    • テストが実装の後になる場合も
    • どうしてもプロトタイピングになってしまう
  • MVACのMAを重点的にテストした

他サービスとの密結合問題

  • DBから直接
    • データ加工などの実装が必要
  • 他サービスのperlコードを利用
    • ライブラリ依存問題
      • "foobar.pm"のバージョン違いとか
  • 疎結合
    • WebAPI利用
  • Squidを挟んでるのでHTTPキャッシュが有効に使える

既存のMVCの問題

  • ORMに処理が集中
    • データソースがRDBまでならまだいい
  • 他のデータソースを使う場合は?

MVAC

  • Model / View / Application / Controller

はてブ

データソース層
  • ORMのクラス
    • 基本的な機能
サービス層
アプリケーション層
  • サービス層を利用して実装
    • ページャの作成、キャッシュ操作など

(構成が)冗長?

  • サービス、アプリケーションと分けるのは冗長?
  • アプリケーションはビューとのつなぎ込み
  • サービスはドメインロジック
    • CUIアプリも簡単に

フレームワークを切り離す

  • 上記3層はWAFを一切利用してない
  • 単体テストが書きやすい
  • WAF
    • URL/コントローラ/ビューのマッピングのみ
    • コントローラでクエリパラメータをアプリ・サービスにマッピング

リニューアル開発

  • 前半
  • 後半
    • 多人数開発
    • ポストイット活用
    • gitを利用して機能開発
      • masterはテストが通ったコードのみ

スケジューリング

  • スケジュール通り
  • 最後はテストがおろそかに
  • リリース直後の高速化などでどたばた
    • 実はリリース直後、全テスト通ってなかった

テスト

  • 継続的にテストを書き続けることが重要
    • テスト結果が赤いとモチベーション低下
  • 100個以上のテストファイル
  • 2000個以上のアサーション

テストの高速化

  • 以前は合計10分強
  • 1テストでもfixture(DB)を使うと10秒ほど
  • ストレスたまる
  • YAML->ROM->RDB->mysqldumpを作る
    • YAMLのタイムスタンプが変更なければ前生成したSQLを使う

まとめ

  • 適度な抽象化
  • 適度なテスト

終わりに

  • 全体の開発環境を向上させる
    • ストレスレスで開発したい
    • 開発しやすい環境
    • 頭使う以外のところをもっと環境向上させる