フロントエンド開発がうまくいかないときに読む記事
フロントエンド開発って、簡単なようで難しく、浅そうで意外と深い、見た目と中身に大きくギャップがありおもしろいなーと常々感じます。
そんなフロントエンド開発ですが、過去 30 を超えるプロジェクトで働いてきた自分としては、まーどこのプロジェクトも驚くほどうまく回ってないなぁと。
あまり偉そうなことを言いたくはないのですが、それでもこの数年間、フロントエンド開発の正解についてある程度考えてきたつもりではあります。
そして今携わっているプロジェクトでは、ほぼ実質的にフロントエンドのリードプログラマーを務めさせてもらっているのですが。
自身が関わる前と関わった後でプロジェクトの中身は一新され、開発の工数が 1 /3 程度にまで抑えられるようになった感触があります。
ということで、今回はフロントエンド開発のコツから、ひいては円滑なプロジェクトの運営についても少しだけ触れつつ、現段階での自身の考えをダラダラーっと書いていこうと思います。
共通化なんてするな
フロントエンド開発を進めていると、よく共通化という単語を耳にします。
多くの場合はコンポーネントに対し共通化という表現が使われているようですが。
自分の経験上、コンポーネントの共通化は不要だと考えています。
コンポーネントを切り出す粒度というのは、一定のルールに沿って行うべきであり、なんとなーくで行うものではありません。
そして過去の経験上、まともなルールの元コンポーネントの共通化が行われていた現場というものは 1 つとして存在していませんでした。
秩序の存在しないコンポーネントの切り出しは、混乱しか生み出しません。
もしあなたが Atomic Design をバカにしているフロントエンドプログラマーであれば、コンポーネントを正しい粒度で切り出すことは一生不可能だと思います。
もしあなたが Atomic Design を素晴らしいデザインシステムだと理解していたとしても、あなた以外のフロントエンドプログラマーや Web デザイナーは残念ながら理解できていないため、コンポーネントを正しい粒度で切り出すことは厳しいことに気づいていると思います。
これはコンポーネントに限らず、カスタム Hooks やその他の処理に関する共通化も同様です。
基本的にフロントエンド開発において共通化は不要です。
もしあなたも共通化は不要だという意味がわかりましたら、はじめて適当なタイミングで、適当な粒度で共通化を行って良いときなのかもしれません。
テストなんて書くな
現時点における Frontend Developer Roadmap によると、テストに使用する推奨パッケージは以下の通りとなっています。
- Jest
- react-testing-library
- Cypress
- Playwright
で、個人的にはここに Storybook を加えたくらいがベストチョイスかなーと思っています。
が、それ以前に、基本的にフロントエンド開発においてテストなんて不要だと思っています。
もしあなたの開発しているプロダクトが、一切の処理のミスも許されず、超リアルタイム性が求められ、少しの行動がめちゃめちゃ株価に影響するようなプロダクトであれば話は別です。
一方で、もしそういったプロダクトの開発を行っていないのであれば、テストなんて書かなくて良いです。
世の中にはさまさまなドキュメントで「フロントエンドにもテストは必須！」みたいに偉そうな書かれていますが、あんなものは無視で良いです。
フロントエンドに限った話ではないですが、テストを行う際は、行うことによるメリットとデメリットをしっかり比較した上で、メリットのほうが上回るのであれば行うべきです。
なんでもかんでも脳死で導入すれば良いってものではありません、それくらいテストの導入というのは膨大なコストがかかります。
知識として持っておくことは大切ですし、ケースバイケースで導入を行うことも大切です。
柔軟性を持って導入を行えば良い思っていますが、基本的には導入しないほうがメリットは大きいのかなーと感じることは少なくないです。
CSS フレームワークを使うな
CSS フレームワークというのは安易に使えるものではありません。
日本のフロントエンドの現場ではめちゃくちゃ安易に CSS フレームワークを導入しがちですが、まともに使いこなせている現場を見たことがありません。
CSS フレームワークというのは、読んで字の如く、CSS のフレームワークです。
つまり、CSS を理解した上ではじめて使うことが許されるパッケージですが、果たしてあなたの現場のフロントエンドプログラマーはみな CSS をきちんと理解しているのでしょうか。
また Web デザイナーが在籍する現場であれば、言わずもがな Web デザイナーもしっかりと CSS を理解している上で CSS フレームワークを前提としたプロトタイプを組むことが求められます。
残念ながら日本の Web デザイナーのほとんどは、CSS フレームワークはおろか、HTML や CSS ですらまったく理解していません。
またコンポーネント設計もまったく理解していないですし、理解の必要性すらも理解していません。
そんな状態で CSS フレームワークを導入するなんてちゃんちゃらおかしな話です。
おとなしく CSS Modules あたりで実装を行うのが間違いなく無難です。
サーバーサイドを使うな
仮に Next.js を使った現場であれば、サーバーサイドにおける Fetch などは避けたほうが無難です。
React を用いた開発を行うばかり、現時点では Next.js を用いた開発を行っている現場は決して少なくないと思いますが。
残念ながら Next.js の仕様を、ひいてはサーバーサイドの仕様をきっちり理解して開発を行っているフロントエンドプログラマーはあまり多くない印象です。
サーバーサイドの仕様を理解しないまま Next.js を使うと、なかなか痛い目に合いますし、実装もうまく進みづらいです。
自分が現在携わっている現場でも Next.js が使用されていますが、残念ながらサーバーサイドについてきちんと理解できているメンバーが在籍しておらず、日々メンバーに対し Next.js の仕様をこんこんと説明しています。
慣れないうちはおとなしくクライアントサイドで Fetch を叩くようにして、その後最適化を行うのが無難かなぁと思いますが、どうなんでしょうか。
Redux を使うな
流石に Flux 系の状態管理パッケージを使っているプロジェクトは減ってきたと思いますが、それでもいまだにちらほら見かけることがあります。
世界的に見ても Redux やそれ系統のパッケージはもう誰も使っていません。
現時点では無難に SWR や React Query を使えば十分です、グローバルな状態管理であれば Context で十分です。
たかだかフロントエンド開発です、複雑な技術に頼らず、シンプルでわかりやすい技術を使うように心がけましょう。
努力をしよう
フロントエンド開発がうまく進まないもっとも大きな理由は、あなたもしくは開発メンバーの知識不足がほとんどです。
驚くことに、日本のフロントエンドプログラマーの大半はフロントエンドに関する知識を持ち合わせていません。（知識を持ち合わせていないメンバーをフロントエンドプログラマーと呼んで良いのかはともかくとして）
フロントエンドの知識を持っていない先輩がフロントエンドの知識を持っていない後輩を見ているわけですから、そりゃーフロントエンドプログラマーが育たないわけです。
で、過去何度か同じことを書いてきましたが、仕事をこなしているだけはフロントエンドに関する知識は残念ながら伸びません。
自身の経験上、フロントエンド開発を最初から最後まで通しで行うことを何度も繰り返して、少しずつフロントエンドプログラマーとして成長していくことができます。
ところがこれが仕事となると、プロジェクトを立ち上げることができるのは 1 人しかいませんし、いつの間にか環境ができあがっているみたいなことも少なくありません。
また環境以外にも、リポジトリに対し強い権限が与えられておらず設定周りを見たりいじったりすることができなかったり、正しいかどうかもわからないコードを強制されたりして、こんな状態で成長もクソもありません。
人間は失敗から成長する生き物ですが、仕事ではなかなか大きなリスクを採ることは難しく、どうしても保守的な開発になってしまうのは当たり前のことです。
なので、フロントエンドの技術を伸ばすには、どうしてもプライベートでの努力が求められてきます。
自分もプライベートで開発をはじめた当初は、驚くほど右も左もわからず、自分はこんなにも何も理解していなかったのかと、強烈に反省したことがいまだに記憶に強いです。
自分はこの数年間で、プライベートで何本かの Web サイトや Web サービスをリリースしてきましたが、その裏で 100 本を超えるプロジェクトを立ち上げてきました。
表に出ているものは本当に一部でしかなく、自身の経験不足や調べが足りなかったばかりに開発を挫折してしまったものもたくさんあります。
とはいえ、この数年間、プライベートで勉強していなければフロントエンドプログラマーとしては厳しかっただろうなーと強く感じますし、今後も勉強の手を緩めるつもりもありません。
もしあなたの仕事におけるフロントエンド開発がうまくいっていっていないのであれば、それはあなたの努力が足りていない可能性は決して低くないと思います。
そんな感じです、ちょっと偉そうなエントリーになってしまい申し訳ないです。