[B! dev][review] Makotsのブックマーク

Google Engineering Practices Documentation

Google Engineering Practices Documentation Google has many generalized engineering practices that cover all languages and all projects. These documents represent our collective experience of various best practices that we have developed over time. It is possible that open source projects or other organizations would benefit from this knowledge, so we work to make it available publ icly when possibl

Makots 2019/09/06

リンク

コードレビューの高まった言葉 - 職質アンチパターン

ブログ間違った，普段こういう事はこっちに書いてます． http://moznion.hatenadiary.com 最近自分がコードレビューで使いがち，あるいは表立って使ってないんだけど内心評す時に使う言葉が色々とあり，まとめてみることとした．参考にしない方が良いと思う．左は言葉，右は説明．屈強 - コードが力強い時に使う．例えば長い一枚スクリプトとか，コメントが一切ないバッチ処理とか．やや批判的な意味合いで使うことが多い．マッチョ - 屈強と同じ文脈で使いがち屈強だけどしなやか - 屈強だけどしなやかな時に使う．好意的な屈強さと言える．モノリス - 長大なトランザクションスクリプト見た時とかに使う．やや批判的．言い訳ないですか - 後で直していくぞ！というメンタルの時に書かれたコードのコメントが案外少ない時に使う言葉．言い訳は無いよりあった方が良い．実際には「もうちょっと言

Makots 2016/08/03

リンク

Facebookの継続的デプロイメント - ワザノバ | wazanova

https://www.facebook.com/publications/514128035341603/ 1日500件、3,000ファイルに及ぶ本番アップフロントエンドのコードは1050万行、内850万行がPHP 開発エンジニア1,000名とリリースエンジニア3名 QAやテスターは存在しない自分でプロジェクトを選ぶ & 自己責任のカルチャーが強い。 1/3のファイルが一人のエンジニア、1/4が二人のエンジニアでメンテされている。フロントエンドの本番コードベースは一つのものを共有日常業務ではローカルのgitを利用。本番アップ可能になれば、中央のレポジトリにマージして、それからSubversion（過去の経緯で使っている。）にコミットする同じエンジニアがコードをコミットする間隔は中央値で10時間本番にプッシュする前に、担当エンジニア自身でのユニットテストを終え、同僚によるコード

Makots 2013/12/04

リンク

コードレビューいろいろ - steps to phantasien

コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque

Makots 2012/08/20

リンク

コードレビューについて - camlspotter’s blog

このところ立て続けにコードレビューについて話をする機会があったので私が経験した最高のレビュー体制を簡単にまとめておこうと思います。利点何故必要か何が嬉しいのかコストうまく回すためには何が必要か細かい運営方法はっきり言って当たり前の事しか書きません。私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。型システムや