Hatena::ブログ(Diary)

kazuhoのメモ置き場

2014-03-13

OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい(もしくはコードレビューの話)

以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。

チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1

https://twitter.com/kazuho/status/431602421068877824

今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。

「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、

 ふりかえってみると、Linux手法や成功の前例は GNU EmacsLisp ライブラリLisp コードアーカイブの開発にみることができる。Emacs の C のコア部分やその他 FSF ツールみたいな、伽藍建築方式にくらべると、Lisp コードのプールの進化は流動的で、すごくユーザ主導で行われた。アイデアやプロトタイプ・モードは、安定した最終形に落ち着くまで 3 回も 4 回も書き直されるのがしょっちゅうだった。

今日的に言い換えるなら、あまたあるブランチやpull-requestの中から最良のものが選択されるということ。

これは、エンジニアリングリソースが潤沢にあるからこそ採ることができるアプローチ。そして、成功したOSSは必ずエンジニアリングリソースが潤沢になるので(成功したOSSの場合、問題があったら直そうとする人が多数いるから)、OSSの開発モデルとしては「バザール」モデルがうまく機能するように見える。

しかし、社内開発においては、限られたエンジニアリングリソースをできるだけ効率よく活用することが求められる。別の言い方をすると、エンジニアが「無駄な作業」をする可能性を減らすことを考えるべきだが、これはバザールモデルとは相反する。


コードレビューの話はその具体例であって、社内でのグループ開発においてプルリクエストの評価(やコードレビュー)で設計の問題を指摘するというアプローチは、実装完了後に設計の評価を行うことになるという意味で、手直しが発生した場合の損失が大きくなりがち。

それよりも、実装開始前に設計レビューをやるなどして、無駄なコーディング作業を減らすことを考えるべき。


参考:

テストファーストなGitワークフローについて - kazuhoのメモ置き場

https://twitter.com/t_wada/status/443945356665962496のスレ

lea pablolea pablo 2016/03/05 10:09 <a href="http://www.htconem10price.com/">HTC one m10 price</a>
<a href="http://www.wrestlemania32i.com/">WWE Wrestlemania 32</a>
<a href="http://www.bmw-g310.com/">bmw g310 Price</a>

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/kazuhooku/20140313/1394687353