  |
はてなキーワード:xUnitとは
最近は最前線から離れててあんまり追えてないけど、現役のときの2008年くらいから10年くらいの間で、仕事のやり方や設計の考え方が大きく変わったIT技術要素で、いまぱっと思い浮かぶのはこんな感じかな。
分野にもよるし、調査して試作した結果自分の業務には採用しなかった技術とかもある。流行ると思って使えるようになったけど流行らなかった技術を入れるとたぶんもっとある。
あと、新機種が出てOSが新しくなったり、ミドルウェアの新バージョン対応、テスト手法の進化もけっこうカロリー高いけどここには書いてない。
「自分はフロントエンド専門でReactしかやらない」みたいに分野を絞れば大分減るけど、その技術が何年持つかわからないから普通はリスクヘッジのために他の技術も齧らざるを得ないし、バックエンドとかの人と議論するのに結局他分野の知識もそれなりに必要。
NoSQL(memcached,Redis,Cassandra)
クラウドアーキテクチャ、XaaS(AWS,Google Cloud, MicrosoftAzure)
CI/CD(TravisCI,CircleCI,Jenkins)
トランスパイラ(Browserify, webpack,CoffeeScript,TypeScript)
型システム(Rust,TypeScript,Haskell)
オーケストレーション(Ansible,Kubernetes, Terraform)
SPA(React, AngularJS, Ember.js,Vue.js)
3Dゲームエンジン(Unreal Engine無償化、Unity5)の他分野への普及
GraphQL
機械学習ライブラリ(Tensorflow, PyTorch,Chainer)
Jupyter Notebook
NFT
プライベートなメソッドや関数をテストする必要は無いと考えています。プライベートなメソッドは、実装の詳細であるからです。
ほとんどの場合、プライベートメソッドをテストする必要はありません。プライベートメソッドは実装の詳細です。
「プライベートメソッドはテストするな」と強く主張されるのは、ケント・ベックの影響もあるかもしれない。
例えばtwitterで、パブリックメソッドにだけテストを書き、テストが必要なほどプライベートメソッドが複雑ならそれを別のオブジェクトに切り出す必要があると発言している(twitter/kentbeck)ように、プライベートメソッドのテストに強く反対している。
またベックの書いたSUnit(xUnitの源流にあたる)には「ひとつのテストをひとつのオブジェクトで表し、それによってテストの独立性を高める」というアイディアが使われている(そのアイディアを実現するためにとても複雑な設計をしているSimple Smalltalk Testing: With Patterns)。テスト自身がひとつのオブジェクトとして独立しているなら、テスト対象となるオブジェクトのプライベートメソッドがテストできないのは当然のことになる。
が問題になる。
テストファーストで開発するなら手を動かしながら軽い気持ちで書きたい。
privateなルーチンの自動テストは面倒だ。実際にコーディングするときは最初publicにしておいてテストしてうまく動いていそうならprivateにするのだけど、この「いそう」がくせ者。いっそのことすべてpublicにしたくなる。
私は元々メソッドはprivateにしない主義なのでメソッドの場合は問題ないのだけれど、ファイル内の「関数」が問題になる。和了点計算だと和了形判定とか符計算とか和了役判定とか単体でテストしたい内部関数が山ほどある。(twitter/koba0367)
privateメソッドをテストすべきか問題、原則論だけだと袋小路に入りがちだから、privateメソッドをテストしたくなる具体的な場面について議論したほうがいいと思う。
自分がレビューでよく見る例としては、複数の publicメソッドの重複部分を privateメソッドに抽出した結果、濃い privateメソッドと薄い publicメソッドが一対多関係になる場合が挙げられる。設計としては間違っていないし、わざわざ publicメソッド経由でテストする意義があるかというと微妙。(twitter/ts7i)
きれいなインターフェースを作ろうとすればするほどpublicメソッドじゃない部分に複雑性を追いやることになり、壊れた時に手戻りが大きすぎると思ったら、プライベートにバックドア開けてでもテスト書くようにしてます (twitter/mizchi)
しかしプライベートメソッドに対するテストを書こうとすると大概リフレクションなどで可視性の制限をすり抜けるとかメソッドの可視性を変更するといった回りくどさやコストの導入が必要になるので、じゃあプライベートに対するテストはそうしたコストに見合うのかが問題になる。
伊藤さんの答えは「原則書かないほうがいいという大前提のうえで、どうしてもというときは、"これはテストのためにpublic"にしているというコメントの上でpublicにする」だった。
自分は「テスタビリティのためにメソッドをpublicにする」っていう"実プログラムの挙動を変えること"の方が、「privateなメソッドをテストコードのみsendで叩く」よりも怖いって思ってることに気がついた。(twitter/highwide)
単体テストがホワイトボックステストだとするなら、publicかprivateかでテストの有無が変わるのは明らかにおかしいだろ。ややこしいロジックはprivateに隠蔽すべきだが、そこがテストできないなんて。 (twitter/kmaebashi)
privateメソッドをテストするかどうか？ まず最初に言っておきたいのは public/private は抽象の設計の問題であって、テストすべきかどうかとは当然無関係だろうということ。(twitter/qeigoi)
特定の言語の貧弱な機能に思考が制限を受けて誤った結論を出している典型的な例。
https://b.hatena.ne.jp/entry/4684049296462116226/comment/megumin1
テストの粒度とメソッドのアクセス権は独立したものなので、「プライベートメソッドをテストすべきか否か」という切り方自体がナンセンスではあるのだが、現実問題としてはアクセス権がテストに影響するので難しい。(twitter/AoiMoe)
privateメソッドのテストはすべきかどうかというより、「できるべき」であって、それができないというのも、ある種、言語機能とテストのインピーダンスミスマッチと言えるのではないだろうか、と思っている。(twitter/aetos382)
RustやGoではプライベートメソッドに対するテストが簡単にできる。
そのためかプライベートメソッドをテストすることに対して拒否反応があまりないようだ。
Rustのテストはファイル内とtests/以下の2箇所に書ける。
テストには開発用のホワイトボックステストと仕様確認用のブラックボックステストがあり、前者をファイル内に、後者をtests/に書けば良い。
例えば度々議論になるプライベート関数のテストについてはもちろんホワイトボックステスト。(twitter/blackenedgold)
Rustではプライベートに対して何の手間もなくテストが書ける。
Rustでprivateなメソッドのテストを書きたいなら、そのメソッドのすぐ隣に書けば内部アクセスになるから普通に書けるよ、ってのは目からウロコだった。できるだけ近いところにテストを書こうっていう文化と相まって最高。(twitter/kuy)
Rust のようにユニットテストをプロダクションに混ぜる方式はおれもいいと思ってて、テストとプロダクションを分離することで private関数のテストができない問題があるけど（テストしたければクラスを分けよ/メソッドを公開せよ/テスト必要なし、に分かれるよね）、そもそもこの議論が不要になるよね (twitter/nunulk)
昨日「private method の単体テストは書くか否か」という話題がちょいとあったのだが、わしは当然書く感じの昨今を送ってきたもんで何で書かんのやくらいに思ってたんだけど、Go だと private なやつのテストが書きやすいってのがデカそう。(twitter/pankona)
golangのテスト書いてたけど、テストプログラムの名前空間(パッケージ)が、対象のプログラムと一緒で、そのためプライベートメソッドでもテストできるの良い感じ (twitter/74th)
Goのテストコード、テスト対象と同じパッケージにすればエクスポートしてない関数でもなんでもテストコードから参照できるんだけど、これってプライベートメソッドはテストすべきか議論するよりテスト書けと言われているようで好き。(twitter/plan9user)
「プライベートメソッドをテストするか？」とは別に「ドキュメントをソースコードと同じファイルに書いていい(文芸的プログラミング)なら、単体テストをテスト対象と同じファイルに書いてもいいのでは？」というのも論点になるかもしれない。
誰向けかよくわからないけど、なんとなく書いてみる。
システムエンジニアをかなり適当に分類すると2つに分ける事ができる。
SIerかそれ以外。
・それ以外…客に売るものを作る
日本のエンジニアの8割くらいはSIer側に属しているんじゃないかな（根拠なし）。
そしてこの2者では求められるスキルが大きく異る。
一番重要なものは、顧客が何を望んでいて、どういうものを提供すれば一番幸せになれるか、を判断できること。
ここには技術的な要素もあるにはあるけど、どちらかというと顧客の言葉やら背景やらを読み取って現実との折り合いをつけたり現場の運用を想像したりする部分が大きかったりする。もちろんどの技術を適用すれば一番効率的とか、安価に済むとかいう話はあり、最低限の技術知識は必要だけれど、世界最先端とか特殊な固有スキルとかが必須という世界ではない。一般的なSIでは難しい数式とか出てこない。
なので、文系っぽい空気があったりする。これが悪い方向に加速すると技術軽視のプロマネ至上主義になる。
何か他とはちがう売りが無いと買ってもらえない、使ってもらえない。
この要素として技術があったりもするけど、技術を売りにするのはハードルが凄く高いため、そういう会社は少ない。
技術そのものを売りにしなくとも、新しいものを数多く試行錯誤するために技術は必要不可欠で、SIerに較べて技術水準は圧倒的に高い。
で、この2つは会社ごとに別れているわけではなく、大手SIerと呼ばれているようなところには大抵両方が含まれている。
ただし、それ以外、の割合は大抵小さい。
自分はどっちの職場も経験した事があるんだけれど、同じ会社でもプロジェクトによってまったく状況が違ったりするので会社単位で一概に何かを断言するのは難しいと感じていたりする。
十年以上前から普通にアジャイルやってる部署もあれば、未だにxUnit知らなそうな部署もある、みたいな。
システムエンジニアになりたい、と思う人はどの会社を選ぶかを決めるにあたり、ここらへんのことは知っておいたほうが幸せになれるかもしれない。
技術を追い求めてガリガリ戦いたい情報処理系の人が大手SIerで望むことが出来る可能性は低いかもしれない。
普通の人からすると大したことじゃないと思うけど、もう会社の中に貢献しようと思う気が失せたので、その実態を書いておく。
ソフトウェアを自社開発していて、顧客自身がWebアプリケーションを作れるようなマルチテナントサービスを提供しています。
とある機能設計でCTOが「コレ出来るよね？」ってすごい適当な図((丸と線をつないだだけ))を書いて説明してて、
別の部署の部下がちゃんと理由((CTOには言葉の意味すらわかってなかったらしい))を説明して何度も断ってたのに、
無関係なうちの部長が呼び出されて「出来るよね？」って詰め寄られて「簡単にできますよ」ってさらっと援護してた。
彼自身はその機能に関して別に作業も具体的な設計をするわけでもないので、頭を悩ませるのは援護射撃をもらった担当の開発者たち。
社歴が長い分既存製品に関する知識があり度々オブザーバーとして呼ばれるが、今はその製品を開発している部署に所属しているわけでもなく、
最近の方向性や技術動向に関しては全然理解していないにも関わらず。
普段は雑談しながら笑ってることも多くて人柄は悪く無いと思ってるけど、仕事に関しては全部CTOの発言を決定事項として下ろしてくる。
自分が板挟みになりそうなら部下を責める。あなたの意図はどこ？
思考停止と思えるほどに「今までもこうやって来たんだし」がバンバン口から出てくる。
それを変えるやり方や新しい概念の導入に戸惑うとイライラして険しい顔でとにかく前例に合わせるようにする。
そうやって前例にこだわってきたからなのか、ちょっとしたエピソードがある。
たった４人の小さい部署だから毎週のMTGの余った時間で持ち回りの勉強会を提案して実施してたけど、
彼以外の３人がミドルウェアやフレームワークや新製品の説明をしているのに対し、彼は割とすぐネタが無くなったのか既存製品の話とか会社の規則に関する話が出てくるようになって、
最終的に「忙しいから」というよくわからない理由で勉強会が消えた。
３人共「楽しかったのになぁ」って口を揃えたんだけどね。
部長がいる僕の部署は新製品と銘打って開発を進めてるけど、例によってCTOの発言によって既に現行製品をなぞる方向でただの焼き直しを進める形になっている。
僕とサシで話した時は「現行製品と同じ機能を作っていくんだったら新製品を作る意味ってなんだろうねぇ(´Д｀)ﾊｧ…」とか言ってたくせにCTOの前ではハハハと笑っている。
以前指摘したけど、彼は新製品に関するプロダクトマネジメントやステークホルダーの立場ではなく、あくまで開発者らしい。
じゃあ誰が責任者でステークホルダーなんだよと思ったけど、そんなものは既存製品にもいなかった。
おかげさまで「あの時はこんな事情があって…」ばかりで迷走しまくってるんだけど、そういう反省は生かさないんだな。
基本的に技術に疎い。もともと企画をやってた人らしいけど、アイデアマン((その場の勝手な思いつきは多い))ではないなぁ。
バズワードは大好きだけど肝心の内容は何も知らないし間違いを指摘しても「そんな解釈もあるよね」ってごまかす。
でもそれでCTOっぽく技術をリードしていると思っているらしい。
その他にもいろいろ。「ifとforが使えれば何でもできるだろ」だの暴言も多い。
社長は彼がCTOとして問題があることに気づいているらしいが、役員だしなぁ。
来期は彼を開発部署の上から外してくれるといいな。でもその頃には僕はいない。
目の前の利益にはすぐ食いつく。
「こんな案件の依頼が来ていてお金はいいんですが、確実に専用のカスタマイズが必要なんですが…」というのに開発陣にヒアリングなしに受注を確定させる。
サーバだってもともと予算はないけどサクッと購入する。開発者たちにサーバを買う予算はないって渋りまくってるのに。
うまく行けば自分の実績として社内で大々的にアピールしまくるが、火消しに走るときは営業に文句行ったり開発者に文句行ったり。
そして保守のことは全然考えてないので、積み残されたカスタマイズサービス群が開発者や運用者、更には顧客への次の担当者を苦しめる。
現行製品の仕様を切り替えた時にカスタマイズで問題が起こったおかげで製品の仕様にカスタマイズを考慮したあれやこれやを要求されてがんじがらめ。
ちなみに、コレよりひどい自称元SIerの営業が居るが、とにかくカスタマイズ案件を取って受注しておいてPMをしないもんだから、
突然「お客さんが明日欲しいっていうんだけど」って焦って飛んでくる事態を連発する。
もちろんそんなことを連発してても「大型案件」を受注するから営業成績はMVPとりまくり。そこからずっと続く保守・運用は彼の仕事じゃないしね。
CTOの話に戻ると、僕らが作っている新製品(?)に関してもとにかく自分の理解の範囲内に収めるべく発言しまくるし、
新しい概念を持ちだされて意味がわからない時は「それって現行製品のコレはできるの？」で畳み掛けてくる。
もちろんそれを聞いた部長は「そうですよね。それも必要ですよね！」って援護してきて考えてきた設計がことごとく旧製品になっていく。
どうやらCTOの中では既存ユーザが内容を移行できる新製品にする予定で、機能まで全て踏襲するらしい。
そんなもん誰が使うんだろうねぇ。
「新製品を世に出していくには実案件で実績を作っていかなければ」って話をして、案件を持ってきた。
最初は短期間で終了する案件だったけど、運用期限の決まっていない案件が発生している。
そのために製品名もリリース時期も何も決めてないけど、メインから分離した保守ブランチができ、APIv1は提供済みだから今後はv2にならざるを得なくなり、
それすら新しい案件で潰されていくことだろう。
当初は「お客さんにはあくまで実験的なものと説明し、お金は取らない」((そんな話を受けるお客さんはたぶんいないって指摘したけど聞いてくれない))とか言ってたのに、
今は「売り上げあげなきゃこれまでの開発費がリカバリできない」とか言ってる。
まともなデバッグシステムやエディタを使わずに果たしてユーザはPHPコードを書いて開発をするだろうか？もちろん、否。
お客さんから依頼を受けたら営業担当者が四苦八苦しながら開発代行を行い納品する。
それでも難しい場合、パートナー企業に依頼をして開発をしてもらい、納品する。
そもそもPHP以外の機能自体も複雑になってて、開発者自身が「ここに機能追加しろって言われたけど、そもそもこの機能どうやって使えばいいの？」と迷うレベルだし、
想定してた使い方を超えてバグを付く動きを相談なしでお客さんに提供しちゃってるもんだから、
どれが正しい仕様なのかすら不明瞭になっている。
Javaってオブジェクト指向のプログラミングが出来るはずの言語なんだけど、オブジェクトなにそれ美味しいの？って状態。
クラスがただの関数置き場になっててメンバー変数をいじるもんだから、副作用のせいで同じオブジェクトを使う処理がことごとく影響を受ける。
それを避けるにはどうするか？もちろん似たような機能を持つ別オブジェクトを作ったり、別関数で違うメンバーを使うようにしたりする。
とにかく既存の流れを邪魔しないように新しいコードを作ればいい。おっと既存機能と同じ処理をする部分があるな。コピペコピペっと。
もうリファクタをしようと思う開発者はいないし、単体テストもないからできない。いや、無いんじゃなくて単体テストを作れない。
あちこちにDBコネクションとか埋め込んであって都度データ取得するから小さなコードでも動作するにはDBコネクションが必要なんだ。
僕は新卒メンバーには「会社内の書き方は（どの会社でもそうだけど、ここは特に）独自のやり方だから、コレが正しいと思わないように。
今後も開発者であるためにはxUnitとかバグの少ないコードの書き方とか自分自身で勉強するんだよ。」と言っておいた。
Conwayの法則とはよく言ったもので、まさしくリファクタできない密結合で暗黙のパラメータの多い組織。
自分の部署の立場を守る発言は多いけど、１年後２年後３年後どんなふうに仕事を進めていきたいからみんなでこうしていきましょう、って意思決定していくことは無い。
未来像を描いて推し進めようとする人とよく飲みに行くけど、その人もCTOからとにかく押さえつけられてたりする。
製品の結合度や他社サービスとの連携を図っていく基盤となる部分を提案しているのに、内容も全然理解してなくて「話が大きすぎて工数かかりすぎ」と言われ、
役員会でCTOが勝手に「仕様検討にかかった時間が負債になった」と報告したらしい。
「なにより、こんなことで諦める俺が憎い！」じゃないけど、そんな中途半端に辞めようと思う僕も駄目なやつだとは思う。
誰にも頼まれないまま開発インフラを変える動きを有志で立ち上げて色々やってCI((例によってユニットテストできない))が回るようになり始めたけど、それも中途半端。
運用インフラを変える部分もやっと使える状態になったけど、まだまだ中途半端。
そういった点は大変に申し訳ない。
でも、今のまま居たって僕に未来はない。
こんなところでこんなグチグチ言ってちゃダメなんだ。
だから、ゴメン！
ソフトウェア開発会社に新入社員として入社して1年とちょっと。
今俺は先行きについてものすごく悩んでいる。
こういうのは業界柄よくあることなので致し方ない、とは思う。
別にそれはこの際どうでもいい。
一世を風靡するしたJavaも今では一部でオワコンと呼ばれる時代だ。
新卒面接の時には「新しい技術を追いかけ続け、会社に貢献したい」とか言った気がする。
だが、その想いは入社半年を過ぎたあたりから見事に裏切られた。
レガシーコードとの戦いも覚悟はしていたが、俺が想定していたスマートなレガシーコードとの戦い方とはひどく遠いものだった。
テストなんてものは書かない。テストはExcel方眼紙で書かれたテスト項目が全てだからだ。
xUnitだとかSpecなんてものはもちろん知らないし覚える気もない。
極めつけはExcel方眼紙のテスト仕様書兼報告書と呼ばれる代物の抜けの多さ。素人でもわかるレベル。
足りなさそうな部分は経験則に則り適当にテストする。だがその結果は報告書には書かない。
バージョン管理なんてものも存在しなかった。上司に聞いたところ、あるにはあるらしいがCVSらしい。
だがそんなもの社内のどのチームを見ても使っている様子すらない。唯一のバージョン管理はファイルサーバー上の日付が書かれたフォルダーのみ。
とにかく現状がひどい現場だが、誰も変える気がない。
現場改善に向けていくつか提案もしてみたが、ただただ否定の言葉だけが帰ってくる。
なんとかしてやろうとも思い、個人的にいろいろやってみたものの、必要かどうかもわからない大量の雑務に押し潰された。
彼らには新しいものを学ぶ気なんて全く無かった。
会社を変える気も無かった。
俺はとにかく現場に失望した。憧れた業界はこんなものなのか、と。
同期や上司と気軽に話ができなくなった。
雑談でさえも話を続けることができない。
現場の問題点だとか新しい技術だとか業界の動向だとか、話したいことはたくさんあるのに。
彼らはそんな話に見向きもしない。
元々静かな現場であった上、コミュ障気味であることも災いし、その結果会社で話せる人はほとんどいなくなった。
雑談でもいいから話せなかった俺も悪い。だが今更何かを話にいく気にもなれない。
明日の飯を食うだけのために、1ヶ月、あるいは1年、もしくはそれ以上かかるようなつまらない仕事でも淡々とこなす。
生きていく上でのれっきとした一手段だとは思う。
だが俺はそんな生き方をしたいと思わない。
だが、現場ではどれだけ訴えても理解してはくれなかった。
俺は今、先行きに不安を感じすぎて俺自身が潰れそうになっている。
転職すればいいのかもしれないが、第二新卒枠がまだなんとか使えるとはいえ、今の実力でどこまで通用するのかわからない。
1年ちょっとで会社を辞めてしまう奴などクズだと見られるだろう。
その上就活もうまくいっていたほうではなかったから、その時の思いが蘇り、踏み出すこともできない。
八方塞がり。
きっとこの業界で自殺を考える奴の心境ってこんな感じなのかと、今日も1人日陰者としてExcel方眼紙の画面を睨み、与えられた作業を淡々とこなす。
ストアードプロシージャでビジネスロジックを実装するメリットを認めつつも、以下の点からビジネスロジックをクライアント言語で実装できる場合はできるだけそうした方が良いという結論に達した。
RDBMSによっては無料あるいは有料でソースレベルデバッガを使用できる場合もあるが、通常はクライアント言語のデバッグ機能を使う方がはるかに便利だ。何か問題があったときに、どこが問題なのかを見つけることがクライアント言語で記述した場合よりもはるかに時間がかかる。
また、Unit TestingFramework(xUnit)も使用できない場合がほとんどだ。
ストアードプロシージャ用の静的解析ツールの存在を知らない。巡回的複雑度を知りようにも知るすべはないのだ。それが行えるツールを知らないだけかもしれないが。
仮にストアードプロシージャの変更を全てAlter xx等で構成されたSQLスクリプトファイルで管理し、それをバージョン管理システムに含めたとしても（というか、最低そうすべきなんだが）、あるリビジョンのコード一式に対応するデータベーススキーマを取り出すのは難しいか面倒だ。
トリガーでビジネスロジックを実装する場合も、上記問題点が全てあてはまる。
さらにトリガーの場合は、どのような場合にどのような処理が実行されるのかを俯瞰することが難しくなるという問題もある。
一つは、Oracleで言うところのストアードファンクション、つまりSELECT等のDML内で使用する関数で、そうした方がパフォーマンス的にも良い場合。
うまくやる方法を考えてみた。
【目的】
社内でオープンソースのプロジェクトを行うことにより以下の４つの価値を生み出すことができる。
１．部門間におけるノウハウの共有
２．外部に公開した場合の宣伝効果
４．仕事そのものを作る効果
（４補足）
・新入社員の研修などが発生した場合に効果的に仕事を割り当てることができる。
・在宅勤務をせざる得ない状況における作業の割り当て。
【前提】
基本的に下記の事項を前提として考察を行う。
１．社内の人間であれば、誰でも参加できる。
２．途中で各人の任意のタイミングで抜けても、問題とならない。
３．社内の人間であれば、だれでもアクセス可能なWebサーバー上で情報を管理する。
ただし、必要に応じてアクセス制限をかけることができる。
インターネットに接続されている、Webサーバーは存在しているものとする。
４．各開発者は場所的、時間的に同じところにいないことを前提とする。
以上の前提より、下記の機能を有したWebサーバーの準備を行う。
１．構成管理機能
簡単にソースコードの取得、更新を行えるようにして、その履歴を残す。
２．Wiki
３．フォーラム
これにより、場所と時間にとらわれずに意見交換を行うことができる。
これにより、リリース時期の予測、作業の有無を効果的に確認できる。
５．テスト管理
これにより、リモート環境であってもリアルタイムにテストの進捗状況を確認できる。
案：TestLink
ReviewBoardの使用
http://blog.monospace.jp/2008/03/24/reviewboard_installation/
（※要調査）
７．フィードバックを受ける場
関係者のモチベーションを保つため、成果物に対して、フィードバックを受ける場を作成する。
案：社内のソーシャルブックマーク、アンケート機能
【効果的な手法】
その他、効果的な開発の進め方を考察する。
xUnitでテストコードを記述することにより以下の効果がある。
・修正後でも修正前と同じ動作するかどうかが、確認できる。
これにより、人の作成したコードでも修正を行いやすくなり、前提１、２の人の出入りに対応する。
自動ビルドを定期的に実行する。また、１のxUnitを使用して単体テストの失敗も監視する。
これにより、サーバー上にコンパイルが通らないソースコードや単体テストに失敗したコードの存在をチェックすることができる。
これは不特定の人間がかかわった場合に異常を検知するためである。
３．短期的なリリース
開発者のモチベーションを保つため、一定のめどがついた時点でα版という形でリリースを行う。
だめだまとまらん。
