「Omotesando.rb #54 〜 コードの読み方 〜」に行きました。

https://omotesandorb.connpass.com/event/161445/

コードの読み方ということで、最近書いている話題とマッチしているので参加してみました。

みなさんどんなふうにコードを読んでいるのかな？って気になっています。

根気の入るコードリーディングをする時のアプローチ

Shibusawaさん

https://speakerdeck.com/fumiyashibusawa/lt-omotesando-rb-2020-01-09

ソースコードを読むまえに抽象化して考えてみようという話でした。

Shibusawaさんは図を書いたりして理解しているそうです。そしてそのための補助ツールとして

• 公式のドキュメント
• リポジトリのREADME

をお勧めしています。

特にRailsのREADMEはとても親切とのこと。

感想

読む側としてはとても重要なREADMEやドキュメント。逆に書く側としてはちゃんと補助となるように揃えておきたいですね。

bundle update PRの読みかた

sue445さん

https://esa-pages.io/p/sharing/8985/posts/202/5544484d73b2b3828ccc-slides.html#/

sue445さんは個人のソフトウェアでは毎日bundle updateしているそうです。 また、ピクシブでは毎週月曜日の朝9時にbundle updateのPull requestを作っているそうです。

次のようなことをしているそうです。

1. gemごとにcompare linkとリリースノートのURLを全部書き出す
2. リリースノートがある場合
   • 内容に応じて読む強弱をつける
3. リリースノートがない場合
   • 変更の中身をみる

プロダクトのコードを読むより先にテストコードを読むと理解が早いそうです。

感想

テストコードを先に読むのはなるほどと思いました。 わたしはテストコード読むのが苦手だなって気持ちがあります。 テストコード何をテストしているのか分りにくいものが多いなーって感じです。 逆に言うとテストコードは意図が分りやすいように3-phaseを守って読みやすいコードを心掛けたいなと思いました。

どうやってコードを読んでいるか

shinsokuさん

よく使うツール

• ghq
• enhancd + peco

感想

gem-srcではなくghq派もいるのだなーと思いました。

RubyMineの便利機能を紹介してみる

森塚真年さん

RubyMine使っている人意外といました。

森塚さんのお勧め機能は以下のようなものでした。

• rails consle(デバッグモード)
• Find in Path(= grep)
• annotate(= blame)
• RubyMineでPull requestが見られる
• ストラクチャ(ファイル内のアウトラインが見られる)
• クラス図の作成

感想

ちょっと便利さがよくわからなかったです。他のツールでもできそうなものだったのでマウス捌きに自信のないわたしには無理そうだと思いました。

Visual Studio Code で効率よくコードを読む

HolyGrailさん

今度はVisual Studio Codeの話です。

拡張機能にたよる

• Ruby
  • シンタックスハイライト、デバッガーなどの基本的なRubyの補助機能
• Bracket Pair Colorizer
  • 確固の対応が分りやるく
• Ruby Solargraph
  • Rubyのlanguage server
• Bust A Gem
  • gemへのコードジャンプ支援
  • gem install ripper-tags
• GitLens
  • コードの横にblameを表示してくれる

感想

Bust A Gemは便利そうと思ったけど、ripper-tagsを使えばvimでも出来そうなので乗り換え機運は来なかったです。

実例で見るコードリーディングのすすめ

makicamelさん

https://speakerdeck.com/makicamel/lets-enjoy-code-reading

世界中の人(人口69億人)で2人ずつペアをつくってじゃんけんをして勝ち抜き戦をしたら33回勝てば優勝できるそうです。

2**33 > 69億

Integer#powerのMRIのソースコードを読んでみたらCで書かれていてよくわからないので、Rubinusのコードを見たらRubyのコードだったので読めそうだと思ったそうです。

簡略化したメソッドを書いたり、printデバッグしたりしてアルゴリズムを理解して解説されていました。

感想

メソッドを簡略かしてみるというのは良いアプローチのように思いました。ロジックの理解にはロジックに絞りこんで理解できるようにするというのはいいですね。 逆に書くときにはロジックはなるべく分離されていたほうが読みやすくなるように思いました。

ActiveRecordのコードを読んでみる

おしょーさん

http://secret-garden.hatenablog.com/entry/2019/12/01/154607

いろいろなテクニックを紹介されていました。

• Method#source_location
  • 2.7だとmethodを表示するだけでsource_locationが含まれている
• p __method__
  • $debug = trueと後置のif $debug
• using BindingDebug
  • https://github.com/osyo-manga/gem-binding-debug
• vimで検索数を表示
  • これどのpluginでやっているのか聞くのを忘れていました
• binding.irb
• caller

感想

私もprintデバッグ派なので好感持てました。

ソースコードリーディング、いろいろな人がいろいろなテクニックを紹介していてとても面白かったです。 また、こういう会をやってほしいと思いました。

追記

vimの検索数を表示するやつはosyo-manga/vim-anzuのようです。(idからしておしょーさん本人の作のものでしょうか？)

vimで検索のマッチ数を表示するのは https://t.co/G187ZvJPqr だと思います。

— ジョーカー1007 (@joker1007) January 9, 2020