give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

【書評】開発チームのコードレビューをより改善したい人に!「Looks Good To Me」を読んでみた

はじめに

はてなブックマークを見ていて「お、なんか気になる本!」と思った「Looks Good To Me」を買って読んでみました。

ちなみに届いた本を手に取ったときの感想は「意外と分厚いな」でした。

でも、すごく読みやすくて、サクサクとページをめくっていくことができました!

どんな本?対象読者は?

「Looks Good To Me」はコードレビューに関するプロセスや文化、仕組み作りなどを詳しく解説した本です。

僕が考えるに、本書はこういう人が読むといいんじゃないかなーと思いました。

  • 開発チーム内にコードレビューの文化がなく、これから導入したいと思っている人
  • コードレビューは形式的にはやっているものの、いまいちしっくり来てなかったり、いろいろストレスを抱えたりしていて、もっと改善したい人

僕の感想

本書の冒頭で「『Looks Good To Me』は、コードレビューの教科書となることを目指して執筆されました」と書いてありますが、まさにその通りで、「コードレビューをこれから始めたい」もしくは「コードレビューをもっと良くしていきたい」と考えている人にとっては、あれも、これも、それも、コードレビューに関するイロハがふんだんに詰め込まれています。

僕も本書を読みながら、「うんうん、せやな、そーやな」と首を何度も縦に振りながら読みました。

プルリクは小さく!小さく!小さく!(大事なことなので3回)

中でも僕が一番首を大きく縦に振ったのは、58ページの以下の部分です。

扱いやすいPRとは……
信頼できるガイドラインの1つは、合計500行を超えるコードを提出しないことです。

(略)

もう1つの信頼できるガイドラインは、PRで変更されたファイルの合計数を20未満に抑えることです。

これは僕もほぼ同じことを考えていて、プルリクのdiffは300行以下に、変更されたファイルは30ファイル以下に抑えるのが良いと思っています。
以前僕が執筆した以下の記事にもその話を書いています。

絶対的な基準があるわけではありませんが、筆者は経験的に以下の範囲に収まっていれば許容範囲かなと考えています。

  • File changedは30ファイル以下
  • 追加された行数は300行以下
調査をサクサク進めるために。伊藤淳一が考える「良いプルリクエスト、悪いプルリクエスト」 | レバテックラボ(レバテックLAB)

微妙に数字は違うものの、感覚的にはだいたい同意見と考えて差し支えないでしょう。

そう、プルリクは小さくしないといけません!
diffの行数は多くても300〜500行程度、変更されたファイルは20〜30件程度に抑えましょう!!
頼むから1000行を超えるようなプルリクはやめてね 🥺

コードレビューするときの技術的な観点は少なめだった

一方、僕が本書に期待していたのはもう少しテクニカルな内容でした。
レビュアーがプルリクのコードと対峙する際の脳内分析とでも言うんでしょうか?
言葉で説明するのが少し難しいですが、

  • コードレビューするときはコードのどういうポイントに着目するべきか
  • コードレビューするときはどういう順番でコードを読み進めていけばいいか
  • コードに関する典型的な指摘事項にはどんなものがあるのか

といった内容を具体的なコード例とともに説明してくれたら嬉しかったなーと思いました。

もちろん、本書ではそうした内容にも触れられてはいるのですが、割合としてはわずかです。
冒頭にも書いたとおり、本書はコードレビューのプロセスや仕組み作り(ツールを使った自動化等)にフォーカスを当てている印象です。

僕が働いている株式会社ソニックガーデンでは、本書で書かれているような取り組みはだいたいすでにやっていて、僕自身、コードレビューのプロセスについては大きな不満は持っていません。
ですので、本書を読んでいて「うん、そのとおり」とか「やっぱりそうだよね」と思うことはあっても、「それは知らなかった!」と思うような目新しい内容はあまりありませんでした。

とはいえ、それはあくまで僕の場合です。
みなさんは「うちのコードレビュー、なんかうまく回ってない気がするんだよなあ……」と思っているかもしれません。
そういう人にとっては、本書を読むことで改善のヒントが見つかるんじゃないかなと思います!

「伝わるコードレビュー」と被る内容もあった

コードレビューといえば、先日「伝わるコードレビュー」という本も発売されました。
この本については以下のエントリで書評を書いています。

blog.jnito.com

