勉強会のレポート(メモ)です。
参加したのはこちら、「ライブラリやフレームワークのソースコードを読んでみよう！」
会場はサポーターズさんです。
スライドはこちら
本日話すスライドはこちらになります！https://t.co/m5YuIoMdat
— 02 (@cocoeyes02) April 10, 2019
#spzcolab
なぜ読むのか
ドキュメントでわからないことを知るため
読むとわかること
・細かい仕様
・アーキテクチャ 設計
設計方法を学ぶことができる
・罠やバグ
こういうのを読むと
・ドキュメントでわからない情報を知れる。
・ソースコードを読み解くスピードがあがる。
副次的に他の人が書いたソースを読めるようになる。
・アウトプットにつなげることができる。
プロダクトのソースを読むのはだめなのか
プロダクトのソースからサービスやビジネスロジックを学ぶことができるが、
ライブラリやフレームワークの方がいい。
こっちは基本的にオープンソースが多い、そのため会社や所属が変わっても読める。
プロダクトの方は企業機密があったりするので、公開できるようなアウトプットがしづらい。
どうやって読んでいくのか
読む前に事前準備
・ただ読むのはつらいので目的をきめよう
〇〇メソッドの処理について調べようなど。
・ドキュメントがあるなら事前に読んだ方がよい
ドキュメントを読んでおいた方がソースを読んだ時に頭に入りやすい
・どんな処理になっているか自分なりに予想してからやってみる
自分だったらどういう実装をしているだろうと思うと、意外な実装を見つけた時記憶に残りやすい。
・IDE(に準ずるもの)があるとよい (VSやRiderなど)
ソースを読むうえで便利な機能が多い、ジャンプ機能など。
実際に読んでいこう
読むうえで気をつけたほうがいい点
・わかったことをコメントに書きながら進めよう
混乱を防ぐため1行1行書きましょう。(疑問点など)
全てを記憶しながら書くのは難しい、なので頭は読み解くことだけに集中させましょう。
・実際に動かしながら読もう
正しいと思いながら読んでも、実際に動かさないと確証を得られない。
・過去のコミット、プルリク、イシューを読もう
なぜその処理を追加したのかを知ることができる。
ソースコードを読むだけじゃわからないところもより理解しやす。
読んだ後、どうアウトプットにつなげるか
アウトプットできる例
・ブログに書く
どんな処理なのかをまとめてブログに書く。
１メソッドまとめるだけでもいい。
メソッドの数だけブログ記事がかけるのでかぶることはほとんどない。
・OSSに参加できる
敷居が高いと思うかもしれないが、そこまで難しくない。
「ここの処理なんでこんな風になっているのか」をイシューで聞く、
もしバグならプルリクができる。仕様でもどういう思想でそうしたのかを聞くことができる。
・登壇できる
ネタには困らないのでLTでバンバンできる。
もっと深堀すればロングトークもできる。
最後に
コードを読み解く力はエンジニアの基礎能力。
それを養うのに、ライブラリやフレームワークを読むのはオススメ。
読書くらいの感覚でいい。
わからないことは聞いて、わかったことはアウトプットしていって。
エンジニアとしての価値を高めていきましょう。
質疑応答
Q. 読むきっかけはどう決める
業務やプライベートで使うもの、よく使うメソッドが優先的にきめています。
いままで使ったことのないものよりも、イメージしやすく、モチベが出る。
Q. 疑問に思ったところのイシューやプルリクはどう見つける
githubの場合、blameという機能でコミットの一覧がでてきます。
「どんなのコミットをしたのか」とコメントを見ることができる。
コミットメッセージによってはタグがあり、そこからプルリクエストをみることができる。
Q. アウトプットする時、どの程度までまとめる
メソッド単位でやっています。メソッド内で使われているものを解説します
小分けにすることで見やすくなります。
