絶対に破綻しないフロントエンドプロジェクト

2020-07-19

フロントエンド開発って、どこの現場も大なり小なり破綻しています。

破綻している原因自体はシンプルで、単純に技術不足、知識不足に尽きます。

現場に技術者が存在しない、でもプロジェクトは破綻させたくない、そう考えるのは至極自然なことだと思います。（少なくとも自分はそう思います）

とはいえ、どうすればフロントエンドプロジェクトが破綻せずに済むのか。

答えは結構簡単で、余計なことをしなければプロジェクトってそうそう破綻しません。

例えば開発環境を整える際のパッケージ選定で。

create-react-app を選ぶのか、Next.js を選ぶのか、みたいな場面は多いですよね。

で、特に static なサイトにする理由もないのに、特に ssr が必要なわけでもないのに、なんとなーく響きに魅せられて Next.js を選んじゃう。

よくあるケースだと思いますが、これが破綻への第一歩です。

Next.js って、このブログでは何度も書いてきましたが、選択肢としてはそこまで強くないと思っていて。

大体のケースで create-react-app で十分です。

Next.js を選ぶときは、Next.js でないと困るから選ぶ選択肢なのです。

にもかかわらず、安易に Next.js を選んでしまったせいで、学習コストがかさんでしまう、みたいなケースがあまりに多すぎるよなーと。

create-react-app すら理解できていないのであれば、まずは create-react-app を選びましょう。

その後、開発途中に Next.js でないと要件が満たせないことに気づいたのであれば、その時移行すれば大丈夫です。

create-react-app できちんと組んでいれば、そこから Next.js への移行はそこまで大変ではないと思います。

例えばスタイリング周りで。

現時点での主流は styled-components と css-modules のいずれかで、どちらかを選べば保守しきれないみたいなことには基本的にはならないと思っています。

特に css-modules について、create-react-app と Next.js では何の設定を追加する必要なく、デフォルトで動作するように設定されています。

両方とも公式サイトにその旨が書かれていますし、普通に考えればそれにべったり乗っかれば何の問題もないはずです。

にも関わらず、なぜか BEM を書いたり全てのスタイリングをグローバルで行ったり emotion やら styled-jsx やらを導入するプロジェクトが山程あるのはなんでなんですかね。

公式サイトにデカデカと書かれている方法を無視して独自の方法を導入するのって、自分には理解できません。

もちろん、BEM やグローバルなスタイリングや emotion や styled-jsx を否定するつもりは 1 ミリ足りともありません、素晴らしい考え方であり、素晴らしいパッケージです。

ただ、よっっっっっっぽど BEM やグローバルなスタイリングやそ主流ではないパッケージを使わないといけない理由があるのか。

スタイリングの保守でやたら時間がかかるプロジェクトは、大概技術者が公式サイトを読んでいなくて、己が正しいと信じ込んでいるケースがほとんどだよなーと。

余計なことせず、まずは css-modules で組めば 95%うまくいきます。

例えば api 周りで。

フロント側の api 周りを手動で書いている現場なんて存在しないですよね？

スキーマファーストで開発すれば、Rest api だろうと GraphQL だろうと関係ありません。

手動で api の呼び出しを書く、なんてことはありえません、それはどんなプロジェクトであっても関係ないです。

Rest api なら swagger や open api を使えばフロント側だけでなく、バックエンド側も api 周りが自動生成されます。

スキーマファーストって今やデファクトスタンダードだと思っていて、むしろ導入していないプロジェクトって恥ずかしいよなーと。

api 周りを手で書いていたら、時間もかかるしやり取りに齟齬も発生するし書き間違いや追従に追いつけずバグが発生するし、良いことなんてこれっぽっちもありません。

スキーマを導入する、これはもう酸素と同じ、ないと死んでしまうくらいのものだという認識です。

api 周りを手動で書くということは、本来やらなくて良い、余計な仕事をやっているわけで、仕事をサボっているのと何ら変わらないと思っています。

そもそも型チェックで。

未だに flow を使っている現場がありますが、さっさと TypeScript に移行しましょう。

もし移行にやたら時間がかかるプロジェクトがあれば、それは技術者がきちんと仕事をしていない証拠です。

確かに、プロジェクトの規模に比例して、移行に多少時間がかかるかもしれません。

