ルールズ・オブ・プログラミング読書会vol.12
https://scrapbox.io/files/655372c161a776001bf71cc6.jpeg
開催日時
2024年5月28日(火) 19:30~21:00
開催URL
参加人数
14人
ルール6
1990年代初頭の時点ですでにコードレビューという単語があったんだ
レビューすると怒られた時代
個人主義
「人を殺すプログラム」
比喩かと思った
本当に人が死ぬ状況で動くプログラムは割とある
90年代
バージョン管理ツールの話
Visual SourceSafe
作業時ロック形式
若いとそのころ生まれてるかどうか・・・
オープンソースの概念がまだあまり普及してないころ
どちらかというとフリーソフト
コードレビュー
歩くEffective C++みたいな立ち位置で時には他チームから呼ばれることがあった
「バグ検出が主目的」
バグ自体というより後々バグが起きそうというものが多い
条件式がかなり複雑になっている指摘
YAGNI
突出してる人が1人だけだとその人が書くコードはコードレビューしにくい
けれどそういうコードこそレビューが必要
コードレビューを知った時点ですでにgithub文化だった
プルリクを潰す作業(非対面)
対面でのコードレビューってどうなのか知りたい
作ったものの情報共有も兼ねてた
対面レビューどうやるのか知りたい
レビューが好きな人がいるのでよくやる
気晴らしになる、らしい
対面レビュー受けたい派多い
我流で学んだことが多いので知りたい
コーディングルールの話
コードレビュー5時間長い
粒度はどんなものなんだろう
コード量自体はそこそこでも、背景の説明をしたりして時間がかかることがあった
書かれてないこと
コード量
レビューの質
格式張ってないと言ってるから意図的に伏せているように思える
Sucker punchのコードレビュー運用の項目を見てハードル高いと思えてしまった
コードレビューでの質問と指摘
指摘はするけど質問したら負けかなと思ってる人
常に上から行きたい
質問の中に指摘を混ぜる人
どっちにせよ指摘してる
対面だとラリーが速い
プルリクだと文章にする時に社会性フィルターがかかる
レビュイーの方が強いみたいなことが書かれているがレビュアーの方が強いケースの方が多いと思った
対面と文章
対面のほうがお互いのリアクションを見てフォローできる
文章だけだと補足が難しい
量が多くて新人がビビる
そもそも渡した仕事量が多すぎる
ペアプロをとりいれると良い
p.105 こういうプロセスを用いることで、~
次回ここから
お悩み雑談室
なんでコードレビューしないの?
してみていいかもしれない
コーディングルールがない
あることで不都合が生まれるケース
守ってるからOKになる
もっといい形でかけるのに・・・
それを決めるトップがいない
全員ソルジャー
各々のグループの自治
コードレビューは書いたコード全て?
チームによる