昨年から本格的にフロントエンドエンジニアとして開発に参加し、一区切りついたので、現場で気づいたことや学んだこと、あーしとけば良かったというのを改めて、振り返ろうかと思います。
技術的なお話はないので、さらっと読んでくれれば嬉しいです。
職場環境の変化-転職
今年の4月までとあるベンチャー企業でフロントエンドエンジニア???として働いていたのですが、会社が求めてる適正と自分が持ってる適正が合っていなかったので、退職し、某大手事業会社に転職。
転職時のスキルセット
- HTML
- CSS
- Sass
- 設計(OOCSS、SMACSS)
- JavaScript
- jQuery
- タスクランナー
- Gulp
- モジュールバンドラー
- WebPack(1系)
- Browserify
- 開発支援ツール
- Git
- GitHub
- CMS
- WordPress
上記のスキルセットで今までコーポレートやEC、ソシャゲ、キュレーションなどのサイト構築をしてました。
フロントエンドエンジニアとしての実績/経験
主にjQueryを使って、UI機能(タブやモーダルなど)の実装経験はあったのですが、APIコールして、リソースの取得、作成、更新、削除などWebAPIの開発経験は全くありませんでした。
前職ではAngularを使ったモダン開発に参加してた時期があったのですが、サーバーサイドのエンジニアがフロント実装も行い、自分はUI/UX設計をやっていったので、ディレクティブで表示の切り替えをしたりと、表面的な部分しか触れることができませんでした。
初めての開発現場
最初にアサインされたのはレガシー化してるお問い合わせフォームをモダン化するというプロジェクトでした。
数十年メンテナンスされてなく、年々サービスが増えていくので、サポートの方のコストを軽減させる目的で立ち上がりました。ユーザービューとアドミンの開発があり、自分はアドミン側を担当することになり、使用するライブラリとして、Vue.jsで開発を始めていきました。
開発が未経験ということもあったので、簡単なところから着手し、リソースを取得して、それを編集/保存ができる単純な仕様のものから取り掛かり、基本的な構文やAPIを叩くタイミングなど、業務を行いながら学べました。
大変だったところ
開発が進むにつれ、仕様も複雑になっていき、実装で悩んだり、サーバーサイドエンジニアとのコミュニケーションも頻繁になってくるので、手がとまってしまう事が多くなってきました。
どこで詰まったかと言うと。。。
- コンポーネント間のデータの渡し方・持ち方
- ユーザーアクションに対する状態遷移の対応
コンポーネント間のデータの渡し方・持ち方
今までは小規模な開発だったので、親と子の関係でしかなかったので、大規模になるとコンポーネントの数も多くなり、親子間だけではなく、孫コンポーネントまでネストが発生し、苦行のバケツリレーが発生。
→Vuexで状態管理を行うことで解決。
【参考にした記事】
Vue.js で状態管理 Vuex の基本を学ぶ
状態管理をVuexに譲渡することによって、データをうまく渡すためにコンポーネントの構造を変えたり、親子間データの受け渡しなど余計な事を考えずに、開発がスムーズに進めることができた。
ユーザーアクションに対する状態遷移の対応
ボタンを押したら、テキストフィールドを追加したり、ドラックアンドドロップで順番を変更したりと、データ構造の変化や値の取り出し方などが分かっていなかったので、配列操作やオブジェクトの特性について理解を深めました。
【参考にした記事】
JavaScript Arrayオブジェクトをまとめたよ
JavaScriptのObjectを理解したい
工数見積もりが読めず、スケジュールが立てづらかった
開発経験がないと、記述するコードのイメージが湧かないので、最初工数を出すのがとても難しかった。
ただVue.jsで開発をしていくとフォームとデータを紐付けて、入力値や選択値とデータが常に同期させることができるので、イベントでIDを取得して、さらにループして値を絞り込んで、stateと同期させるとか、余計な事を考えなくていいので、Vue.jsの特性が分かってくると開発終了日がいつ頃になるかゴールが見えるようになってきました。
苦戦を強いられながら、開発が進んでいくのですが、中盤になって、問題が起きました。
定義されたAPIと画面仕様の違い
APIはすでに完成済みだったですが、フロント側の実装中に足りないプロパティや保存時にリクエストパラメータをまとめて送る仕様なのに、IDに紐付いたURIで指定され、過剰なリクエスト数が発生していたりと、UIに合わせた構造、仕様ではないことに後々になって気づき、フロントとサーバー間で認識のずれがありました。
要件定義やAPI設計を見直し
返ってくる値がフロントフレンドリーなAPIではなかったので、サーバーサイドのエンジニアと、もう一度画面設計書と仕様書を見比べながら、一緒に再設計することになったのですが、API設計の基本知識がなく、どういうふうに変更するのがいいか分からなかったので、下記の書籍を購読しました。
【参考にした書籍】
Web API: The Good Parts
UI仕様に合わせた構造を自分なりに考え、扱いやすいデータ構造の提案ができるようになったので、とても参考になりました。
反省点
開発に入る前にエンジニアと、仕様確認やAPI設計の認識合わせを行うべきでした。
これを行うことで、
- 仕様や機能の解釈を間違ったままプロジェクトを進めてしまうのを防ぎやすくなる。
- 設計上の問題も早い段階で見つかりやすくなる。
API連携に入るタイミングで、大きなズレが発覚すると修正が発生し、作業が止まってしまう事もあるので、複雑な機能が多い大規模な画面を作成する場合は、必ずフロント側でもAPI設計のレビューをしたほうがズレや漏れが少なくなると思いました。
あとはフロントエンジニアという立場上、UIにも接してるので、認識のズレがあった時はすぐにサーバーエンジニアに報告して、軌道修正をするように動くべきだと感じました。
最後に
JSよりCSSを書いてる時間のほうが長い案件がほとんどでしたが、今回は逆で始めてVue.jsでAPIを使った開発ができたので、とても貴重な経験ができました。
同時にプロジェクトを円滑に進めるためにはサーバーサイドエンジニアと密にコミュニケーションをとらないと遅延してしまうということも学べたし、自分自身もサーバーサイドの知識を身につけ、共通言語でお話ができるくらいのレベルにしないといけないと感じました。
今後もフロントエンドエンジニアとして、精進していきたいと思います。