ライブラリやフレームワークを早く使いこなす方法

ライブラリやフレームワークを早く使いこなす方法

このブログでは自分なりに得た個人開発についての方法論をいろいろと紹介している。全工程を自分でやらなければならない個人開発は、自身の能力を底上げするのに最高の方法でもある。その過程で、アプリをよりよいものにするために新しいライブラリやフレームワークの導入を検討する事も多々あるだろう。

コードを書く時間というのは実は意外に短くて、基本的に作業時間の40%以上は勉強や調べ物に費やされる。以前、WakaTimeというコーディング時間を計測するサービスで計ってみたら、週に20時間程度しかやってなかった。となると、ドキュメントを読む時間やそれを理解する時間は、場合によってはボトルネックになりうるという事だ。言い換えると、ライブラリやフレームワークの使い方を素早く把握できれば、仕事の速さが大きく向上する。

本稿では、技術の使い方を素早く把握して手早く自身のプロダクトに適用するための考え方をシェアしたい。

まず技術を学ぶことは目的ではない事に注意する。アプリを作ることが目的なので、使いたい技術の全容を把握する必要は全くない。超初心者はともかく、本を買ったりして1ページ1ページありがたく目を通すなど時間の無駄。本を読んでいる自分に酔っている事に気づいた方がいい。基本を把握したら、あとは分からないところを掻い摘んで調べればいい。

知らないことを恐れる必要はない。エラーにぶつかることも恐れる必要はない。自分は今もしかしたら非効率だったり間違ったやりかたで作っているかもしれないという不安を受け入れる。ハードウェアだと間違えば壊れてしまうリスクがあるけど、ソフトウェアは何度でもリセットできる。

何かと教科書のようにまとまった情報を求める人がいる。確かに部分的な知識で車を運転すれば死の危険があるけど、ライブラリを誤って使って死ぬことはまず無い。だから「なんだこのAPI？叩いてみよう」ぐらいの気軽さでいい。

一般的に広く使われるフレームワークやライブラリは、その使い方に綺麗な一貫性がある。なぜなら、不規則で全部まる覚えしなければならないような技術は使いづらくて人々に受け入れられないから。

すごく単純な例を挙げると、PHPにstrpos(A, B) という関数がある。この関数は、 A で指定した文字列の中から B を探して、何文字目に見つかったかと返すもの。添字はゼロ番目から始まる。つまり、3文字目に見つかれば2が返る。さて、もしBが見つからなかったら何が返る？

答えはFALSE。これは覚えるしか無い。じゃあ次、 array_search(A, B) という関数があって、これは B の配列から A を探して、何番目の要素に見つかったか返す。さて、要素が見つからなかった時の戻り値は NULL か、それとも -1か？

いやいや、答えはFALSE だ。NULL か -1 かという選択肢に違和感を覚えた人は要領がいい。もし素直にうーんと悩んじゃった人は、教科書的に丸覚えしようとしている。strpos も array_search も中身を探すという内容の関数なんだから、見つからなかった時の戻り値がもしそれぞれ違ったら設計に一貫性が欠ける事になる。だからおかしい、という考え方が重要。

PHPには他にも strrpos という似た関数がある。見つからなかった時の戻り値は…もうドキュメントを読まなくてもお分かりだろう。

いい技術は名前にもしっかり一貫性がある。だから全部覚えなくてもなんとなく「こういうメソッドを探してるんだけど、こんな名前でありそうだなー。ほらあった！」と推測できることが大事。

例えばElectronのBrowserWindowというクラスには沢山のメソッドが用意されているけど、命名規則がしっかりしていてとても探しやすい。ウインドウを最大化する maximize() というメソッドに対して、最大化されているかどうかを調べる isMaximized() というメソッドがある。もうお分かりのように、 minimize() と isMinimized() も同じく用意されている。

まぁ最大化と最小化も出来るんだからフルスクリーンもこのクラスで出来そうだよね、ほら setFullScreen() と isFullScreen() があった。と、こういう感じで推測していく。もしフルスクリーン処理だけ別のクラスに用意されていたら、設計がおかしいか何か別の事情があると考える。

このように、相手の気持ちを慮れる人の方が人付き合いが上手いように、設計者の気持ちを想像できる人の方が技術と上手く付き合える。

上記で述べたような法則は、典型的な良いソフトウェアの特徴。だから自分がコードを書くときも同じようにルールを意識すると、後々助かる事が沢山ある。なぜなら、一ヶ月後の自分は別人だから。

時間が経って綺麗サッパリ忘れた自分が過去の自分のコードを読み取る時、簡潔なルールに沿って書かれていれば、「あの処理はあそこにあるっぽい」とすぐに把握して作業を再開できる。サーバを書いて、クライアントを書いて、一ヶ月後にまたサーバを書く、という事はざらにある。その場しのぎのコードは身を滅ぼす。継続的に個人開発していくためには、自分の過去のコードをすぐに把握できる事がとても大事。

この記事があなたの個人開発の手助けになれば嬉しい。

使ってね！！