壁
優秀なエンジニアとして生きていくためには、名を挙げなければいけない。その方法として最も明快かつ適切なのが、「優良な OSS を作ること、またはそれにコミットすること」というのは知っている。だが、名を挙げようとする僕の前にはボルダリング的な大きい壁がある。
それは間近に迫っていて、むき出しになっている石の形、配置がはっきりと分かる。この壁は以下の2つがあれば超えられるだろう。
- テストという道具
- コードリーディングのための智と技
テストという道具
テストを自分で考えて書いたことがない。理由としてはただひとつ、面倒くさい。そもそも低い技術力のためか、大きいプロジェクトを作ったことがなく、テストの必要性を感じていなかった。というか今まで自分が作った規模では、目視で確認したほうが絶対に速かった。
しかしそんなのはミニマムな個人開発の話であって、テストという道具は絶対に使えなければならない。規模が大きくなれば、生産性は落ちるし、複数人がコミットするプロジェクトであれば、テストによって自分のコードを担保するのは必須事項だ。
RSpec「未来で待ってる」
コードリーディングのための智と技
他人が書いたコードが読めなければちゃんちゃら話にならない。
まず、書く前に OSS をどんどん読もうと思った。OSS の中でも身近なものがいいだろう、なおかつ Ruby で書かれたもの、と考えるとそれは Gem だった。最近ブログをよく読んでいる人たちの GitHub を見つけて、インプットアウトプットがわかりやすい Gem を選んだ。
「読めない…… 」
def self.method_missing(name, *args, &block) ... end
が分からなくて、調べればこれが何かを知ることはできたが同時に、これが「メタプログラミング」の一部(?)であると見て、「これが常識よねー」感のする OSS 暗黒大陸から一旦退くことにした。実際常識なのだろう。僕のレベルが達していなかった。
とりあえずその辺りの知識がないので、「メタプログラミング Ruby」を読む必要性を強く感じている。というか読む。図書館にあったから借りてくる。
また、コードを追う技術が足りていないことも明らかになった。ソースにアタリをつけて、デバッガでオブジェクトの状態を確認しながら、変数・関数を grep していく。おそらく基本であるこの流れが、「アレこの変数どんなだっけ?」「デバッガの使い方が〜」となっていく。
(偉い人、コードリーディングのスクリーンキャストとかエントリーあげてください。お願いします。)
最近 pry と pry-doc を導入したところだ。こちらの道具の使い方も習得せねば。
壁
次々と現れる壁を適切に登って行くことで、しばらく壁に出くわさない、経験と手慣れた道具だけで超えられるちょっとした段差にしか出会わない状況が来ると思っている。
そう、それこそが
ブレークスルー
まとめ
OSS で名を挙げられる時代。試されるのは自分の能力のみ。
僕がこれからすること。