私はエンジニアとして、既存のライブラリやプラグインの使用は最低限に留めたいという考えがある。ここでいう最低限に含まれるものは、jQueryやReact.jsなど、実装の基盤となるようなライブラリや、細かなモーション調整に使うTweenMaxのようなアニメーションライブラリだ。
私は個人でも受託制作の仕事をすることがあるが、実務経験の少ない方のヘルプか、実装は全て任される案件が多い。そういう案件は限られたコストでなるべく早く実装してほしい、という意図のものが多く、大体が作って終わりになるか、実装したものを別の人が引き継ぐことになる。
その場合、ベイジの案件同様、開発には開発用ファイルを用意して、最新技術を使用しコンパイルして、機能実装は全て自前で…という進め方だとオーバースペックであり、自身の手を離れた後に運用する人はその環境について学ぶ必要があるため、開発速度と運用コストの両方で悪影響が生じてしまう。そこで悩むのが、既存のライブラリやプラグインを利用すべきかどうか、だ。
一例をあげると、既存のjQueryプラグインを使わないのが良い選択かどうか。
jQueryのカルーセルは今だとslick.jsが有名だ。これはベイジで制作しているカルーセルの動きを一通り網羅しており、初心者でも引数を指定すれば簡単にカスタマイズできるようになっている。プラグインを導入し実行するよう記述すればすぐに動き、容量は42KBほど。
一方、各案件で自力で作っているものは、案件に必要な最低限の処理のみ記述されている。そのためSlick.jsのような柔軟性はなく、引数の種類が乏しくドキュメントもないため初心者には改修しづらい。また、自力でカルーセルを実装する工数が必要になる。容量はwebpackのコードを含んでも6KBほど。
容量の差がかなりあるものの、それがパフォーマンスに対してどれほどの影響があるのかはこの日報では追わないが、実際にこの機能に触れるそれぞれの視点で考えてみようと思う。
まず、ユーザーにとってはどうだろうか。必要な機能が動作し、軽く、操作性を損ねず使い勝手がよければよいだろう。つまり、自作か既存かといった違いはどうでもよい。
クライアントにとってどちらが良いかはクライアントの性質によって変わるが、我々の手を離れた後の改修のしやすさや工数削減を考えると、ドキュメントが用意されており、その通りに調整すれば正しく動作することを保証されているプラグインの方が良い場合もあるだろう。
会社としては、自作のほうがよい。自分たちで実装したコードであれば、実装者は解説することができ、他のエンジニアがどういうコードを書いているかを見てベイジの書き方に慣れてくると、どこでどういうことをしているのか推測できるようになる。また、自社案件に特化した調整が加えられていることもあり、細かい仕様の変更なんかは自作の方がやりやすい。
これは例えば、新入社員がベイジのコードに慣れるうえでも役に立つ。もしプラグインを使っていたならば、誰もそのコードが何をしているのか説明できないし、1からコードを追う必要があるだろう。そのプラグインが多機能であればあるほど、その作業は面倒だ。また、時間をかけたくなくてつかうのだから、わざわざプラグインの中身を読み解こうともしないだろう。
個人的にはプラグインを気軽に使う文化を根付かせたくない。内部で何をしているのかわからないコードほど怖いものはないし、修正が発生したときに作業が難航することも考え易い。これは偏見かもしれないが、プラグインを多用しているサイトを見ると初心者が実装したのだと感じる。他人のコードを読むのはエンジニアなら誰しもがすることであり、少なくとも自分は他人にそういうコードを見られると恥ずかしい。
ただし、個人で請ける仕事ではクオリティやユーザーのことより、開発速度を求められる場合がある。そのときに「いや、それでも私は自力で全部つくるんだ」では結果として良いコードであっても「あの人は仕事が遅い」となってしまう。そして結果をださなければ、次はないだろう。このあたりは仕事の特性によって考えていく必要があると思う。
一番理想の回答としては、自分たちでプラグインレベルのものを作成してしまうことだ。どの案件でも使いまわせて、必要な機能だけ持ってくればいいようなものをつくる。内製するから誰もわからないコードになるリスクも低い。エンジニアとして目指すべきところはそこだろう。
一番よくないのは、自分で実装できないからプラグインを使うということだ。それは完全に成長の機会を捨ててしまっているしもったいない。
社内でも汎用性のあるコードはライブラリとして管理していこうという動きがあるが、今の段階でいうとなかなか進んでいない。そのあたりも充実させてクオリティと速度両方を担保できる実装をしていきたい。