「伝わるコードレビュー」はテキストコミュニケーションにフォーカスを当てた本です。
PRのdescriptionや、レビューコメントのやりとりについて、どう書けばわかりやすくなるのか、どういう言葉遣いをすればお互い気持ちよくコミュニケーションできるのか、といったポイントを解説しています。

「Looks Good To Me」でも「Chapter 6 効果的なコードレビューコメントの作成」で同じようなテーマが語られています。
たとえば「あなた(You)」で始まるレビューコメントは、攻撃的なトーンとして捉えられやすいそうです。へ〜、知らなかった!

「伝わるコードレビュー」を読んだときは、「こういう本が必要になるのって、日本人エンジニア特有なのかな〜」と思ったりしていたのですが、そんなことはなく、世界共通みたいですね。
テキストコミュニケーション、ムズカシイw

まとめ

というわけで、今回は書籍「Looks Good To Me」の感想を書いてみました。

何度も書いているとおり、「コードレビューの文化やプロセスをこれから導入したい」とか「うちのコードレビューはもっと上手にやれるはずだ」と思っている人にとっては、打ってつけの一冊だと思います。

より洗練されたコードレビューのプロセスや仕組み作りを目指している人は、ぜひ本書を手に取ってみてください!

あわせて読みたい

こちらは以前僕が執筆した、「良いプルリク、悪いプルリク」に関する記事です。
プルリクとコードレビューは切っても切れない関係だと思うので、こちらもあわせてどうぞ!
levtech.jp

レビューコメントのやりとりでギクシャクしがち、という人は「伝わるコードレビュー」もお勧めです。
blog.jnito.com

【謎現象】MXR Carbon CopyとJ.Rockett Archerを組み合わせるとディレイ音がほぼ鳴らない

今回はギターネタです。
最近MXR Carbon Copyというアナログディレイを買いました。

アナログディレイ、やっぱり気持ちいいですね〜!・・・と言いたいのですが、なんか音が変。
なんでだ?もしかして壊れてる??
と思っていろいろ調べたところ、ある事実に気付きました。

それは、「J.Rockett Archerが手前につないであると、Carbon Copyのディレイ音がほぼ鳴らない」という謎現象です😱

動画で確認してみる

テキストで説明するより音を聞いてもらった方が早いので動画を撮ってきました。

www.youtube.com

動画の内容はこんな感じです。

Carbon Copy単体 ✅

問題なくきれいにディレイ音が鳴っています。


Archer + Carbon Copy ❌

Archerをオフ(バイパス)、Carbon Copyをオンにすると、ディレイ音が1回しか鳴りません!

Archerもオンにすると、ディレイ音のリピート回数は少し伸びますが、Carbon Copy単体のときに比べると音質が悪く、ディレイ音の余韻も少し不自然です。


EP Booster + Carbon Copy(比較用) ✅

比較用にEP Boosterをつないだ場合も検証してみました。
これはCarbon Copyだけオンにしたときも、EP BoosterとCarbon Copyを両方オンにしたときも問題ありません。


Archer + EP Booster + Carbon Copy(比較用)❌? ✅?

ArcherとEP BoosterとCarbon Copyをシリアル接続した場合も検証してみました。

Carbon Copyだけオンにしたときは、「Archer + Carbon Copy」のときと同様に全然ダメです。
ディレイ音が1回しか鳴りません。

EPとCarbon Copyをオン、Archerをオフにすると、3〜4回リピートするようになりますが、やはりまだ不自然です。

3台ともオンにすると、そこそこリピート回数が増えます。
これぐらいならCarbon Copy単体の場合と比較してもOKな感じがします。


結果をまとめるとこんな感じ

動画の検証結果を表にまとめるとこんな感じになります。

Archer - OFF ON - - OFF OFF ON
EP Booster - - - OFF ON OFF ON ON
Carbon Copy ON ON ON ON ON ON ON ON
音質

バイパス(スイッチオフ)状態のArcherがCarbon Copyの手前にあると、Carbon Copyの機嫌が特に悪くなるようです。

原因は何?直し方はあるの??

原因はよくわかりません!直し方もわかりません!
誰かわかる人がいたら教えてください!!

素人の推測ですが、Archerは若干特殊なエフェクターで、

  • バッファードバイパスである(オフの状態でもギターの信号は内部の電気回路を通っている)
  • ペダル内部で9Vから18Vに昇圧している

