新人君へのアドバイス集(その1)

 2月半ばから本社を離れ、(一応数ヶ月の約束で)別の現場の方にヘルプに出てます。
そこで今年の4月で2年目を迎える新人君と、今年で4年目(?)位だけど
今迄全く開発に携わる機会が無かったメンバー2人と仕事をする事になり、
老婆心ながらこの二人に何とか自分の持ってる知識の一部でも伝える事が出来ればと思い、
日々アドバイスやらレビューバックした事をメモして、月一回それぞれに振り返りの為に送る
なんて事をしてました。

 結論を言ってしまうと、残念ながら前者の2年目君については、、、これ以上の
続行が難しいと判断して、自分の中で終了としてしまいました。。。。

 ただ、それ迄に記録した事がムダになるのも勿体無いので、業務とか現場に特化したような
知識とかは(守秘義務的な観点からも)載せる事が出来ないので
一般的な話に絞ってアップしてみようかな、と。

 ⇒ 正直なところ、周りの同期からみても既に遅れが見え始めている彼に対して
   勝手にこっちが「焦り」を覚えて、少々キビシ目に言っていたという事もあって
   それがプレッシャーになり、反発を招く事になってしまったようです。

 と、いつまでもボヤいてても仕方ないので、本題へ。

(※)以下、2年目君と4年目君にそれぞれしたアドバイスを特に区別せず
  混ぜこぜに挙げてます。
 
 
【彼がファシリテートしていた会議が終わった後にしたFB】
 ・議事メモは(提出を求められていなくても)取るようにしておいた方が良い。
 
 ・今回の会議の目的はそもそもどういうものだったのか?
  ⇒ 「情報共有?」「何らかの決定?」「相談・依頼?」
    参加してて何がしたかったのかが良く分からなかった。
    また、「出席者が次にどういうアクションを起こしたら良いのか?」は
    明確にしておいた方が良い。

【ソースと単体テストのレビュー後にしたFB】
 ・テストで大切な事は?
  ⇒ テストは「バグを見つけること」が目的。バグが見つけられないテストケース、
    テストコードは極論すればゴミ。

  ・今回の(単体)テストの「ポイント」は?
   ⇒ 今回は設計書に書かれてることが間違いなく(=過不足無く)実装されていることを
     確認するためのテストケース(すなわち設計書と1対1)でないとダメ。
   ⇒ 例えば異常系のテストが記載されていないが、(設計書に載っている以上)
     それもやる必要がある。
     今回であれば、同じ処理を2回繰り返せば一意制約エラーが簡単に起こせるので
     異常系テストケース確認はそれでやれば良いのでは?

  ・ソースはシンプルに。
   ⇒ ソースのバージョン管理をしておけば、不要なコードをコメントアウトして残す
     みたいなことはしなくて済む。
     そういうものも含めたソースのゴミは極力減らして、シンプルに書く事。

     半年後の自分から「なんだこのコードは?」というツッコミが来ないように
     メンテナンスを意識してシンプルに書くようにした方が良い。

【質問があった時の(設計)課題に対しての考え方についてのFB】
 ・設計に関して課題が見つかった時、どう解決していくか?
  ⇒ まず、自分でその課題に対して「どうあるべきか?」を考えて、
    レビューを依頼する。もしくは有識者に確認するというのでも良い。
    いくつかの方法はあるが、要は結局「自分で考える事」が重要。

    ⇒ 今回なら、A案、B案、複数の方法があると思うが、
      どれを選択するか?についても頭を使う必要がある。
      また、その選択に関して(レビュアー等に確認する時は)
      「根拠(とか何故そのように判断したのかの理由)」を示しながら
      聞くのが良い。

【システム設計の考え方についてのFB】
 ・各処理の前提条件を押さえている?
  ⇒ 全体の流れの中で、その処理がどの位置に存在するのか?

    例えばワークテーブルのデータ削除はそのテーブルを利用する処理が
    動く直前に行うことが多いが、それはなぜか?(直後に動かさないのはなぜか?)

【レビュー後にFBした事】
 ・レビュアーは完璧ではない
  ⇒ レビューのレベルはレビュアーのレベルに依存するので、
    残念ながら100%の間違い・漏れぬけの指摘が出来るわけではない。
    (ハッキリ言ってしまえば、レビュアーのレベル以上の指摘は出来ないし、
     逆にあまりにも下らない誤字脱字等が多ければ、それらの指摘だけでレビュアーの
     集中力・時間が割かれてしまって、レビュアーが指摘できる
     設計についての注意点等の指摘が半分も出来ないかもしれない)
    
    レビュアーの指摘にインスパイアされて、レビュアーの
    指摘の漏れに自分で気づくことが大切。

    また、指摘点が100%正しいわけではない。
    勿論それなりの観点・根拠でレビューの指摘が上がってくるハズだが
    その指摘自体が妥当かどうかについても自分で一度考えてみる。
    妥当でない思ったら、その根拠を明示してレビュアーに
    逆質問して、認識を合わせていく必要がある。

【作業の仕方についてのFB】
 ・SVNへのコミットはこまめにするべし。もしくは最低限ロックをかけて作業する事。
  (※)残念ながらこの指摘はこの後毎月のように指摘する事になったのですが。。。
  
っと、まだまだ1/3にもなってないけど、長文になりそうなんで、一旦区切りますか。