ソースリーディングの勧め
プログラミングを学習する際は手を動かしてコードを書きましょう。
— 98hira (@crenscent) 2019年4月9日
とよく言われる。
これも本質だとは思うんだけども。。
自分にはあってないことが分かった。
とりあえずコード書いてみるんだけども。。。クソコードを生産しているだけな気がしてストレスしかない。。。
上記のような思いがあった時に、「ライブラリやフレームワークのソースコードを読んでみよう」というテーマの登壇イベントを見つけて参加してきたので、印象に残った部分と概要をまとめました。
個人的に印象に残った箇所
OSSやフレームワークのソースを読むことで、設計思想を学ぶことができる。
→正直1個人でより良い設計を考えるより、天才達が議論に議論を重ねてできた、OSSのソースを理解することに努めた方が勉強効率は遥かに上だと考えています。
コードを読み解くスピードが上がる。
→実際の現場で働くと、スタートアップ企業にでも勤めない限り、1からソースを書くことは殆ど無いと思っています。大抵は他人(※)が書いたソースを修正したりカスタマイズしたりするのが主な業務になってくるはず。なので、「ソースを書く力」より「ソースを読み解く力」の方が重要だと考えています。
(※)ここで言う他人には、過去の自分も含まれます。3ヶ月前に書いたソースを覚えていますか？と言う話です。
1メソッド単位でアウトプットする。
→ソースを読んだからすぐに分かるかと言うとそうではありません。いっぱい時間かけて読んだけど結局何も分かりませんでした。では話になりません。なので、ソースを読んで理解する範囲を極力狭くするために、まずは1メソッドの処理を理解する。と言うのはいいなぁーと思いました。
登壇の概要
ソースコードを読むケース
- ドキュメントに記載していない細かい仕様の把握
- アーキテクチャ、設計、設計思想
- 罠、バグ
ソースコードを読むメリット
- ドキュメントだけでは分からない情報を得られる。
- コードを読み解くスピードが上がる。
- アウトプットに繋げることができる。
ソースコードの読み進め方
- 分かったことをコメントに書きながら読み進める。
- 過去のコミットやプルリク、issueを読む。
- 目的を持って読み進める。
- IDEなどの便利機能を使う。
アウトプット方法
どんな処理なのかをまとめてブログに書く。
→1メソッドだけまとめても価値がある。
OSSに参加できる。
→いきなりバグを見つけるのはハードルが高いが、「ここの処理なんでこんな風になっているか分からないのだけどどう思う？」と質問形式のissueを投げる。
登壇できる。
まとめ
コードを読み解く力は「エンジニアの基礎能力」となる力。
なので、技術書を読む感覚でコードも読みましょう。
最後に
クソコードは極力書きたくないですが、クソ文章はいっぱい書いていこうかなと。
