アジャイルプラクティス読んだ

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

これはいい本だった。各章ごとに悪癖への誘惑と、それがダメな理由をまとめつつ、天使の助言に繋いでいく形にまとめられていて、非常にわかりやすかった。

「こっちの方がいいから絶対に実践すべき！」みたいな強い主張も少なく、この手の手法が場合によっては過剰だったり不足だったりするであろうことがしっかりと考慮されているのがウマイ。読んだ人がそれぞれのバランスを考えながら実践方法を考えてるんじゃないでしょうか。

以下、プロジェクトが（ほぼ）終わったばかりで心が荒んでいる人間の愚痴交じり。

チームの多数派（特に影響力の強い開発者）の振る舞いがプロ意識に欠けていて、チームの運営に無関心な場合は、自分自身がチームを離れてよそで成功を目指すべきだ

HAHAHAHAHA！　まったくその通りだね！　その通りすぎて何も言えねぇよ！　そのチームだけじゃなく、会社ごと辞めるつもりならこれが正解なんだろうけどさ！　逃げてはいけない戦いがそこにはあった。

まぁ、「“特に影響力の強い開発者”と、二度と同じチームに入れないでください」ってのは、もう半年以上前に伝えてあったんだけども。精神衛生上よろしくない戦いだった。

（悪魔の囁き）人のコードに問題を見つけても、自分の胸のうちにしまっとくんだ。当人の気分を害したり、もめ事を起こすのは嫌だろ。そいつがお前の上司だったらなおさらだ

今回の最大の失敗だったと思っている事を、的確に指摘されすぎてて泣いた。自分の意見の正しさを十分に説明できる実力が無かった。完全に力不足。

ピックアップレビュー（コミットレビュー）

個人的には（少人数なら）コミット直後にレビューした方が前後のログも残るしいいかなーとか思っていたりするんだけど、少数派なんだろうか。ログが煩雑になりすぎ？　リファクタリングする前の動いてる時点でとりあえずコミットしてしまう。

「偉大なプログラマ」になる必要は無いのです。私たちが目指すべきは「偉大な習慣を身につけたプログラマ」です

皆さんの名言フォルダに保存しました。