2011-04-29 [長年日記]
_ テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる
まず、導入された結果は以下のようになっております。信じられないものもありますが、事実です。
- 1. マージが頻繁に行われる開発中はNoMethodErrorや文法エラーが続出。必要なコードのマージ漏れまで発生
- 2. 修正の度に人力テストが必要となり、コスト増大
- 3. これまで以上に責任論が追求される現場となる
- 4. コスト増加を恐れるあまりリファクタリングはおろか、巨大な迂回処理やコピペが横行する
本プロジェクトには、以下のようなテストコードを作(らない|れない)様々な原因があります。
問題分類 | 現場への影響 |
---|---|
マネージメント | テストコード作る時間が与えられず「人的テストでやってしまえ」という作業スタイル。 |
ソフトウェアの設計 | 以前書いたとおりマルチスレッド・マルチプロセスの更新が頻繁に起こる煩雑さ |
実作業者のやる気・技術 | 社員に元々やる気が無い。さらにプログラムへの興味・感心が無かったり、適正を著しく欠いていたり、事務作業*1に忙殺されたり、会社にあまり来なかったり。 |
マネージメントの問題
職を失う覚悟で文句を言わないといけませんが、言っても途中で無かったことにされます。対策になりません。*2
ソフトウェアの設計
これはまだ声を大にして「リファクタリングさせてくれ!」と進言することは可能です。しかし以下のように、出資者としては当然のリクエストがついてきます。
やってもいいけど、一つのバグも許さないよ。金ももちろん出さないよ。
そして、より近い上司からこう言われます。
だめだよ、動いてるんだろ?
残念ながら、対策になりません。
実作業者のやる気・技術
これしか残りませんでした。では、ここから一人の非カリスマ技術者が変えていけることは何でしょう。。
やる気 | いろんな理由でやる気無い人もいるからこれは、難しい。 |
---|---|
技術 | やる気がなくてもテストコードを書く技術があれば、作るようになるかもしれない。 |
最終的には下記2つの現状を打破したいと思っています。
- 1. マージが頻繁に行われる開発中はNoMethodErrorや文法エラーが続出
- => マージする前にテストコードを通してしょうもないミスは防いでいく
- 2. 修正の度に人力テストが必要となり、コスト増大
- => 人力テストの作業を減らしていく
打破できなくても、テストコードを作る気概を持った若手プログラマを育てたい。人力テストをやって貴重な20代をつぶすような会社生活を送って欲しくはありません。
責任論については取り切れるものではないと思っているため、言いたい人には言わせておけばよいと思っています。
どうしていったらいいでしょう?
テストコードを書かない技術因りの原因を考えてみます。
以降では、大本営設計オレオレRubyフレームワークを DihoneiOreoreFramework → DOFと称します。
探ってみた結果、技術の無いメンバーがDOFに対して簡単にテストコードを作成していくために必要なことは、以下の3つと考えました。
- 1. テストコードそのものの概念と恩恵を理解してもらう
- てすとこーど?(´・ω・`)?なんて顔をされないように、テスト用データの用意、とかモックとかスタブとかを説明します
- 非人力テストを適用した場合、どのような恩恵を享受することができるのか
- 例) マージしたら動かないから人力テストやらなきゃいけないという苦痛は、マージ後にテストコード通せばすぐわかりますよね
- 2. 何を非人力なテストで確認していくことが重要なのかを理解してもらう
- 書いているコードがどんな原理で動いているのか理解してもらうために、DOFの動作について説明します
- DOFでついつい作りやすいバグについて説明します
- 3. DOFに対するテスト用
DSLRSpec環境を整備して使ってもらう- DOF用テストコードは作ってはありますが、自分用のため、とても他人が使えるようなものではありません。
- RSpecを意識させないような、平易なコード
DSLまで昇華させる必要があります。
一介の非カリスマ技術者のやることが決まりました。一個ずつやっていきたいと思います。
まとめ
- テストコードを作成する文化がないので、Ruby/Railsを使ったって人的なテストが増加する一方で、いいことが一つも無くなった
- こんな状況は打破したいから、以下を頑張ってみる
- テストコードというものに目を向けてもらえるように、テストコードのすばらしさを説こう
- テストコード作成に時間がかかる、作成が難しいなら、簡単に書けるようにRSpec環境整備
DSL作成を頑張ってみよう
前向きだわぁヽ(・∀・)人(・∀・)人(・∀・)ノわーい
一人 Q and A
- 一人でやらなくてもいいんじゃね?組織である程度の時間を取ってやったらどう?
- 今君たちはどれだけ損していて「テストコード書けるようになったら」どれだけ儲かるの? と聞かれます。これに答えられないと、組織で動くことは許されません。
- 細かいデータを集めて数値化したとしても「手順書作ればいいんだよね」と片付けられてしまい、数値化できないDOFの惨さを伝えることができないため、弊社では組織として動くことができません。
- 若手がおかしな文化に染められる前に、素早く活動したいという思いもございます。
- 本当にRSpec環境を整備したら
DSLで解決できんの?- やってみてから。。。正直どうでしょう。。。向いてない人を作業に回さないほうがいい対策かもしれないのですが、そこは弊社の懐事情が許すわけもなく。。
追記(2011/05/01)
- 全員に強要すんの?嫌がる人もいるよ?
- 布教活動からして、希望者を募る形にしたいと思ってます。。
_ tDiary 3.0.2 リリース
肉*1の日定期リリースおめでとうございます。バグ発見に少々貢献したので一人ほくそ笑んでおります。
更新手順
github経由で更新しておしまい。
git ~/workspace/github/tdiary-core git branch 3.0.2_release # トピックブランチ作成 git checkout 3.0.2_release # トピックブランチに切替え git fetch -v official # 修正内容をfetch git merge 3.0.2_release official/master # トピックブランチにmerge apache2再起動してfcgi環境での動作確認 git checkout master # origin/masterに切替え git merge master 3.0.2_release # トピックブランチの内容をorigin/masterにmerge apache2再起動してfcgi環境での動作確認 git push -n # dry run で確認 git push # tamoot/tdiary-core へpush
*1 29日だから「にく」
コードジェネレータとDSLが混ざってますか? 混ざってないなら例えばRSpecはすでに RSpec is a DSL for creating executable exmaples ですし、その再発明はあんまり賛成できない気がします。技術的に RSpec を採用できない可能性もありますが。
オレオレフレームワークをRSpecを使ってテストできるように整備する、ですね。。
「(機械的に)動いていることが確認できているコードを増やす」「(自前の)書かなくてよい(はずの)コードを捨てる」「”たぶん動くコード”を捨てる」ことで保守性を上げる。これはきっと「理解はされる」と思います。実際に手を動かせるかどうかは別ですが。
まずは「そのために必要なアクションとして」RSpecなどの新しい話を持ってきてオレが手を動かしているのだ、と分かってもらえることが大事なんだと思います。自分でもうまくいってるかどうかは分からないですが。