Motherにビューンっていたような?
ソニックガーデンの伊藤さんのんを読んで
ソニックガーデンで行われているコードレビューの具体例をお見せします (SonicGardn Study #11 の補足として) #sg_study - give IT a try
自分もコードレビューで色々言うのだけど。いやムシロ言って欲しいんだけど。コードレビューメモ日記。
ゴール
まず最初に、コードレビューのゴールが「とりあえず今回のリリースを間に合わせる!」だけだと「うごけばよかろうもん」ですれ違うので「今回のリリースには間に合わせる!だけど、その後の保守や機能追加も楽して素早く動きたい!あと、次のリリースのために、もう一歩成長しとこう!」という感じのゴールかな。
リリースには間に合わせる
現状のコードに満足できていないとしても、価値は届けなきゃだよね。「自分が納得したコードでリリースすること」じゃなくて「リリースした後も自分が納得できるコードに改善していける仕組み」がいい。
保守や機能追加
コードがクリーンだったりグリーンだったりしないと凄く辛いよね。拡張するよりゼロから作った方が早いわ!みたいな。
リリースして終わり!ならグチャグチャでもまぁ良いんだけど、保守とかエンハンスとかあるし、技術的負債によって突然の死を迎えてしまうね。
次のリリースのため
今回のリリースだけがゴールになると「動くかどうか」にフォーカスしがち。「動いてるから今回はいいけど、次のリリースのための開発のときにこんなコード書かないでね(にっこり」な視点があると良いかな。変数名とか。
1行1行に意図を
1行1行に意図を持ってね。と僕もいいます。コピペ得意な人は辛そうです!
説明しやすいコードを
たまに全員レビューをするときがあって、そのときに、コード書いた人に内容を説明してもらうのだけど。少なくとも自分が相手に説明しやすいコードじゃなきゃ!
テストコードにメンテナンス性を
いまの課題はここかな。まずは、自動テストを書こう!というとこをやったので。ぶつかるべくしてぶつかってるのだけど。
知識を広げる余裕を
余裕がないと、どっかからコピペしてきて、動いてるからいっか、って。あと、この前書いたコードと同じことやればいいや、って。そのときにちょっとでもいいから、もっといい方法ないかなー、ってJavadocをブラブラしてみるとか。普段から適当にライブラリ素振りしとくとか。ね。
コードを憎んで人を憎まず
コードレビューは、人を攻撃するもんじゃないし。未来の話をしよう。嫌な思いはするかもだけど。それは自分のスキルが足りないと受け止め。
おは。