コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手
■ - hitode909の日記
出勤とか退勤とかするのめんどうで，忘れたら余計めんどうなことになるから，忘れないよう気をつけるみたいになってて，30分に1回くらい退勤のこと思い出したり，退勤忘れて帰る夢を見たりして，めんどうだった．革新的ソフトウェアを作って世界を変えるのが仕事なので，出勤や退勤といった些細なことに気をとられている場合ではないので，なんとかしないといけなかった． コマンドラインから退勤できるようにしたけど，普段から退勤する習慣がないから，すぐに退勤するの忘れて帰ってたりしてた． Google Chrome拡張を作って，定時過ぎたらポップアップが出て，退勤しますかとか聞かれて，OKしたら退勤できるようにしたら便利な感じになった． スペースシャトルの燃料タンクとか，心配になったら人が見るみたいな運用じゃなくて，普段は黙ってるけど減ってきたらウオオオとか言って，教えてくれるようになってると思う．まともなソフトウ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
