実務開始から半年もたってないよわよわエンジニアが「ES6で書かせろ」とわめいた話

2021年1月より、主にLaravelを使ったシステム開発案件に参加させていただいています。
現在参加している案件で3つ目となり、まだまだ経験は浅い状態です。

どのように開発しているか

僕が働いている会社では、Web制作とシステム開発の両方を行っています。
会社に入ってくる案件の9割はWordpress案件で、全体の比率を見ていてもディレクター、コーダー、デザイナーが多いなという印象。
そうした業務を行う人がいる傍ら、専門的にシステム開発業務に携わる人もいます。僕も今のところそんな感じです。

システム開発を行う際の編成はこんな感じ。

• 責任者：開発部の部長。Laravelとインフラにめちゃんこ詳しい。JSはやらない。
  • コーダー：Web制作と兼務して画面のHTMLコーディングを担当している。JSはアニメーション系のみ。
  • Laravel担当：処理を書いてBladeで画面も作って、さらにJSも書く
    • 自分
    • 入社3年目？4年目？の人

使用する技術は大体こんな感じ。

• バックエンド
  • Laravel8
  • MySQL
  • CentOS
  • Apache
  • さくらVPSやAWS EC2
• フロントエンド
  • Laravelのテンプレートエンジン
  • jQuery

2つ目の案件でJSに我慢ならなくなった

始めに申し上げると、僕は重度の「不便さアレルギー」です。
セルフレジでキャッシュレス支払いすれば並ばなくていいのにわざわざ並んで現金支払いをする人の正気を疑ってしまう、ちょっと極端な人間です。

そういう前提と、そもそもLaravel・JS共に経験の浅い未熟な立場というのもあるわけですが、現状のフロント開発に関しては「でもさすがにこれはないだろう」と感じざるを得ませんでした。

何が嫌だったかというと、

• ES5の構文しか使ってない
  • もう一人のLaravel担当さんはES6の構文を知らなかった
• コードが見づらい＆直しづらい
  • 同じセレクタを、なぜか変数化せずに使いまわす
  • クラス名ではなく$('input name=["hogehoge"]')とかでとってる場合、inputが複数種類あるとかなり見通しが悪い
  • そもそも要素数が多く、クラス属性の命名がしんどい
  • ひとつのイベントに長大な処理が書いてある（何に対してどんな処理がいくつあるか把握しづらい）
• 外部ファイルに分けない
  • 「ここでしか使わない処理であれば、Bladeの一番下にscriptタグで直接書く方がいい」という考え方
  • その処理が結構長い
    • （APIを叩いてjsonをとってきてHTMLを生成する処理）
    • （その生成した要素に対する様々なイベントたち）
  • インラインで書いたJSが他のページで必要な時は、そのBladeにコピペしてくる
  • 変数化してないセレクタに関しては、そのページのクラス属性などに合わせて呼び出し部分を書き換える
  • ページの仕様が変わった場合は、コピペしてる場所の数だけ修正する

基本的には構文うんぬんの前に本質的な書き方の問題です。ちなみにコーディング規約も定まっていません。

ただいくら問題があるとはいえ、自分の立場からいきなり「先輩のコードの書き方」や「開発の体制」そのものに物申すことはできませんでした。全然戦力としては不十分な立場なわけだし、不満を感じている人が自分しかいないというのも分が悪かった。そういった政治的事情もあって、「ES6の記法を取り入れようという提案」くらいが、角が立たず学習コスト的にも許容範囲なのではないかと考えたわけです。

ぶつかった壁

現在進行形の話も含めて、なんだかんだハードルはあります。

提案した当初はあまり理解を得られなかった

今回の案件は、一社だけが使うシステムではなく、複数の企業間で情報をやりとりするためのSaaSのようなものです。
そのためIE11にも対応しようということになり、提案した当初は「ES5のままでいきましょう」と却下されてしまいました。（Babelを使う方向で食い下がってなんとか承認してもらいました）

JSのコーディング規約を決めたことがなかった

システム開発をするうえで、JSに限らずコーディング規約を定めたことがほとんどなかったようです。
Laravelに関しては「コントローラーにはDBを叩くような処理を書かない」「データをいじるメソッドとDBに保存するメソッドは分ける」などの習慣はあったものの、JSに関しては「やる人が自由に書く」という感じで、あまり保守性や可読性についての精査をしていませんでした。

これに関しては、僕の担当分のJSをES6を一から勉強して書いた上で、規約の案をドキュメントにまとめて共有しました。

品質管理が難しくなった

社内にはES6で書けるWebディレクターさんや、もっとJSに詳しくて、ReactNativeでモバイル開発などもできるすごいエンジニアさんがいます。

でもその方たちは他のWeb制作案件に参画したり、アプリも作る案件の場合にReact Native担当として参画することはあっても、システム開発のフロントエンド実装には関わることがありませんでした。
加えてコードレビューをする文化がないのもあって、「ES6が便利なのはいいけどお前のコードの品質は誰が保障するんだ」という問題が浮上。

これに関しては「いうてもvarがconstになったり処理をクラスにまとめてるだけで、大きく違いがあるわけじゃないので……」と誤魔化しましたが、正直なところ未知数です。コピペをやめただけでも保守性は上がるから悪くはないと思うのですけど。

今後について

まだ案件は終了していないのでこれからどうなることやら。

しかし学んでみると、見様見真似ではあるもののクラス構文は便利でした。これまでの書き方では対応できない部分でも、ググってアロー関数やthenによるコールバックなどを知ることでなんとか対応できています（今のところ）。

僕自身ES6の構文を使うのが初めてですし、他の担当者の方の懸念材料となってしまっているのは申し訳ない限りではあります。可能な限りがんばります。

この後、既存実装のリファクタリングと新規実装・IEも含めたブラウザテストまでどうにか終わりました。
(ユニットテストの実装がかなり遅れてしまったので全く無傷ではないのですが…)