読者です 読者をやめる 読者になる 読者になる

三流プログラマが脱三流するために書くブログ

PHP, オブジェクト指向プログラミング, デザインパターン, リファクタリング, DDD, 関数プログラミング, etc.

9. パートタイム技術アドバイザーの仕事に感じる難しさ

KPT

今月から、他人のコードを読んで改善提案をする仕事をしています。 三流プログラマにのくせに、こんな仕事を引き受けていいんだろうか…と悩みましたが、相手は今年の新卒ということで、私の知識と経験が少しでも役に立つのであればと、引き受けました。

新人とはいえ、PHPRuby でコードを書いた経験は多少あるようで、まったくゼロから、というわけではないので、質問されたら答える、ER図やコードをレビューする、くらいの仕事です。

でも、難しさも感じていて、リモートでのやりとりと週 1 時間程度のミーティングだけなので、危うい方向に進んでいてもこちらの反応が遅れてしまうことがしばしばです。

テキストベースでのレビューも、意図を伝えるためにできるだけ細かく書いていますが、果たして週一のオンサイトミーティングだけで十分なのか、と思うこともありますし、納期もある中でどのくらい細かく指摘すべきか、という問題もあり、スケジュールと進捗を突き合わせながら毎週考えています。

特に難しく感じているのは、設計の部分です。実装に入る前に設計をレビューしてないため、コードを見てから気づくわけですが、クラス設計はリファクタリングも大きくなりがちで、手戻りが発生してしまうため、納期との兼ね合いで指摘を躊躇してしまいますが、将来技術的負債を残さないためにも最初の頃にある程度きれいにしておいた方がいいのは間違いないので、やり方を見直さなくてはいけないと感じています。

相手が今後どういうプログラマになるか、という将来への影響もあるでしょうから、いい加減なことは教えられないというプレッシャーもあるので、この経験がきっと脱三流につながることを願い、こちらも日々勉強です。

それでも、いまのところ、感謝されているし、コードの品質的には問題ないレベルになっているかなと感じているので、少なくとも足を引っ張ってはいないとは思いますが、まだまだ改善の余地があるので、毎週ひとり振り返り会をやりつつ、インクリメンタルにやっていこうと思います。

ひとり振り返り会

Keep

  • 名前はシビアにチェックする
  • 改善提案はできるだけコードで示す

Problem

  • クラス設計のレビューを早期にやるにはどうしたらいいか

Try

  • phpcs 使ってもらおう
  • ミーティング後に、どうしたら効率的になるか意見を聞くようにしよう

参考にした記事

ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 - Qiita