[プルリクエスト] 締切は意識し過ぎない👀
Hideyuki Fujiharaコードレビューの際のポイントについてつらつらと書いていこうと思います。
今回はこちらの本を参考にさせていただきました。
Hideyuki Fujiharaレビューもそうですが、開発をしていると急かさせるシーンがあったりします。
その際に、
- 「忙しいから」
- 「面倒臭いから」
- 「締切が近いから」etc...
こういった理由でレビューを早急に切り上げてしまうのは良くありません。
人間は易きに流れるため、こういったレビューが行われると、
低品質なレビューが常態化して、productを蝕むからです。
そしてそれは本当に忙しい時に牙を剥いてくるからであり、
その時にもこのレビュー姿勢で臨むことになり、
技術的負債が重なって苦しめることになるからです。。。😱
Hideyuki Fujihara先述のようなプレッシャー下ではレビューイもレビュアーも、
- 「早くマージしないと」
- 「早く作らないと」
- 「絶対に期限までに間に合わせないと」
- 「期限までに絶対マージさせないと」etc...
こういった心理に陥っている可能性があります。
（PMなどもそうなっているかも知れません）
そうなれば負のサイクルに陥ることで重大な欠陥を見落としてしまい、
事態を悪化させかねません。
『早急なレビューが諸悪の根源』になってしまっていると言うことです。。。
（この場合は早急なレビューそのものよりも、それを是として常態化させている環境が諸悪の根源と言い得ます）
Hideyuki Fujihara詰まる所、開発チーム（スクラムチーム）に早急な要望をする、と言うことは、
productにとっては非常に危険な賭けとなり得ることを求めてきている訳なのです。
それでも求めるのであればそれ相応の理由を求める必要があります。
そうすることで、その早急な要望が実は仕様の変更で対応できる問題だと気づいたり、
運用面の問題でカバーしないといけない問題だと気づいて対応できたり、
開発で対応するとしても早急なリリースではなく次回のリリースに延期できたり、
（延期が望ましいものだと分かったりなど）
そもそも不要な対応だと気づけたりなど、
（そもそも何でこれが欲しかったんだ、他の手段で代替できるのでは...🤔 etc...）
回避策を講じるチャンスが生まれます。
こうすることでproductも開発チームも守ることができ、
ユーザーにもより合理的に安定してコミットをし続けられるようになります。
開発チームやステークホルダーもそうですが、
レビュアーはより広い視野で考えられるように気をつけないといけないのでしょう。
Hideyuki Fujiharaただとはいえ、そう言った早急な対応が必要な時もあるかと思われます。
例えば、
- 多数のユーザーに甚大な被害が及んでいる
- それがとてもクリティカルなものである
- 経営戦略的に大変重要で一刻も早くリリースしたい(例:ライバル企業とシェア率をせめぎ合っている)
こう言った事態などが考えられるかと思われます。
この時重要なのは、『なぜその場しのぎのコードを使ったのか(採用したのか)』ということを記録として残しておくことかと思われます。
そして、
- 今後のリファクタリングの方針
- そのことを示すTODOコメント
- そのコードの振る舞いを保証できる自動テストスクリプトの実装
- リファクタリングチケットの用意
こう言った次に繋げるための施策も打っておく必要があるかと思われます。
加えて、アジャイル開発の振り返り会(レトロスペクティブ)では、
どうやったらこう言ったことが減らせるのかについて議論をして、
改善のアプローチを講じていくこともまた必要かと思われます。