OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話） - kazuhoのメモ置き場

以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G

[kazuhooku]

blogged

[katzchang]

エンジニアリングリソースに余裕を持たせると面白いことが起こるかも、という話に持っていこうぜ。

[june29]

実装レビューの前に、大枠の設計レビューを、というお話。いい設計にたどりつけたなら、いい実装の半分は終わっているようなものだと思う。

[route246]

手戻りがデカくなるようなもの作るときは実装途中でちょいちょいレビュー挟むなぁ

[knjname]

これを曲解して、設計が終わるまで1行もコーディングしちゃいけないんだよ☆方向に暴走されると困る。

[r-west]

そうそうリソースを無駄にしないために、リスクと詳細を事前にきっちり詰めて、ドキュメントにして、検討漏れがないかチェックリストでチェックして。もちろんドキュメントはExcelで :p

[nettabo]

WIP PRじゃダメなのかな

[myfinder]

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

[nilab]

「成功したOSSは必ずエンジニアリングリソースが潤沢に」「社内開発においては、限られたエンジニアリングリソース」「実装開始前に設計レビューをやるなどして、無駄なコーディング作業を減らすことを考えるべき」

[kgrock]

kazuhoのメモ置き場

[fragarach_the_sword]

OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話） - kazuhoのメモ置き場

[hatajoe]

なるほど。こういう話あまり聞かないしためになる。世はgithub時代だからな。

[ishiduca]

"社内でのグループ開発においてプルリクエストの評価（やコードレビュー）で設計の問題を指摘するというアプローチは（中略）それよりも、実装開始前に設計レビューをやるなどして、無駄なコーディング作業を減らす

[slywalker]

設計の合わせは大切。落とし穴に落ちないように。

[suginoy]

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

[haishi]

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

[restartr]

どういうフェーズのPRなのかが前提として共有されていれば大きな問題にはならないと思うし、プロトタイプで構わないと思う。

[stealthinu]

『成功したOSSは必ずエンジニアリングリソースが潤沢になる』のに対し『社内開発においては、限られたエンジニアリングリソースをできるだけ効率よく活用することが求められる』から同じ方法論が使えないと。なるほど

[Dryad]

『成功したOSSは必ずエンジニアリングリソースが潤沢になる…しかし、社内開発においては、限られたエンジニアリングリソースをできるだけ効率よく活用することが求められる。』

[kasumani]

kazuhoのメモ置き場 以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 Tags: from Pocket March 14, 2014 at 07:02AM via IFTTT

[naka-06_18]

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

[masaruyokoi]

変な言い方だと根回しなのだが、初期設計やコード書きながらでもいいから気づいた所は関係者と相談しよう！

[d_akatsuka]

PRの粒度が大きいとレビューする側も辛いし、出戻りも発生するのでWIP PRを出すのが良いと思う

[wasai]

うむ

[matsumanahate]

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

[ryonext]

とても納得できる話

[fukumura]

設計レビュー大事。

[nomnel]

“http://htn.to/by5or1”

[masutaka26]

そうですね。設計に近いところまで見積もって、状況に応じてWIP PR出す感じで！

[lesamoureuses]

ここ1ヶ月くらいのKPTはこれを解決するためのT出そうとしてる “それよりも、実装開始前に設計レビューをやるなどして、無駄なコーディング作業を減らすことを考えるべき”

[mitsugi-bb]

いかに書かないかが重要。

[YaSuYuKi]

需要に対する充足率のもっとも低い、ボトルネックになるリソースを浪費しないように、か