という特徴があります。

このへんの仕様がもしかするとCarbon Copyの機嫌を損ねる原因になっているのかもしれません。

ちなみにChat GPTに言わせると、

ArcherのバッファとCarbon Copyの入力インピーダンスの相性問題ですね。
特にアナログディレイってデジタルと違ってすごく原始的なフィードバック方式だから、前段の信号特性にめちゃくちゃ影響受けるんだよね。

だそうです。知らんけど。

ただ、単純にインピーダンスの問題だけならEP Boosterをオンにしたときもインピーダンスは下がる(=状況としてはArcherと大差なくなる)はずなので、同じような問題は起きるんじゃないかなーと思ってます。

Archerのアウトプットだけ、Carbon Copyの秘孔を突くような、何か良からぬ信号が出力されているんでしょうか。。

参考:海外の掲示板でも似た報告が!?

同じような現象がネット上に報告されていないか確認したところ、1件だけよく似た話が見つかりました。

(ChatGPTによる翻訳。強調は筆者)


私はこの件についてJ. Rockettにメールしましたが、解決策の返答はありません。

最近Archerを手に入れて、音は良いのですが、私のMesa/Boogie Mark V:25のエフェクトループ内で使っているMalekko Ekko 616アナログディレイに思わぬ副作用を引き起こしています。

Archerをアンプのインプットに接続し、Archerがオンでもオフでも、アナログディレイのリピートが1回しか鳴らなくなってしまいます。

Archerを完全に接続から外すと、ディレイは通常通りのリピート数を出すようになります。
ディレイのミックスやリピートレベルを上げても変化はありません。

同様に、MXR Carbon Copyを使ってみても同じ現象が起こりました。
Archerがオンでもバイパスでもです。

なお、このアンプのエフェクトループにはセンド・リターンレベルの調整機能はありません。

一方で、ArcherをJHS Lucky Cat(デジタルディレイ)と一緒に使うと、リピートは正常に動作します。

Archerは他のペダルと組み合わせた場合には特に問題は起きません。

この現象を経験した方や、アナログディレイとの相性を改善する方法をご存じの方はいませんか?

お読みいただきありがとうございます。

https://www.reddit.com/r/guitarpedals/comments/aglh0d/question_j_rockett_archer_messing_with_analog/?rdt=38424

うむ、内容を読む限り、僕と同じ現象が起きていますね。

この人の場合、

  • Carbon CopyだけでなくMalekko Ekko 616というアナログディレイでも同じ問題が起きている
  • JHS Lucky Catというデジタルディレイでは問題は起きなかった

と書いています。

残念なことに有力なリプライは付かず、質問者の人いわく、「アナログディレイが使えないのは致命的なのでArcherは売った」と書いています😭
「メーカーのJ.Rockettに問い合わせても回答がもらえなかった」という点も痛いですね。。

まとめ

というわけで、今回のエントリでは、MXR Carbon CopyとJ.Rockett Archerを組み合わせるとディレイ音がほぼ鳴らない、という謎現象について紹介してみました。

いや〜、困りましたねえ。
ArcherもCarbon Copyも気に入っているのでどちらも手放したくないんですが、場合によってはどっちかを買い換える必要があるのかな〜と思っています😣

買い換えるならディレイの方かな〜。
何かおすすめのディレイをご存じの方がいたら教えてください!

ちなみに最近気になってるディレイはこれです↓
1回試奏してみたい〜!

【書評】もっといいコメントの書き方がわかる!『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』

はじめに

翔泳社さんより、『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』をご恵贈いただきました。

実はこの本は発売前から気になっていて、Amazonですでに予約購入していました。
ところが今回、翔泳社さんから本書を贈ってもらえることができたので、僕としては願ったり叶ったりでした😄
翔泳社さん、どうもありがとうございます!

どんな本なのか?

ひとことで言うと、プルリク上でITエンジニア同士が交わすテキストコミュニケーションに関する本です。

「こういうコメントはGOOD」「こういうコメントはBAD(なのでこう改善しましょう)」といったコードレビュー上のポイントが、豊富な具体例とともに説明されています。

どんな人におすすめか?

これはズバリ、実務に入ったばかりの新人エンジニアさんですね!
コードレビューをする側(レビュアー)よりも、される側(レビュイー)に回ることが多いITエンジニアのみなさんにおすすめです。

