QA@IT

コードを書いたことがない人にコードレビューをしてもらわないといけない辛さをなんとかしたい

3789 PV

ITの部署でコードを書いている派遣社員です。
正社員にコードレビューをしてもらいます。
正社員はコードを書いたことがありません。おそらく。

辛さその1
ITのツールも使いこなせないためコードレビューは顔を合わせて行います。
コードレビュー前に大量の資料が必要。
コードレビューでのお願いごとを書く。
誰が誰に対して何をしてほしいか?
大局観で大掛かり。

辛さその2
理解できないコードレビューのコメントに対応しなければいけません。
コードがあっちこっちに飛んで読みづらいから一箇所に書け。メソッドを使うなということ。
メソッドを使うなら処理される順番にコードに番号を振れ。資料にコードをコピーして番号を振る。
コードの行数はこれでいいのか?少ないと仕事をしていないとみなされる。

辛さその3
正社員が何をしているのかわからない。
職場に対する不平不満ばかり。

  • 質問者が何を質問したがっているのか回答者に伝わるような、もっとわかりやすい文章にするべきではないでしょうか。もう少し踏み込むと質問になりそうなのですが、現状だと愚痴が述べられているな... と感じてしまいます。 -
  • 愚痴みたい(というか勢いで書いたんだろうな)とは私も思いましたが、思ったことを。私なら啓蒙のための資料を紛れ込ませますかね。MSがIBMがAppleがGoogleがこういってます、だからこうしてます。あんなやりかた古いのです、という資料を。付き合いのある企業の資料だといいかも。理屈が通らないところでも発言してみる事に意味はあったりするものです。 -

回答

ITの部署でコードを書いている派遣社員です。

そんな頭の悪い会社やプロジェクトを抜けて別のプロジェクトいけばいいのではないでしょうか?
「我社の開発方法はこうです」という固定観念に囚われてる企業に、
わざわざ時間をとって改善しても無駄な努力でしょう。

編集 履歴 (2)
  • likeボタンがないので、コメントですが、そのとおりだと思います。 -
  • >likeボタンがないので
    そういう時はvoteするんですかね?
    -

コードレビューのやり方がいまいち文面から読み取れませんが、以下対策案です。

ただし、文面から判断する派遣先企業に対して立場の弱い派遣社員から提案していくのですから、相当な覚悟と苦労が必要だということはご理解の上、試してみて下さい。

…あと、釣りではないですよね?…

  • GitやMarcurialなどのヴァージョン管理システムを使う。
  • IDEの使い方に関する勉強会を開く
  • テストを書く
  • レビューツールを使う

GitやMarcurialなどのヴァージョン管理システムを使う。

  • 古いコードなど無用なのでバッサリと捨てます。
  • 変更前と後が確認出来れば、一つ一つのメソッドについて長い時間かけて説明する必要ありませんよね。

IDEの使い方に関する勉強会を開く

  • IDEでの操作について勉強会を開催します。
  • これは「すべてのプログラマーの生産性があがる」とか適当な理由をつけて、週一回くらい開いてみて下さい。
  • なお、プログラマーの時間のほとんどは他の人のコードを読むことに費やされているようなので、これは開催して損はないはずです。
ここらへんの内容をすればいいと思います。

このあたりを操作のショートカットを共有する勉強会でいいと思います。

  • 変数のdeclarationに移動する
  • Type declaration(クラス)に移動する
  • interfaceから実装クラスに移動する
  • 呼び出しているメソッドに移動する
  • 最近開いたクラスに戻る
  • また参照していた画面に移動しなおす
  • テストクラスに移動する
予想される反応
  1. だれも参加しない
  2. 時間がないからといってレビュワーの人が参加しない

前者についてはあきらめたら試合終了ですよ

後者については、政治的な問題が絡みますので、派遣元の上長→派遣先の上長→レビュワーという形で参加するように促してください。

誘い文句は 「プログラマーのスキル向上を見守ってほしい」 ということにしてください。

決して「レビュワーのスキル向上」とは口が裂けてでも言ってはだめです。

テストを書く

これは当たり前のことだと思っていますが…

  • (変更が簡単になるように)クラスを小さく作ろうとしたら、メソッドがあっちこっちに飛ぶのは必然なことです。
  • たくさんあるメソッドについて説明をする時間をとるなら、該当するクラスのテストを流した方が速いです。
  • テストには対象メソッドの引き数、戻り値が書かれているはずなので、口頭で説明するより明快なはずです。

レビューツールを使う

文面を見る限り、レビューに対して準備時間が1人日くらいかかっているように見受けられます。

開発者は質問者の方以外にもいるでしょうし、月に行うレビューの回数が一人あたり4回(再レビューも含む)くらいは行われているでしょう。

仮にメンバーの数が20人であると、一ヶ月あたり80人日、大体400万円弱の無駄をしています。

そういう状態であれば、コードレビューツールを導入することをお勧めします。

主にレビューツールとしては以下があげられます。

どれも、独自にサーバーを立てる必要がありますが、無駄をしている100万円出せば元は十分取れると思います。

編集 履歴 (0)
  • せっかくの回答が埋まってしまったのはもったいないですね。質問者のアカウント見るにもう見にくる事はなさそうですが、気づいたのでコメント。

    この質問者さんの現場は多分思われているより酷いですよ。むかーしコード書いてたとか業務だけはしってるぜなお偉様、IDEとかもう二度と使わない人たちにコードを見ていただく会(笑)なんだと思います(なので資料で啓蒙かなって思いました)。
    -
  • DVCS導入出来る現場ならここまでの事にはならないんじゃないですかね。

    付け加えるなら、コードは画面で見ましょう、こうすればフォント大きくできますよ。みたいなところから始める必要がありますね。IDEも入ってないだろうからエディタの導入も……。こんなクソみたいな現場はまだあるんです。居てもらわないと困ると思わせればわりと言う事通るようになりますけどね。長いコメント失礼。返信不要です。
    -
ウォッチ

この質問への回答やコメントをメールでお知らせします。