nantekkotai's blog

おもに技術とお仕事に関連することを書いています。

大事なことは、できるだけラクをすること。

仕事で受け入れテスト的なものを用意しようということに、個人的になりまして、今日は一日CasperJSについてあれこれ触ってました。

候補としては他にもcapybara-webkitとかnightwatchとか調べたんですけど、なんかめんどくさそうだし、なんというかサクッと理解できなかった。というかCasperJSの使い方がすんなり頭に入ったので「これだな」という感じで決めました。

実際使ってみて「イケそうだ!」という感覚を得られたわけで、明日から(というか明日中に)ガリガリと必要な分の受け入れテストを書くつもりなんですけど、この「なんとなくイケそうなので選んでみたら、やっぱりイケました」という感じは以前にもあって、それはKnockoutJSを採用したときもそうだったなと思い出したわけです。

KnockoutJSの選択

クライアント側のフレームワーク使って作りたいな、という案件でした。
2年くらい前で、当時は「JS?フレームワーク?だったらBackboneだろう」という感じでしたけど。
でも僕は、双方向データバインディングでMVVMなKnockoutの方を選択したわけです。

いろいろ理由をこじつけて選択したわけですけど、一番の理由はすんなり理解できたから。そんでラクそうだった。
実際ラクでした。それはもう、jQuery的なラクさ。

選択の基準はラクさ

大事なことは、CasperJSにしろKnockoutJSにしろ、自分にとってのラクさで選んだと言うことです。
もっとスキルのある人たちなら、違う選択をしたかもしれない。長い目で見て、別の選択肢(BacknoneやAngularJSとか)を選んだかもしれない。
自分がプログラマとしては平凡なのと、コードよりもプロダクトの方に関心があるということもあって、目的を達成させる工程に関しては自分が理解しやすいものを選ぶ、そう考えたわけです。

で、何が言いたいのかというと、

本当に解決したい課題以外のことは、できるだけラクな道を選んで良い。

ということです。

集中するためにラクをする

自分にとって「それこそが解決したい課題である」と呼びたいものに集中する。 ここに関わるもの以外はすべて、ラクしていい。
ズルと言ってもいい。
それくらい割り切って、選択して良いのではないか。

自分にとって大事な課題に集中できるのであれば、へぼプログラマと呼ばれようがクソエンジニアと思われようが何だって構わないのです。

自分が見つけた課題。
それを解決するときに生まれる価値。
そこから生み出されるチームへの貢献。

それぞれの人が、それぞれの課題に集中できるようになること。
それが理想かなと思いました。