Code Review Meetup #4 (https://sideci.connpass.com/event/98378)

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

at Productivity Engineering − Forkwell Meetup #4

Pull Requestを出してレビューしてもらってから反映。 どこにでもあるありふれた開発フローに付きまとう、どこにでもあるありふれた問題。 「Pull Requestがレビューされない」 もちろん開発フローにレビューが含まれている以上、レビューをしないメンバーにも非がないとは言えませんが、多くの場合はレビューされないPRには問題があるものです。 デカい 兎にも角にもデカいPRは読むのがつらいです。 もちろん要件が明記されていないなど、他にもPRが読みにくくなる原因はたくさんありますが、一番はこれです。 極端な話、1行変更のPRは他に何も書かれていなくても実装内容を察することができますが、10ファイル100行の差分と箇条書き20点の要件が書かれたPRは内容を把握するだけで一苦労です。 しかし、このこと自体は数カ月でもコードを書いていれば自然と勘づくもの。 問題はなぜPRが大きくなってしま

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/Read less

ツールに任せることができないどんなことを人間は指摘できるのだろうか？ 驚くほど多数の事柄があることがわかっている。この記事の残りで幅広い重要事項のリストに触れ、2つの特定の領域、パフォーマンスとセキュリティに関してはもう少し深く言及する。 設計 新しいコードは全体アーキテクチャに適合しているだろうか？ コードはSOLID原則、ドメイン駆動設計、もしくはチームが採用する他の設計手法に従っているだろうか？ 新しいコードでデザインパターンは使用されているだろうか？これらは適切だろうか？ コードベースの標準や設計スタイルが混合されている場合は、新しいコードは現在の原則に従っているだろうか？コードは現在の方向性を引き継いでいるか、徐々に除去される古いコードの例に従っているだろうか？ コードは正しい場所に配置されているだろうか？例えば、コードが注文に関係する場合は、それは注文サービスの中にあるだろうか

GitHub: haya14busa/reviewdog: A code review dog who keeps your codebase healthy 英語記事: reviewdog — A code review dog who keeps your codebase healthy – Medium reviewdog というlinter などのチェックツールの結果を自動で GitHub の Pull Request にコメントしたり， ローカルでも diff の結果から新たに導入されたエラーだけを表示するようにフィルタリングできるツールを作りました． 英語記事 を Medium に書いたし，README も書いたので 日本語記事はまぁいらないかなぁと思ったけど，柄にもなく Vim 関連以外で普通に便利ツールを書いてしまって，これは日本語でも簡単に共有しようかなぁと思いこの記事

クソレビューアだらけのレビュー会 という、はてな匿名ダイアリーのエントリがホットのようです。共感する方が多いのか、1日でブックマーク数が700を超え、結構な勢いでコメントがついています。 何を対象にしたどのような条件下でのレビューなのかを示す文脈は直接書いていませんが、 ソフトウェア開発、システム開発における 欠陥の摘出を目的としたレビューであり レビュー対象はWord等のページ番号のある文書(仕様書や設計書)であり 少なくとも5名以上の同僚が集まる 対面の会議であり 文書の作成者が進行をリードするウォークスルースタイルで レビュアーはこの会議で初めて文書を読んでいる ということが推測できます。 レビューのスタイル であれば、もううまくいかないことは目に見えています。会議の場で初めて見る文書をウォークスルースタイルで作成者が頭から説明してゆくやり方は、設計の欠陥や仕様同士の矛盾などを見つけ

code_review_basics.md コードレビューの基本 一番大事な事 ソースコードはプロジェクトの共同所有物である 誰かだけが触れるコードを無くす 自分だけが持っているコードを無くす 自分だけが触っている時間を短くする コードレビューで大事な事 コードレビューは... 相互学習型のプロセスである メンバが成長することが大事 相互学習とは レビュアーとレビュイーが、お互い学び合うこと 考え方を共有すること 質問することで学ぼう 一番できる誰かだけが教えるのではない 知識や経験の少ない人が何に躓いているのか学ぼう メンバの成長 同じミスをチーム内で繰り返さないことが成長 ミスを繰り返さないために 本人の問題にしない 明日はわが身 仕事の正しい手順を覚えよう 道具の正しい使い方を覚えよう コードレビューの心構え 伝えることが大事 改善するまでがレビュー レビューにコストをかけ過ぎない

これは、「ドリコム Advent Calendar 2015 その2」の、8日目の記事になる。 7日目は、middlemanとGitHub Pagesでブログを5分で開設！ほか盛りだくさん！ | いくら寝ても眠たい だった。 私は、ドリコムでエンジニアをしている matsusaki (@misoobu) という者だ。 ここでは、最近考えることの多い、組織におけるエンジニアの情報共有と、そのあるべき姿について書く。 また、それに関連して、コードレビューや設計についても触れる。 内容は、エンジニア視点のものになる。 情報共有は、組織にとって極めて重要だが、簡単なことではない。 本記事が、再考するきっかけとなれば、幸いである。 情報共有とは 情報共有を失敗するとどうなるのか 様々な情報共有 プロジェクトの状況や方針 作業内容とその状況 プログラムの設計やコード レビューの目的 レビューをするとき

Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、

SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。

チーム内で良くある間違いなどをチェックリストにし、それをコードレビュー時に使う事で、コード自体のレベルを上げつつコードレビューの品質のばらつきをなくす取り組みについて。Trelloなどを開発するFog Creek社のブログの翻訳。 効果的なコードレビューについて書いた我々のブログ記事の中で、チェックリストを使う事を推奨した。チェックリストを使う事で、レビューが継続的にチーム全体でうまくはたらくようにできる。また、ありがちな問題を見つけたり解決したりするのを確実にする、簡単な方法でもある。 ソフトウェア工学研究所の研究によると、プログラマは15から20の良くある間違いをしてしまいがちだという。そういった間違いをチェックリストに追加しておく事で、問題が起こった時にそれを特定し、確実に駆逐するようにできる。 チェックリスト作りに取り掛かるに当たって、一般的な項目は以下のリストのようになるだろう。

SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。Read less