とはいえ、移行したらモダンな書きっぷりと堅牢なプロジェクトを得られるわけで、これってメリットしかないですよね。

フロントエンドの現場の 8 割近くは、型周りがぐしゃぐしゃです。

過去の経験で言うと、未だに flow で頑張っていたり、全ての型に any が割り当てられていたり、全ての型がグローバルで割り当てられていたり。

確かに React × TypeScript の書きっぷりに関するドキュメントが薄いのは認めます。

けれども、例えば create-react-app であれば、きちんと公式サイトにサンプルコードへのリンクが貼られています。

これを読めば、少なくとも大きく外すことはないはずです。

にも関わらず、こういったドキュメントを読まないから、きちんと調べないからおかしなコードを書いてしまうわけで、結果プロジェクトが破綻しちゃうんですよね。

最後に、フロントエンド開発に限った、絶対に破綻しないプロジェクト設計をば。

create-react-app で環境を作る
TypeScript を導入する
スタイリング周りは css-modules で行う
1url のパスに対し 1component（以下 page component と書く）を割り当て、そこにロジックとスタイリングを全て乗っける
page component 以外の component を作成しない、最上位の index ファイルで大枠のルーティングを行う
css ファイルの class のネストは 1 階層までとする
redux を導入しない
hooks や utils、helpers や constants など、新たなフォルダやファイルを作成しない

フォルダ構成は以下のとおりです。

src
├── pages
│ ├── about
│ │ ├── style.module.css
│ │ └── index.tsx
│ ├── contact
│ │ ├── style.module.css
│ │ └── index.tsx
⋮ ⋮
│ ├── style.module.css
│ └── index.tsx
└── index.tsx

良し悪しはともかくとして、これで 8 割くらいは破綻しないと思います。

危ない点としては、スタイリングの class 名が被りがちなのと、ページをまたぐ要素（localstorage など）がちょっと危ういくらいです。

が、スタイリングに関しては 1 つの component 内で全て完結するため、BEM のような冗長な class 名をつけざるを得ない件はともかく、破綻自体は起こさないですね。（なら styled-components を導入しろよって話になりますが）

コンポーネント志向に真っ向にぶつかるようなプロジェクト設計ですが、破綻しないという観点では強いと思います。

もちろん、自分は普段こんな構成で開発は行いません。

が、技術者の技術力が不足している現場であれば、こんな感じの設計のほうが破綻せず、保守性の高いプロジェクトになるんじゃないかなーとは思います。

欠点としては、page component と、それに付随する css ファイルがやたらめったら長くなります、当たり前ですね。

でも破綻はしないので、現場によっては強くオススメできます。

フロントエンド開発が破綻する理由は 2 つで、

余計なことをしたせいで破綻する
やらなければいけないことをやらなかったせいで破綻する

の 2 つに集約されます。

前者としては、安易な Next.js の選択や、適当なフォルダやファイル作成が当てはまります。

後者としては、型をきちんとつけなかったり、スキーマファーストを導入しなかったりですね。

両者に共通していることは上にも書いたとおり、技術者の技術不足が原因の 8 ～ 9 割を占めていると思っていて。

型に全て any を割り当てるとか、スタイリングや型を全てグローバルで置いちゃう件については、技術力云々以前に、人としてどうなの？という部分も大きいとは思いますが。

日本ではどこの現場もそうですが、いかんせんフロントエンドの正しい技術力を持っている人があまりに少ないため、そこの現場のフロントエンドエンジニアが正とされる風潮がとても強いです。

そのせいで、本来きちんと作っていれば 5 分で終わるような修正に、数時間、数日をかけているケースもかなり多いのがめちゃくちゃ悲しいです。

上記にも何度か書いていますが、大事なことって全て公式サイトに書かれているんですよ。

にも関わらず、公式サイトすら読まず自分本位に適当なコードを書いてプロジェクトを破綻させる人のことを、自分は技術者と呼びたくないですし、フロントエンドエンジニアだとは認めれません。

公式サイトを読めば大体のことは解決されます、これは自分の経験から断言できます。

『うちの現場は大丈夫！』、『自分はしっかりとしている！』などと勘違いせずに、常に『自分は間違っているかもしれない』という気持ちでいることがとても大切だなーと思う、今日このごろです。