Webアプリケーションのコードとか初めて書いたとき,コピペコードを羅列してとにかく動かすということだけを考えてた.
だんだんWebアプリケーションの仕組みとかわかってくると,ライブラリの仕様がよくわからなくてハマったときに,なんとか動かすためにライブラリの外から入力パラメータを変えて出力をみるみたいなことをやっていたり,安易なソリューションを求めてググっていたことがよくあった.
というか今も普通にある.
ハマった原因がそもそも仕組みを理解していないことだったというのもあったと思う.
そんなわけで今使っているライブラリの仕様/動作がよくわからないと思ったときはさっさとソースを読むようにしている.
読もうと思ったやつは,GitHubで管理されているかGitHubにミラーがある場合に,以下のリポジトリにsubmoduleとして突っ込んである.(読みたいものをおいておくためのもっと良い方法があるかもしれない)
こんな感じでいろいろ読んでいると,cho45さんが言っていた,"フレームワークのコードは結局全部読まなければならない"というのがぼんやりわかってきた気がする.
ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく - YAPC Asia 2011
Railsみたいなフルスタックのフレームワークを使うと,(モジュール化されているとはいえ)メタプログラミングを駆使して汎用化されているから,今作っているアプリケーションには不要なレベルの抽象化とかされてて.読むのが大変そう.
できれば,UNIXの思想っぽく,独立した小さいモジュールを組み合わせて,疎結合なアプリケーションをつくりたい. 小さいモジュールならソースを読むモチベーションも保ちやすいし, このモジュールなんか気に入らないと思ったらそこだけ別のものに差し替えるか自分で書けばよい.
だだし,Linuxカーネルなんかは密結合なコードになってて,かなり入り乱れたコードになってるらしい.これを疎結合にするとその分の細かなオーバヘッドが重なって,パフォーマンスに影響するらしいという話をどこかで見た気がする.
パフォーマンスとトレードオフになるの難しい.
速くしなければいけないところとそうでないところを見極めて,前者の場合は少々密結合になってでもパフォーマンスを重視して,後者の場合は疎結合にするというように良い感じにバランスがとれれば良いんだろうけど難しい.