仕事でミスった…

ボーイスカウトの規則とは

まずは, ポーいスカウトの規則とはなにかから. 以下のサイトの解説が詳しい.

• ボーイスカウトの規則 - Strategic Choice

以下, 引用.

コードを, チェックアウトしたときよりもきれいにして, チェックインしま す. これを「心構え」として常に持って, 「習慣化」します.

コードの洗練を継続して行う, ということです. それは大仰なことではなく, 変数名をよりよいものにし, 大きすぎる関数を分割し, 小さな重複を排除し, if 文の連なりをなくす, という小さな活動の積み重ねです.

背景

今回の開発は, スクラッチから Java でコードがかけるというまたとない機 会なので, 今まで学んできた TDD を今こそ発揮しようとかんがえた.いつも 以上にはりきって,レッド・グリーン・リファクタリングのサイクルを回し たつもりだった.

失敗したこと

ボーイスカウトの規則に従うと…

ボーイスカウトの原則にしたがって,

• 変数名をよりよいものにし, マージで競合が発生しまくった.

• 大きすぎる関数を分割し, 予定コード量が 見積りの 2,3 倍になる.

• 小さな重複を排除し,if 文の連なりをなくす. 予定完了日が 見積りの 2w に対してさらに 1w 遅延.

  今日は上司に, せっかく動いているのになぜなおすの? と注意された.

そしてマージミス

そして最大の失敗を今日犯す.

SVN で他人のブランチに自分の開発用ブランチをマージしたら, マージミ スが発生.レベルダウンが発生して,チーム全員でマージ箇所のコードレビュー を実視.全員の一日の工数を奪ってしまった.

競合がたくさんでてしまい, 多数の手動マージが必要だった. 注意してい たが, やっぱりまちがってしまった…

もう名前変更もうかつにできない, リファクタリングも相談して許可を得 てからするようにと, 注意される.

ここから学ぶこと

なぜ発生したか?

マージミスがなぜ発生したかというと, あせっていたから.

実は, マージしたときに JUnit がグリーンからレッドになったのは知ってい た. しかし, JUnit は他人のコードをとりこむとすぐにレッドになる, これ は日常茶飯事だったので,気にすることが泣く, 実機確認を急いでしまった.

立ち止まってでも, 実機の前に JUnit をグリーンにしておくべきだった.

また, もっと JUnit をグリーンにすることをチーム内にアピールするべきだっ た. なんかいつも, 自分が壊れたテストコードをグリーンにする作業をし ている気がする.

手動マージのコツとかってなんだろう?? 今回, 自分ひとりで手動マージ作業をすることに無理があった. 他人の修正を把 握できないのに. マージ完了後にレビュー依頼をするべきだった.

リファクタリングは悪いことか

今の状況では, 悪いことだった.

工程の遅延とレベルダウンにつながってしまった. 今の自分のコーディング能力では, リファクタリングをすることのリスク のほうが大きい. くやしいけれども, 力不足を感じた.

家で, ゆっくりときれいなコードを書くのはよい. しかし, お金を対価と して働いているので, 目的を達成するために, リファクタリングが必要か どうか, かんがえることをしなかった. TDD 頑張るぞーという幼い思い込み で今回のようなことになってしまった.

実は今日, このプロジェクトを離れて別のプロジェクトへ移動する話がき た. 今のプロジェクトもあと 1 ヶ月だ. くいのないように, 自分の実力を発 揮してプロジェクトに貢献したい.