「コードレビューって何?」「レビューコメントが付いたけど、どう対処すればいいの??」と右往左往している新人エンジニアさんは、本書を読むことでコードレビューに対する向き合い方や心の準備ができるようになると思います。

一方、本書はレビュイーだけでなく、レビュアーにもお勧めです。
なぜなら「こういうコメントは書いちゃダメ」という、レビュアー向けのNG例とその改善策もたくさん載っているからです。

最近レビューする側にも回るようになった人は、本書を読むことで「そういえばあのコメントはわかりにくかったかも」とか「ああいう書き方をすると、相手を萎縮させちゃったかもしれないなあ」といった反省点が見つかったりするんじゃないかなーと思います。

僕の感想:あるあるパターンの連続!開発チーム全員で読んでおくと良さそう

僕が本書に別名を付けるなら「コードレビューあるある大全」と名付けたいです。

というのも、本書を読む進めていくと、「あるある!」「あー、これもよくある!」と、次から次に過去に自分も遭遇したことのあるコードレビューコメントの例が登場したからです。
「よくこんなにあるある事例を集めてきたな〜」と感心するほどです。

こういったNGパターンは、おそらくどの現場でもよく見かける光景なんでしょうね。
ですので、きっとこのブログを読んでいるあなたの現場でも絶対に役立つ情報が載っているはずです。

コードレビューを必須にしている現場で働いているみなさんは、開発メンバー全員で本書を読むといいと思います。
とくに、輪読会形式で読んでいくと「これはうちでもよくあるよね」とか「今度からみんなでこの点に気を付けよう!」といった具合に、参加者同士で話が盛り上がりそうな予感がします 😄

その他、思ったことなど

かわいいイラストが多くて読みやすい

「本を読むのが苦手」「文字ばっかり読むのはしんどい」と考えている人も大丈夫!
かわいいイラストがたくさん載っていて、普段本をあまり読まない人もすっと理解できるような構成になっています。


コード例はRubyが多め(でも誰でも読める)

執筆者がRuby界隈の方たちなので、コード例はRubyやRailsを想定したものが多かったです。
とはいえ、コードが主役の本ではないので、Rubyプログラマ以外の人が読んでもまったく問題ありません。

テクニカルな話は少なめ

本書を読む前は「コードレビュー全般に関する本」だと思っていましたが、実際に読んでみると「コードレビューにおけるテキストコミュニケーションに特化した本」だとわかりました。
なので「コードレビューするときは、こういう観点でコードをチェックしよう」というようなテクニカルな話は本書には出てきません。
個人的にはそういう話も読みたかった、というか、僕が書きたいな!!

一方、ソニックガーデンのコードレビューでは……

ちなみに弊社ソニックガーデンではこんなに丁寧ではなく、もっと殺伐としたやりとりが交わされています(苦笑)。

というと、「めっちゃ怖い」と思われるかもしれませんが、これはレビュアーもレビュイーもどちらも優れたプログラマで、なおかつお互いを技術者としてリスペクトしあえているからです。
加えて、普段からよくZoom等で話していて、お互いの人となりがよくわかっているから、という側面もあります。

つまり、互いに気を遣わなくてもよい関係性を構築できているので、コードレビューのコメント自体はシンプルで素っ気ないものになることが多いです。

たとえば、こんな感じですね。

素っ気ないコメントでもお互いに気分を害さないのであれば、コードレビューにかける時間も短くて済むので効率的です。

まとめ

というわけで、今回は『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』の感想を書いてみました。

コードレビューコメントに特化した本というのは、おそらく今までなかったと思います。
今までなかったけど、コードレビューの文化は日本のIT業界にかなり浸透してきているはずです。
ですので、「コードレビューやってます」という現場で働いているITエンジニアは全員必読の一冊、と言っても過言ではないかもしれません。

若手ITエンジニアのみなさんはもちろん、ベテランエンジニアのみなさんもプルリク上のテキストコミュニケーションを見直すために、本書を一度手に取ってみることをお勧めします!

あわせて読みたい

これに関連して、良いコミットや良いプルリクエストに関する議論を僕も以前、レバテックラボさんのサイトに寄稿しました。
「伝わるコードレビュー」とあわせて、こちらもぜひチェックしてみてください。

levtech.jp

levtech.jp

なお、個人的なコードレビューの極意は「自分のことを棚に上げる」ですw

qiita.com