[B! development][programming] EF-0512のブックマーク

そろそろコードレビューそのものの必要性について考えるときがきているのかもしれない - タオルケット体操

技術ブログの方に書くか迷ったのですが、かなりポエムの類な文章になりそうなのでこちらに書きます。ちょっと前にバズったこちらの記事 medium.com に触発されました。ちなみにコードレビューに関する話としてはまだ僕が色々と手探りだった3年前にもこんなことを書いていたようです。3年前の自分の考えに触れられるブログって面白いなという気持ちとこいつどんだけ軽率な文章書いてんだよという気持ちが合わさり甘酸っぱい気持ちが生み出されました。 hachibeechan.hateblo.jp 当時と今では日本全体の技術的トレンドも変わっていますし、そもそも僕の所属している会社も違います。今の会社ではGitHubを使っており、コードレビューが当然のフローとして組み込まれています。そしていま改めて当時のブログを読み返したのですが、びっくりするほどコードレビューに対する僕の考えが変わっていないので、改めて

EF-0512 2018/01/29

リンク

「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog

はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。戦略ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースするなぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。失敗パターンその1: 巨大PRパターン失敗パターンその2: 新機能リリースブランチパターン失敗パターンその1: 巨大PRパターン新機