あなたの現場のフロントのプロジェクトは崩壊していないですか？

2021-06-15

日本のフロントエンドのプロジェクトはほぼ崩壊しきっていると思っているのですが。

『一体自分は何の根拠を持って崩壊していると言っているのだろうか』とふと思い、自分なりの判断基準を書き出してみることにしました。

フォーマッターを導入していない

普通のエンジニアであれば「そんな現場あるわけねーだろ！！」と思うかもしれないですが、事実自分はフォーマッターを導入していない現場へ参画した経験があります。

通常であれば Pritter か ESLint あたりでフォーマットをかけると思いますが、そこの現場はすべて手動フォーマットという…。

仕事をしていて気が狂いそうになったので早々に離脱しました。

こんな原始時代みたいな開発はやめましょう、恥ずかしすぎます。

フロント開発で Linter となると ESLint StyleLint CommitLint あたりが上がると思います。

自身の経験では ESLint のみ導入されている現場は比較的多い印象があります。

逆に ESLint すら導入していない現場は結構やばいです、言ってしまえばルール無用な状態なので。

Linter は導入が意外と難しいですが、きちんと導入することが非常に重要です。

また導入したからといって満足せず、少しでも堅いルールを追加し続けることが大切かなーと。

Storybook を導入しないのは別に構わないのですが、導入したいのにできていない場合は大きめの問題を抱えているケースが多いです。

過去目にしてきた導入できない理由としては、

などが多かったです。

Storybook を組むのであれば、そもそもプロジェクトの開始前にコンポーネント設計を明確にし、どの粒度で Storybook を導入するのか決めておく必要があります。

個人的には Storybook を導入するしないはケースバイケースで良いと思うのですが、常に Stobybook が導入可能なコンポーネント設計は必要だよなーと思っています。

今どき素の JavaScript でフロントのコーディングを行うのは自殺行為です。

もしあなたが携わっているプロジェクトがそうであれば、おそらくプロジェクト内は大小さまざまなバグで侵されまくっています、もう手のつけようがないです。

any ってめったに使うものではありません、型の整合性が取れない場合のみしぶしぶ使うものです。

過去 TypeScript を使っていますという触れ込みで参画した現場において、プロジェクト内のコードの型ほぼすべてに any が割り当てられていることがあってぞっとした経験があります。

比較的レアケースだとは思いますが、もしあなたの現場がそうであればやはりもう手のつけようがないと思います。

いまだに BEM を手動で書かせたり、CSS はすべてグローバルで当てる現場がちょこちょこあります。

これまた原始時代じゃないんですからやめましょう、恥ずかしい。

GraphQL であれば型ありきなので問題ないと思いますが、Rest だとそうもいきません。

Open API を使用して Api 周りの型を生成したり、はたまた Api の呼び出しの実装まで自動生成するのが一般的です。

にもかかわらず、いまだにスキーマすら作成せず 1 から手作業で Api 周りを書いている現場もたくさんあって、あれなんなんですかね？

スキーマを作るだけで型周りのエラーも出なくなるし、ある程度実装も自動生成できるのだから、メリットしかないと思うのですが。

Web デザイナーが在籍しない現場は論外として、いるにもかかわらずプロトタイピングツールすら使っていない現場はやばいです。

Web デザイナーはプロトタイピングツールを使用してフロントエンドエンジニアに連携を。

フロントエンドエンジニアは Storybook を使用して Web デザイナーに連携を行うのがあるべき姿のコミュニケーションだと思っています。

ということでいかがでしたでしょうか。

上記の項目のうち 1 つでもあなたが参画しているプロジェクトに該当するものがあれば、そのプロジェクトは崩壊していると言って差し支えないと思います。

とくに Storybook を導入したいのにできない理由がある や Api 周りの型がない に当てはまる現場は決して少なくない印象です。

が、上記はの内容はすべてフロントエンド開発の基本中の基本です、守れていて当然、守れていないのは相当やばいという認識を持ったほうが良いと思います。

ぜひマネージャーやディレクターの方、現場のフロントエンドエンジニアにそれとなく聞いてみて、現状を確認してみるのはいかがでしょうか。