git diff HEAD~ して、変更数が10行程度しかない。
そして、その commit に至るまでまる2日間が費やされてきた。
さらに、その変更の内容はいかにも単純で、ああそりゃそうするよねぇ、というようなものだったとする。
それをみたマネージャは、どんな風に思うだろうか?
「ああ、こいつはこんなちっぽけな仕事に2日間もかけていて、なんとまぁとろいのだろう」
って風にとられがちなんじゃないかな。ソースコードの行数で成果量をはかるくらいなのだから。
いやいや。
その10行に至るまでの過程というのは、そうは見えないけれど長くうねった道でありがちだ。
まず、複雑で大きなシステムのマクロとミクロの振る舞い、デザインを把握しないとはじまらない。望む機能を実現するには、この場所にあのクラスのメソッドを入れたらうまくいきそう。だけどそのメソッドは protected なんだよね… じゃこいつを friend クラスにしよう (えー)、public にしてしまえばいいじゃない (うわー) そのメソッドをよぶ public メソッドを追加するとか (いやいや) とか考える。
既存のデザインをむやみと壊さず、いちばん少ない変更で所望の機能を実現するにはどこをいじればいいか、熟考と試行錯誤する。もちろんどうしようもないときには構造を大きく変えるんだけど、できるだけ漸進的なアプローチをとりたい。
小さなステップを踏み、ビルドがこけないか、テストにちゃんとパスしているかを心がけ、よしこれで大丈夫だろうとローカルブランチに commit し、 rebase で commit の順番を入れ替え、さて元ブランチにマージ! としてみると conflict の嵐に見舞われ、ビルドを壊さないように、テストにこけないようにちまちまと手を入れ、やっとマージに完了。そして push! これでやっと10行程度の変更を終えることができる。
そういった行間を読めるか、というのはだいじな資質なんだな。
大規模で必要以上に複雑なシステムがあったとして、それを「きーっ! 書きなおした方が早いわ!!」 という衝動にはかられがちなんだけれど、そこでひと呼吸落ち着き、適切な場所に最小限の変更を施せる、という能力は一朝一夕で身につくものじゃないなー。ツボにひと針刺して、体の調子をすっと治せるような能力。
エンジニアの仕事というのは、結果の見た目がシンプルでも、かんたんではないのだ。それを実感する日々。
Tweet
