スケーラブルWebサイト(3章)

web 書評

第3章 開発環境

ここではまず冒頭で成功する開発チームの3つのルールとして、下記の3つが挙げられています。

  • ソース管理を実施する。
  • 1ステップでビルドできるようにする。
  • バグを追跡管理する。

ソース管理を実施する。

  • エディタのアンドゥ機能のようにソース管理はなくてはならない機能であるとされており、確かにその通りだなと思います。さすがに今ではほとんどのプロジェクトで利用されているかと思いますが。。
  • では、具体的にソース管理に何をするかということで、下記が挙げられています。(自分はここまで使いこなせていませんが。。)
    • バージョン管理
      • これがメインです。repositoryからチェックアウトして、変更しチェックイン(コミット)する。一人で開発する際にもなくてはならない機能だと思います。
    • ロールバック
      • 変更の取り消し、及び過去の指定したバージョンに戻ることが出来る機能で、頻繁に使うことはないかもしれませんが、いざという時になくてはならない機能です。また、どこでバグが埋め込まれたのかなど、プロジェクトの分析にも必要不可欠な機能だと思いました。
    • ログ
      • コミット時にメッセージを付加できる機能です。タスク管理との連携なんかにも使われています。何も入力されてなかったりすると少し寂しかったり。。
    • diff
      • 変更履歴を持っているから、その差分を見れるのは当然欲しい機能です。
    • 複数ユーザーによる編集とマージ
      • 複数人が同ファイルの別の箇所を変更した時に、変更をうまく取り込んでくれる機能です。同じタイミングで同じ箇所を変更しようとすると、手動でマージを行う必要があります。
      • しかし著者はその場合は、「頻繁にチェックアウト(更新)していない」や「開発者同士の意思疎通が十分でない」など、開発の体制に問題があるとしています。この辺りは大規模な開発ではどのように行われているか気になりました。
    • 抽出
      • ソースのブロックごとに注釈(リビジョンと最終更新者)を参照することが出来る機能です。ソースのどの部分がいつ誰に変更されたかをソース単位で見ることが出来る機能です。
    • ロックすべきか否か
      • ロックをすると当然その間はロックしたファイルを他の誰かに変更されることを防止できるので安全ですが、他の誰かがソースの他の箇所を変更するが出来なくなってしまいます。それでは、生産性が落ちてしまうこともありますし、せっかくマージの機能があるのだからロックは極力しないことを推奨しています。じゃあいつロックを使うのか。。。ぜひ教えてください！
    • プロジェクトとモジュール
      • ソースをプロジェクトやモジュールといった単位でまとめてチェックアウトしたり出来るという機能です。
    • タグの設定
      • あるリビジョンに対して、「バージョン1.0.0」のようなバージョンをつけておくことが出来る機能です。これによりいつでも特定にバージョンに戻せたり確認したり出来るようになります。
    • 分岐
      • 例えばリリース後にそのまま新規機能の開発を行っている時に、リリースしたバージョンにバグが出るとします。その際、ソース管理にある最新バージョンには新規機能の開発が含まれているのでそこでバグ対応してリリースことは出来ません。
      • そういった場合に、過去のリビジョンやタグを基にリリース時のバージョンを分岐させ、そこにバグの修正をしリリースします。一般的に分岐にはそれぞれ下記のような名称がつけられます。(subversionだけ？？？)
      • trunk ... メインの開発が行われる。
      • tags ... 上記でいうタグ。ここで開発は行うことはあまりない！？
      • branches ... ここでいう分岐。バグ対応などメイン以外の開発を行う。
    • マージ
      • 上記のように開発を分岐した場合、当然あるタイミングでソース全部をマージする必要が出てきます。そのための機能です。ソースのマージと比較しても当然複雑になりますし、衝突が発生しやすいです。なのでこまめにマージを行うのがいいのかなと思います。
  • ソースをさらに有効に活用する方法として、「シェルやエディタやIDEとの連携」や「ウェブインターフェイス」、「コミットログの活用(RSSやメーリングリスト」などが挙げられています。
    • この辺りは、チームでの開発では必須だと思います。後はコミット時にテストを自動実行するなどでしょうか。
  • またソース管理システムの紹介なんかもありました。今だとやはりSubversionが主流なのでしょうか。後はGitとか？
  • ソース管理に入れるべきもの
    • ソースだけでなく、設定ファイルやビルドツール、ドキュメントもソース管理システムに入れるべきとしています。
    • 逆にソースからコンパイルされた結果ファイルは入れるべきではないしています。また、選択したソース管理システムによっては、巨大なバイナリファイルなども入れるべきではないとしています。

ビルド

  • 開発したアプリケーションをどのように本番に展開していくのか、これについて書かれています。
  • リリース時にミスが発生しないように自動化し簡単にワンステップで実行出来るように整備することは大事ですよね。
  • 環境
    • 開発環境
      • 文字通り開発を行う環境。個人がそれぞれ構築するものとチームみんなで共通に利用する環境があります。
    • ステージング環境
      • テスト環境や検証環境という言い方をされることも。
    • 実運用環境
      • 本番環境ですね。ベータ版としてユーザーにテストしてもらうこともあります。
  • リリースの流れ
    • 「開発」して「コミットしてステージングに反映」して「ステージングから本番に展開してリリース」という流れを辿ります。
    • flickrでは、ウェブベースのコントロールパネルからボタンを押すことで各操作が行われているそうです。
    • また、本番環境と開発環境、ステージング環境の設定の違いを反映させる方法として、本番環境の設定ファイルの下で各環境用の設定ファイルをロードする方法が挙げられています。それにより設定が上書きされ、各環境に応じた設定値を読み込むことが出来ます。
      • よく、設定ファイルに下記のように全環境の設定が記載しコメントアウトで制御していることがありますが、それよりは管理が楽ですよね。
# 開発環境
#$IP_ADDRESS = '127.0.0.1';
# ステージング環境
#$IP_ADDRESS = '192.168.0.1';
# 本番環境
$IP_ADDRESS = '192.168.0.100';
  • リリース管理として、ソース(主にtrunk)をどのように管理していくかの方法が書かれています。
    • 大規模開発ではtrunkからは決して展開せず、展開が必要になったときはtrunkを分岐し、分岐から展開を行う。その後分岐をtrunkにマージする。
  • また、上記と対照的に「データベースのスキーマ変更」と「ソフトウェアとハードウェアの構成変更」については、慎重に行うべきで自動化するべきではないとしています。
    • 上記のように慎重に検討すべき点はあるにしろ、自動化することはとても重要で絶えず意識すべきことではないかと思います。自動化することでミスをなくす、繰り返し実行できるなどいい点がいっぱいあると思います。テストの自動化なんかも特に。

問題管理

  • 開発を行うと当然バグや要望が出てくるので、それを如何に管理するかが書かれています。
  • 問題や次にやるべきことについて「どのような状況になっているか？」、「誰が担当しているか？」をみんなで共有すること、さらに誰が今何の仕事に携わっているかを共有することはチームで開発を行う以上とても重要だと思います。
    • 個人でもTODO管理を行うので、チーム単位でも行うというのは当然の流れだと思います。
  • そこで問題管理システムの登場です。
    • バグはもちろん、要望などもまとめて入れておくことで、何をすべきかを管理することが出来ます。
    • 開発全体の状況を各エンジニアが見えるようにしておくことは、開発者それぞれのモチベーション維持につながると思います。またタスクを潰していくことを可視化することは、作業することにゲーム性を与え楽しく作業が出来るということもあるのかなと思ったりします。
  • ソフトウェアの紹介としては、「FooBugz」、「Mantis Bug Tracker」、「Request Tracker」、「Bugzilla」、「Trac」などが紹介されていました。
    • MantisとTracは使ったことがあり、現在はTracを使っていますが、Tracはwikiの機能もあるのがいいですね。wikiを別に用意することなく、Trac上で全てを管理出来ることはとても便利だと思います。とりあえずTracを開けば状況を知ることが出来ますし。またSubversionのリポジトリとの連動出来るのもいいですね。
  • 問題管理の戦略として、CADTと呼ばれるモデルではなく、ゼロ欠陥手法と呼ばれるモデルを導入するべきとしています。
    • CADT
      • バグを修正せずひたすら新規機能を追加したり書き直す
    • ゼロ欠陥手法
      • 新機能に取り組む前にバグを直す

コーディング規準

  • 変数やファイルの命名規則を文章にしておき、ソース管理システムに入れる。
  • コーディング基準に定義する内容としては下記が挙げられています。
    • インデント(タブなのかスペースなのか、幅は？)
    • 空白
    • 括弧
    • コメント
    • 命名
    • ファイルレイアウト(ファイルの命名規則)
  • これは開発者の数だけこだわりがあるだけに基準を作ることは大事であり難しいことだと思います。
  • ですがしっかり決められているかどうかは生産効率に大きく関わってくるんじゃないかと思います。
    • どこに何が書かれているかがわかりやすくなるのはもちろんですが、インデントに空白とタブが混じっていたり括弧の位置が違ったりすると読む気がなくなったりしません？？
      • 仕事で色んな会社の人が書いたコードを読む機会が多いので慣れましたが。。。
  • 最後にコーディング規準の規則として書かれていたことを引用します。

チームのメンバーにとって、単一のコーディングスタイルで合意することは、完璧なスタイルを探すことよりも重要である。

テスト

  • リグレッションテスト(回帰テスト)
    • これは自動化すべきテストだと思います。自動化するためにはロジックをしっかり各層に分離することが必要不可欠であり、アプリケーションの設計によって、テストにかかる工数は大きく変わると思います。
    • テストを書きやすいアプリケーションとは、役割ごとに各層に分離されたモジュール結合度の低いシンプルなプログラムだと思うので、必然的にバグを埋め込まれることも少なくなるのかなと思います。
      • 言うは簡単、行うは難しですが。。
    • ただ、一度テストを書くと書かないことが気持ち悪くなるので、テストを書くことを習慣化することが大事かなと思います。
  • 手動テスト
    • 時間もかかり退屈ではあるのですが、やはり必要な作業です。
    • テスト計画作成の流れとして、「主要な機能を抽出する」「理想的なパスを最初にテストする」「境界条件をテストする」という流れが挙げれています。
    • よく使われる機能をまずは重点的にテストし、その後境界条件やエラーなどのテストを行うことで、テスト時間を最大限に有効活用することが出来るとしています。

まとめ

  • 感想というよりも内容の箇条書きとなってしまいましたが、開発環境について幅広く書かれた興味深い章になっています。
  • いいアプリケーションを作るには、いい環境作りから。常にここで書いた部分なんかは意識しておきたいなと思いました。


4章の感想も書こうと思ったのですが、思いのほか長くなってしまったので今回は3章のみで。