コードレビューン

Motherにビューンっていたような?
ソニックガーデンの伊藤さんのんを読んで
 

ソニックガーデンで行われているコードレビューの具体例をお見せします (SonicGardn Study #11 の補足として) #sg_study - give IT a try

 
自分もコードレビューで色々言うのだけど。いやムシロ言って欲しいんだけど。コードレビューメモ日記。
 

ゴール

まず最初に、コードレビューのゴールが「とりあえず今回のリリースを間に合わせる!」だけだと「うごけばよかろうもん」ですれ違うので「今回のリリースには間に合わせる!だけど、その後の保守や機能追加も楽して素早く動きたい!あと、次のリリースのために、もう一歩成長しとこう!」という感じのゴールかな。
 

リリースには間に合わせる

現状のコードに満足できていないとしても、価値は届けなきゃだよね。「自分が納得したコードでリリースすること」じゃなくて「リリースした後も自分が納得できるコードに改善していける仕組み」がいい。
 

保守や機能追加

コードがクリーンだったりグリーンだったりしないと凄く辛いよね。拡張するよりゼロから作った方が早いわ!みたいな。
 
リリースして終わり!ならグチャグチャでもまぁ良いんだけど、保守とかエンハンスとかあるし、技術的負債によって突然の死を迎えてしまうね。
 
 

次のリリースのため

今回のリリースだけがゴールになると「動くかどうか」にフォーカスしがち。「動いてるから今回はいいけど、次のリリースのための開発のときにこんなコード書かないでね(にっこり」な視点があると良いかな。変数名とか。
 

1行1行に意図を

1行1行に意図を持ってね。と僕もいいます。コピペ得意な人は辛そうです!
 

説明しやすいコードを

たまに全員レビューをするときがあって、そのときに、コード書いた人に内容を説明してもらうのだけど。少なくとも自分が相手に説明しやすいコードじゃなきゃ!
 

テストコードにメンテナンス性を

いまの課題はここかな。まずは、自動テストを書こう!というとこをやったので。ぶつかるべくしてぶつかってるのだけど。
 

知識を広げる余裕を

余裕がないと、どっかからコピペしてきて、動いてるからいっか、って。あと、この前書いたコードと同じことやればいいや、って。そのときにちょっとでもいいから、もっといい方法ないかなー、ってJavadocをブラブラしてみるとか。普段から適当にライブラリ素振りしとくとか。ね。
 

コードを憎んで人を憎まず

コードレビューは、人を攻撃するもんじゃないし。未来の話をしよう。嫌な思いはするかもだけど。それは自分のスキルが足りないと受け止め。
 
おは。