Developers Summit 2009 株式会社はてなの開発戦略 2/2
後半は、はてブのリニューアルしたときのお話でした。主にアプリの設計周りとテストの話だったので非常に面白かったし参考になりました。既存のフレームワークは便利だし素晴らしい設計だと思うけど、仕様をガッツリ変えちゃうこともあるしWAFに踊らされてる感が確かにあるので社内用途にあった物を自作するのは全然ありだと思います。
MVACで分けているのが冗長かどうか、という点が講演中に言われてましたがレイヤごとに完全に仕事を切り離してるので特にそうは思わなかったですね。逆にコントローラになんでもかんでも処理突っ込んで平坦なプログラムの方が保守性落ちて後から死ねる気がします。OOPで階層化すると若干構成が冗長気味になるのは仕方無いんじゃないかな。（OOP完全に理解しているとは言えないのでここらで自粛）
あとTDDは新規機能だとやりにくいってのには非常に同意してしまった。本当は駄目なんだろうけどｗ 自分の場合も実際に出来るかどうかパフォーマンスが出るかどうかプロトタイピングでやってしまっているところがあるので後からテスト書いてる感じです。もっと設計をしっかりするべきなんだろうか。
プレゼンに1点ツッコミすると「粗結合」じゃなくて正しくは「疎結合」です。
以下、講演時のメモ書きです。
リニューアルについて
- フルスクラッチする必要があるかどうか検討
旧システム問題点
- 保守性、拡張性
- テスタビリティ
- 他サービスとの密結合
保守性、拡張性
はてなフレームワーク
- 2002年製
- 今使うにはちょっと古い設計
- クラス継承ベースでのコントローラ
- １つの機能使いたいがために多重継承
- 継承しすぎ or コピペしすぎ
- 冗長なviewへのマッパクラスの作成
テスタビリティ
はてなフレームワーク
- テストが考慮されてない
- 旧ブックマーク
- ほとんどテストをしてない
Ridge/Moco
- テストを書きやすく
- (リニューアルなので)機能仕様は確定済
- 完全にTDD
- 新機能の場合
- テストが実装の後になる場合も
- どうしてもプロトタイピングになってしまう
- MVACのMAを重点的にテストした
他サービスとの密結合問題
MVAC
- Model / View / Application / Controller
(構成が)冗長？
- サービス、アプリケーションと分けるのは冗長？
- アプリケーションはビューとのつなぎ込み
- サービスはドメインロジック
- CUIアプリも簡単に
フレームワークを切り離す
- 上記3層はWAFを一切利用してない
- 単体テストが書きやすい
- WAF
- URL/コントローラ/ビューのマッピングのみ
- コントローラでクエリパラメータをアプリ・サービスにマッピング
リニューアル開発
- 前半
- id:naoyaが一人で
- 黙々とTDD
- 後半
- 多人数開発
- ポストイット活用
- gitを利用して機能開発
- masterはテストが通ったコードのみ
スケジューリング
- スケジュール通り
- 最後はテストがおろそかに
- リリース直後の高速化などでどたばた
- 実はリリース直後、全テスト通ってなかった
テスト
- 継続的にテストを書き続けることが重要
- テスト結果が赤いとモチベーション低下
- 100個以上のテストファイル
- 2000個以上のアサーション
テストの高速化
まとめ
- 適度な抽象化
- 適度なテスト
終わりに
- 全体の開発環境を向上させる
- ストレスレスで開発したい
- 開発しやすい環境
- 頭使う以外のところをもっと環境向上させる
