コードリーディングのコツは極力コードを読まないこと｜牛尾 剛

私はクラウドのプロダクトチームで働いているが、何を隠そう一番苦手で克服できていないことが、コードリーディングだ。ものすごーく時間かかるし、時間かかったうえに読み間違えたりするし、しかもめっちゃ頭使うのに他の人はずっと速いので敗北感しか残らない。先日もマネージャの Pragna に相談したら、最初は２時間かかるけど、３か月もしたら５分で終わるわよ。って言われたけど、いや、そもそも俺４時間は最低かかるねんけどな、、、って感じ。 技術イケメンの皆さんのアドバイス よくよく私のキャリアを考えると、OSSにコントリビュートとかしていることはあったが、めっちゃくちゃ巨大でややこしいコードベースを読んで理解する必要が無いことが多かった。１からコードを書くのは得意だが、他の人のを読んでがっつり理解してとか、どうやったら出来るのかわからない。 当然自分の周りの技術イケメンの皆さんにコツを聞いていたのだが、ど

[tkmkg8m]

自分にとってのコードリーディングって、ドキュメントとかインターフェース部分じゃわからない挙動を理解するためとかレビューでバグがないか確認するためにやることが多いので記事の話とはゴールが全然違ってた

[cl-gaku]

そうすると「そのとおりに動かねえじゃねえかクソ！」という場所があぶり出される

[TokyoWorker]

信頼できるディベロッパーだと良いけど…

[Phenomenon]

名前つけがちゃんとしてたらそうだよね。クソコードは全部読まないとわかんないからきついんだよね。

[door-s-dev]

まあ分かる。ライブラリ使う時にソース読まなくてもメソッドのインプットとアウトプットが分かってれば使えるしそれと同じ事かなと

[nakag0711]

interfaceなんて知らん、全部if文で分岐すればいいというコードの場合はどうすればいいですかね

[kwhrtsk]

コードレビューのときは、こういう読み方ができるコードになっているか？という観点でも指摘をするようにしている。適切な粒度の構造化と命名がされているか、必要なコメントが書かれているか。

[ryuichi1208]

適切な設計できちんと保守されてる場合なのかな。読まないと何ともならないケースの方が身近だと多い気がする😥

[shikiarai]

最初から全部は読まないよね。まず当たりをつけて、順序立てて読み、よしよし、良い感じだな……あれ？ここは……？　ちょっと深く掘ってみよう、おや？　おや？　おやおやおやおやおや？

[tagomoris]

これはつまり裏返すと、普段からインターフェイスのデザインをちゃんとやれ、命名には気を遣え、変な副作用を起こすな、あたりに気をつけてコード書かないとねとなるよね

[S_Maeda]

“大抵は自分にとって難しすぎることは、何かが間違っているのだ。”

[yuki_2021]

参考になる。自分もほんとコードリーディング苦手で苦手で・・・

[mkusunok]

スゲー奴も実はコピペをする衝撃に安堵したり？

[winterfall]

“自分に何かが足りない、才能が足りないから、こんな大変」と思い込んでいるケース。大抵は自分にとって難しすぎることは、何かが間違っている”

[warau-uichi]

考え方

[eichisanden]

ポイントを決めて何度かに分けて読んでいる。最初は大まかに全体構造を掴んで、次にもう少し深く読むとか。ただ関数名と全然違うことやられる結局読まないとダメで辛い

[peperon_brain]

コードに限らず技術書や論文も同じに思う。読むにあたっては何か目的があるはずで、まずはそこに繋がるとこだけ追っていく。その過程で周辺が見えてくる。繰り返すと全体が見えてくる。

[rti7743]

だからこそ読まなくていい部分が多いコードは良いコードだと思う。駄目なコードは複雑に依存していて、全部読まないと理解できなかったりするから。

[peketamin]

業務知識を確認しながらじゃないとコードだけ読んでもよくわからなかった。

[tattyu]

パフォーマンスが異様に悪いコードは往々にして実装がめちゃくちゃやばいので結局全部読む羽目になって前任者への怒りを吸収してまた一つ大人になる。自分は特定の機能に着目してそれを紐解く様に読んでるな。

[shozzy]

コードレビューの時は、そうも行かない気が。

[futonchan]

どうしたら設計って上手くなるんだろう

[atsushingo]

カコードって何かと思った

[takeshiketa]

すごい人がこうだからこうみたい内容なのでよく分からない。

[rryu]

最初は読むというより探索に近いと思う。その関数がどのように使われる想定なのかの情報を集めるみたいな。それでも分からない場合に全文読み下しの苦行に入る。

[clubman023]

なるほ

[T-miura]

なんか組織のレベルとか、OSSのレベルに依存する気がする。出来のいいものなら、かかれている方針が良いと思うけど、クソコードだとわけわからん設計とか、トラップありそうなので、詳細見てったほうがはやいとか、、

[mapyo]

この境地に達したいなぁ。

[zorio]

自分もこうかな。基本的に名前とか構造は合理的だと信頼して読む。そうでなければ大きなシステムは手がつけられない。

[anigoka]

DV男「女にモテるコツは極力女の気持ちを読まないこと」

[ptpadan]

わかるな、逆に信頼できない人のレビューはめちゃ工数取られるし

[Iridium]

コメントもあまりなく、設計書に実装の詳細な記載がない現場で働いているので、残念ながら役に立たなかった。治安の悪い世界では通用しない。

[sshayashi0208]

こういうコードリーディングの方法もあるのか🤔

[asuka0801]

ロジックは流し読みで良いのは分かる。効率悪いコーディングはそもそもlinterが指摘してくれるしね。代わりにインターフェース設計とテストはしっかり読む。

[pmint]

「担当でもないテストコードを疑うな」って話。「コピペは悪」なんて初心者でも分かるノウハウを信じるうちは初心者。コピペしやすいコードが、短期記憶を使わず読みやすく簡素なコード。

[sugawara1991]

"実装を信用する"てのは、大規模開発が(ある程度うまく)動いている環境下でその前提が成立し故にその規模でも動いているというトートロジーかなあ。その規模だと全部読んじゃう人のスピード感が適合しないよね

[NOV1975]

この人大体こう言う話に「間違った名前」をつけてマッチポンプ的に耳目を集めるタイトルで書く癖あるよね。この話はコードリーディングのコツにはなってない（プログラムの仕様の把握でしかない）

[frkw2004]

コードを読む目的は何か? 今分かっている不具合の原因を見つけるため? なら必要以外のコードを見る必要ない。必要部分との切り分けにコメント等は一旦信用しておく。

[few01]

同意。ついでに、インタフェースの粒度が構造的になっていないと読みにくいね。