- 紹介する内容は SD や WEB+DB に載ってる内容です
- 詳細はそっちを読んでください
- 知ってる人は内職しててください
- この資料は公開するので、メモするより聞きましょう
- 手動はだるい、ミスしやすい
- 手戻りを減らす
- 自信を持ってプログラムを変更できる
- 気持ちよく仕事できる
- プログラミングに集中する
- 工数が減る
- はじめてやる場合は減らない
- むしろ増える
- 長い目で見るとペイできる
- テストの自動化
- コード解析の自動化
- 環境構築の自動化
- 構成管理
- デプロイ
- ユニットテスト
- Web 系の結合テスト
- 負荷テスト
- などなど
- デグレが防げる
- 何十回、何百回でも繰り返し実行できる
- 実装時の考慮漏れに気づける
- 効率的にバグをつぶせるタイミング
- 実装中 > 単体テスト > 結合テスト > リリース後
- どのタイミングでバグに気づきたい?
- xUnit, xSpec を使う
- JUnit (Java), Test::Unit (Ruby), unittest (Python)
- JDave (Java), RSpec (Ruby), JSSpec (JavaScript)
- 大抵の言語にライブラリがある
- ブラウザからのアクセスを模したテスト
- エンドツーエンドのテストを行う
- 機能仕様を満たしているか、デグレはないかなどの確認
- 主なツール: Selenium
- 負荷を生成してテストする
- 大規模データ、大きい負荷での検証を行う
- 主なツール: JMeter
- テストコードを用意する
- テストをコマンドラインから実行できるようにする
- Maven(Java), Rake(Ruby), nose(Python), phing(PHP) など
- 自動化するためには GUI からの実行では不足
- 自動実行する環境を整える
- 依存パッケージのインストールも自動化しておく
- Maven(Java), Bundler(Ruby), compoesr(PHP)
- コードの修正に合わせてテストを実行させる
- ローカルで実行する
- Guard, omake, flymake
- コミット時 (push 時)に実行する
- Jenkins, Travis などのサービス
- Pull Request に合わせてテストすると効率が上がる
- コードの進化に合わせてテストを書き換える
- 現時点でテストがない場合
- これから触る箇所のテストを書く
- 改修する度にテストを増やしていく
- これからコードを書く場合
- テストを書くことを想定して実装する
- テストしやすいモジュール構成を意識する
- 疎結合, DI
- テストしやすい構成 ≒ 見通しの良い構成
- エラーに対処する
- テストが通っていない状態を放置すると意味が無い
- テストの高速化
- 実行に時間がかかりすぎるとテストが信頼されなくなる
- 効率の悪いテストを書き換える
- モジュールを分割する
- 自動テストはコスト高
- 実装時間は伸びると思って良い
- テスト時間がやや短くなる (手戻りが減る)
- 短期プロジェクト、使い捨てコード以外では用意すべき
- 自動テストがあれば、テストフェーズはいらない
- 実装時に開発者がやっていたチェックと同程度と考える
- 信頼しすぎない
- テストの実装漏れもある。万能ではない
- せっかく Jenkins を使うなら、ついでにコード解析しましょう
- xUnit や xSpec はテスト時にカバレッジを取得できる
- カバレッジ: どの部分をテストしたのか。網羅率。
- カバレッジを取得するとテストしていない箇所が判る
- 通っていない if 文がないか
- テストが薄い箇所を潰していく
- 100% を目指すとハマるので頑張り過ぎない
- テストが十分かどうかの判断にはしない
- C0/C1/C2
- 詳しくはググってください
- Code lint, CheckStyle などとも。
- インデントや変数名が意図したものになっているか
- 統一しておくとコードが読みやすい (ゆるめでもよい)
- 各言語/フレームワークでよく使われる規約があるはず
- エディタの設定で flymake できるようにしておくとよい
- CheckStyle (Java), pep8 (python), CodeSniffer (PHP) など
- バグを埋め込みやすいコードを検出する
- 深いネスト
- 分岐がやたらと多い
- などなど
- FindBugs(Java), pyflakes(python), PHPMD (PHP) など
- 参考程度に見ておくとよい
- CPD (Copy/Paste Detector) とも。
- コピペっぽいコードを検出する
- CPD(Java), CloneDigger(Java/Python), PHPCPD (PHP) など
- 誤検出するときもあるので、これも参考程度に。
- コードに残された TODO や FIXME を検出する
- TaskScanner Plug-in (Jenkins)
- 忘れた頃に見てもいいかも
- 効果あるの?
- 多少は。
- やらないよりまし
- 環境構築も(なるべく)自動化しておくと楽かも
- 開発環境や本番環境の構築に時間をかけない
- ネットワークやマシンの構築が即時にできる
- 調達待ち、ラッキング作業などを考えなくて良い
- API を使えばより自動化できる (AWS SDK など)
- 故障率が下がるとは思わないこと
- 別の理由で停止することも多々ある
- デメリットもあるので事前に検討は必要
- サーバ、クライアントの設定を自動化する
- OS/カーネル の設定
- ミドルウェア/ライブラリのインストール・設定
- 開発環境と本番環境の差を減らす
- 「こっちの環境でしか起きないバグ」
- 「あっちとこっちでライブラリのバージョンが違う」
- 構成管理ツール chef, puppet, ansible など
- まずはシェルスクリプトでも良い
- 手作業を減らす/なくすのを目指す
- 構成テストツールもある (serverspec など)
- 手順書ベースのサーバ構築はつらい
- 再現性が低い、テストできない、ミスしやすい(抜け、漏れ)
- アプリケーションの投入を自動化する
- アプリの転送
- メンテナンスモード
- LB からの切り離し
- 切り戻し
- などなど
- ワンクリックでデプロイできるようになる
- capistrano, fabric, ansible など
- 手順書ベースのデプロイはつらい
- 一度書いたら他の案件にも使える
- それなりには使えるかも
- 思ったより案件によって差がある気がする
- コスト高そう
- 導入するのは結構大変なのでできるところから。
- コードレビュー
- Pull Request ベースのやりとり、マージ
- ドキュメンテーション
- Javadoc
- ER 図のリバースエンジニアリング
- Sphinx などを使った省力化 (Office を減らす)
- 自動化しましょう
- 「自動化」は度合いなので、ちょっとずつでもよい
- 7F では結構使っているみたい
- 残業が少しは減るかも
- 見積もり段階から考慮しておかないと難しい
- 最初に自動化するとコスト安
- 書籍「継続的デリバリー」の考え方が参考になる