OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話） - kazuhoのメモ置き場
以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G
些末なコードレビュー - naoyaのはてなダイアリー
朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。 あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。 コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう･･･実にくだらない。 ところで話は変わってコードレビューについて。 コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい
火曜日 - 日々の研究[STAP細胞]
研究を進めるとき、自分の喜ぶ結果がでたら、ほとんど確実にミスがある。これは、研究者にとって普遍的な現象だと思う。また、間違ってない発見をしても、冷静になるとつまらないことも多い。新しくて意味のあることを見つけるのは想像以上に困難であり、精神がすり減るようなことを繰り返し経験する。しかし、そういうことは本気で研究をしないと分からない。研究者になる前の僕が一人で研究を始めたとして、それを意識できたかどうかは分からない。真剣に科学にとりくむ環境があってこそ、そういう経験が「普通に」できたのだと思う。 某細胞の件。日曜日には、意図的な捏造の可能性が高くなって呆然とした。しかし、そうする理由が全く理解できなかった。今日の学位論文のイントロには驚いたが、落ち着いてくると何となく分かってきた。要するに、O氏の周りには研究環境がなかったのだ。結果を出さないといけないプレッシャー云々とか、そういうのに駆動さ
![火曜日 - 日々の研究[STAP細胞]](https://cdn-ak-scissors.b.st-hatena.com/image/square/cd9a934fe9beaffda56e2037053206136eaf1c6d/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F10257846132616123197%2F10257846132617102597%2F1535645457)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
