開発速度を上げるための Pull-Request のつくり方 - クックパッド開発者ブログ
こんにちは、投稿開発部の森川 (@morishin127) です。クックパッド、お料理アルバム、みんなのお弁当の iOS アプリの開発等に携わっています。 クックパッドでの開発は GitHub Enterprise 上で行われており、書いたコードをプロダクトに取り込む前には基本的に第三者のコードレビューが必須です。コードレビューはプロダクトの品質向上に貢献していますが、往々にして結構な時間と労力がかかるものです。Pull-Request を出してレビューをしてもらい指摘の修正を繰り返していると、場合によってはマージに数日〜1週間ほどかかってしまうこともあります。自分の開発速度を速めるため、また周りのエンジニアの開発速度を下げないためにレビューしやすい Pull-Request を出すことは重要です。この記事ではレビューしやすい Pull-Request のために心がけていることを紹介したい
pplog開発のコードレビューから学ぶpull requestによる自律的行動とコミュニケーション - ppworks.jp
pplogの過去のポエムを複数単語で絞込できるようになりました。 pplogは、自身と向き合い想いを言語化するためのサイトだったりします。（色んな使い方があります） 最新のポエムだけが他人に見えますが、 自分の 過去のポエムを見る機能があります。 この過去ポエムは検索機能が付いているのですが、先日まで複数単語で絞り込むことが出来ませんでした。 pull requestが来た id: shootaさんからpull requestを頂きました。 勝手にやった！まさにこれだ！と思いました。 よし、コードレビューをしよう！ 命名に突っ込んだ これを見て思うところがありました。 search_word_arrays = params[:keyword].gsub(/ /," ").split() 私は言った for文にナニカを感じた し、Cぽい！ search_word_arrays = param
コードレビューをし合える文化がチームを強くする - ppworks.jp
コードレビューしてますか？ 「コードレビューをしよう - pblog」でも触れたのですが、 今回はコードレビューの話です。 コードレビューって何からして良いか分からなかったり、レビューアーに負担なんじゃないか、、、って尻込みしがちですが、レビューしてもらう前に気を付けること、なにをレビューしてもらうのか、そして逆にレビューするのか、そして何が起きるのかあたりを考えていきましょう。 レビューして貰う前に気を付けること レビュアーの負担を減らすのは大事です。 コーディング規約に沿っているか？といった簡単なレビューは、犬にやらせるという方法もありますが、そもそもgit-pushする前に、ローカルのgit-commit時点で対処しておくというのもありです。 犬 is rubocopですし、 rubocopやjshintなどをgit-hookにまとめて設定できるpre-commit gemが便利そう
初めてコードレビューされる人のためのpull requestとcommitの作り方 - Qiita
pull requestの作り方について 作業途中でもpull request作ったほうがいい。 作業途中だと分かるようにwantedlyだと、[WIP]とかタイトルの最初につけてる タイトルに書くこと 作業の内容が分かるタイトル descriptionに書くこと WHY WHATを必ず書く Viewに変更がある場合は、スクリーンショットを貼る 関連のissueやpull reqeustへのリンクがあれば書く コードだけで分かりにくい箇所の説明(できるだけコードだけで分かるほうがいいけど) イメージは、初めてpull requestを見る人がmergeする上で必要な判断ができる情報があること。 どの作業をしているか、残っているか分かるように、マークダウンでチェックリスト作る git commitの方法について 僕自身まだまだcommitの単位は汚いので、今の僕レベルで気をつけていることを書
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
