プルリクエストを送るときは大抵気が重い。 | tech - 氾濫原
たとえ明かなバグ修正、すなわちマージされる公算が大きくても、些細なことでケチがついたりする。これがさらに機能追加みたいな「マージしてもしなくても本流には関係ないね」みたいなのは、マージされる公算がさらに低くてさらに気が重い。 まずプルリクエストを送るケースってのは、別にプルリクエストを送りたくてやってるわけではなく、そのプルリクエストに含まれるコードが自分に必要だからやってるに過ぎない。つまり最悪自分のレポジトリに置いておけばいいのだが、本流に取り込まれていれば今後のバージョンアップで機能が壊れることが減る (ついでに他に困ってる人がいたら助かるかもしれないね)。そういう保守的なモチベーションで動いていることであって、元気良くプルリクを送っているわけではない。 そういうわけで、大抵の場合プルリクエストを投げた時点で「XX だ! とか言われてDISられそうだ」とか「コードスタイルがあってない
オープンソース - hitode909の日記
オープンソースというかGitHubでPull Requestベースで開発してると，Pull Request送るのは，不具合修正か機能追加か効率化のためが主で，リファクタリングのためにわざわざPull Request送ることは稀だと思った．その結果，20人以上がコミットする3000行のクラスが出来上がったりする． プロジェクトのオーナーはどこが悪いか知ってから直せるけど，そうでもない人は，動く限りは，どう実装されてるか気にならないし，開発に参加しようとは思わないのかもしれない． リファクタリングすることで，他人のPull Requestがマージできなくなるかもしれない，という遠慮があるのかもしれない． photo by Najwa Marafie - Free Photographer
下から目線のコードレビュー - steps to phantasien
WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
