最近、2つ理由からレビューの仕方や、仕様化のプロセスについて勉強しています。
- 自分自身がプログラムを書いている間、ドメイン知識が足りず、手が止まっている時間や周囲に確認することが多い。
- (半ば非公式に)分析用のRプログラムのコードをレビューするようになったが、「どうすればお互い勉強できるレビューができるか」に困っている。
1つ目について話すと、私はWEBマーケッター向けの社内ツールを作成しているのですが、 マーケッター側の企画者のまとめた「仕様」を理解できておらず、 「全データを使うめちゃめちゃ時間がかかるので、ここのチェック変えても大丈夫ですか? あ、変えちゃダメなんですね。…じゃあなんとか別の方法を考えてみます」 みたいな細かい手戻りも多いように感じています。
2つ目は、分析者(いわゆるデータサイエンティストと呼ばれるような立場)の人のコードをレビューするようになったということ。 分析者は、コードを書くことが専門ではないため、定期分析用のコードが必要以上に煩雑で扱いづらいものになってしまっていました。 そのため、先輩からの引き継ぎやモデルの改良に異様に時間がかかってしまっていました(と傍から感じていました)。
開発ではレビューが行われていたものの、 分析サイドでは「自分のやった分析を、一生自分で面倒見なければならない」みたいな風潮になってしまっていて、 分析者の立場では「優秀な人ががんばればがんばるほど自由に動けなくなる」という闇のスパイラルに入る傾向にあったように思います。
また、「レビュー=品質の悪いコードを外に出さないためのチェック」という役割が強くなってしまっているように感じていて、 「この機能を実現するのにAPIとして機能を切り出す場合と切り出さない場合の2つ選択肢があるんだけど、 どっちが総合的に楽なんだっけ?」と悩むような場合に、 相談とかレビューというか、そういう役割のものが欲しいと思っていたこともあります。
"ソースコードはプロジェクトの共同所有物である" "コードレビューは相互学習型のプロセスである" その通りだと思う。参考書籍も激シブでとてもいい。 / “チームでコードを書き始めたが、「どうやらレビューってやつをした方が良いらし…” https://t.co/gp4RW51ikb
— Takuto Wada (@t_wada) 2016年8月18日
チームでコードを書き始めた後、「どうやらレビューってやつをした方が良いらしい」くらいの若手に向けた資料です。 · GitHub
というわけで、こちらの記事で紹介されている本2冊を読んでみています。どちらの本も、上のような悩みにフィットするものだったので、 もうちょっとうまく開発フローを回せるようになったら文章でまとめてみようと思います。
[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?
- 作者: 清水吉男
- 出版社/メーカー: 技術評論社
- 発売日: 2010/05/01
- メディア: 単行本(ソフトカバー)
- 購入: 12人 クリック: 437回
- この商品を含むブログ (16件) を見る
- 作者: Karl E.Wiegers,大久保雅一
- 出版社/メーカー: 日経BP社
- 発売日: 2004/02/28
- メディア: 単行本
- 購入: 7人 クリック: 152回
- この商品を含むブログ (25件) を見る