バックエンド一本だった新卒エンジニアが急にFEをやって困ったことと良かった事

はじめに

今回はBE一本だった私が急にFEも担当することになって困っていることを紹介したいと思います。
もちろんFE初心者なのでチンプンカンプンなこと言ってることも多いと思うので温かい目で見守っていただければと思います。
あとそれぞれに対するアドバイス等頂けると大変助かります🙇🙇🙇🙇🙇🙇🙇🙇🙇🙇🙇🙇

前提

• 一応Reactでとりあえず作るならそこそこできる(と思います)
• いわゆるポートフォリオは作ったって感じです

事の経緯

某プロジェクトにおいて私はBEエンジニアとして仕事をしていました。ところが、色々あってチーム体制が変更となり、結果私は一人でBEとFEを兼任することとなりました。

技術スタック的にはこんな感じです

• Next.js (app router)

これらを習得し、実装する必要がありました。おまけに最初から高難易度のUIが要求される機能を作るという鬼畜っぷり、、、。Reactがチョットワカルぐらいの知識の中、チームにFEエンジニアもおらず頼れる人も少ない中での孤軍奮闘が始まりました。

困っていること

Next14->15の破壊的変更

自分のプロジェクトはNext.jsを使用しています。そんな自分がFEをやることになる直前に15へのバージョンアップが行われました。

15では破壊的な変更があり、特にNextの大きな特徴とも言えるキャッシュの挙動が大きく変わりました。すごくざっくり言うとNext14まではデフォルトでキャッシュしていた部分がキャッシュされなくなりました。
Nextのキャッシュはただでさえ難しい部分なのですが、初学者の私はこの破壊的変更に大きく振り回されることになりました。

大前提キャッチアップが難しくなってしまいました。Next14までのわかりやすい記事はそれなりにあったんですがそれも意味をなさなくなってしまうからです。幸い15のわかりやすい記事がなくもなかったのでどうにかはなった(多分)と思います。

ですがプロジェクトで実際にNext15にしたことによる不具合が起こります

これに対処するために無理やりNextのレンダリングの仕組みをある程度理解する必要があり、私は大いに苦しみましたとさ(泣)
ぶっちゃけ今もこの内容の何割理解できてるんだろう,,,,

FEの基礎がわからない

FEの基礎と言われたら皆様なにを思い浮かべるでしょうか?html,css,js,react,,,とかよく聞くんじゃないかなと思います。
研修では当然このような内容は扱います。研修をクリアした私はフロントエンドの基礎をマスターしているといえるかというと、、、

答えは「No」です
というのも実際のプロジェクトで扱っているコードと比較したとき、明らかに自分とのレベルの開きがあったり、実際のFEの方とのスキルの「差」を感じるからです。
ではその「差」はなんなのか。

それは、、、
ぶっちゃけ全然わかりません。
現在進行形で困っているので誰か助けてください(泣)

BEの場合、言語やフレームワークが変わっても「基礎」といえる部分は以外と変わりません。
ざっと挙げるだけでもSQL、DB設計、CRUD、エラーハンドリングetc,,,
一部ギークな部分もありますが基本はこういう「基礎をいかに高度にやるか」という世界観だったりその方法論を高めていく世界だと思います。

一方FEは「移り変わりの激しい世界」だとよくいわれます。そのせいでBEほど基礎が固まる前に移り変わりが起きてしまうのが原因なのかなと思っています。でもFEも積み重ねや経験で熟練度が変わるのは同じかなと思っています。では一体FEの方は何を積み重ねて強くなっているのか、、、なるほどわからんという感じです。

UI関係の用語の多さ

これも何気に苦しいポイントです。UIを構成するパーツには色々と名前があります。ヘッダーとかフッターとか、このあたりは分野に限らずご存知の方が多いと思います。ですが実際に画面を構築しようと思うと結構な比率で「なにこれ?」と言いたくなるUIパーツの名前が出てきます。
実際に出てきて?となったのは

• モーダル
• dnd
• Picker

ざっくりこんな感じだったんですが実装の度にUIの知識を入れていかないといけないと思うと、、、中々辛いなあという感じです

手札がないと戦えない

FE全体の特徴としてBEより「手札がないと戦えない」側面があるんじゃないかなと思っています。さっきのUIの話ですが、全て「既存のコードで遭遇したもの」なんです。なのでわからない事が多くても、たどり着けないことはないのです。

一方で一から画面を構築しようと思うとそうもいかないです。渡されたデザインを解読するのにまずUI関連の知識が必要ですし、それを再現するのにどういうライブラリ、スタイル、ReactのAPIなどが必要かを一から探す必要があります。自分がまだその経験をした事がないのもそうですが、調べるにしても導線がなさすぎてぶっちゃけできる気がしていないです。

現役FEの方はどうしているのでしょうか?やっぱりある程度頭に入っているからわかるのかな?と思っているのですがいかがでしょう?

コンポーネントと共通化の罠

コンポーネントやDOMツリーはその性質上、親子の関係があることが多いと思います。この場合、親のコンポーネントで当てたスタイルが子のコンポーネントにも影響を及ぼします。

つまり親コンポーネントは子コンポーネントに対する共通化とも言える訳です。すると親の変更が必要になった場合、子のコンポーネントにも影響がいくわけです。勘のいい人ならこの段階で何が起こるかお分かりいただけると思います。そう、ここに共通化の地獄 が発生します。

親のコンポーネントの変更が発生したとき、子コンポーネントに影響がいってないか確認する必要があります。この子コンポーネントが多いと変な影響が出たり、逆に親に合わせて子を変更したり、、、、ぶっちゃけ地獄みたいな世界です。

BEだったら手続き型みたいなことをすれば(不便ですが)避けれますがFEだと必ずコンポーネントやタグ間で親子関係が発生しているので避けられない問題です

BEよりも型関係が面倒

私は、BEとしてTSを学ぶために以下の書籍でTSの勉強をしていました
TSの書籍ということもあって特に型に関する記述が多くありました。
プロを目指す人のためのTypeScript入門　安全なコードの書き方から高度な型の使い方まで

ですが思ったのです。「こんな型いつどこで誰が使うねん」と
参考 -> TypeScriptの型入門
結構できることは多いです

実際BEで複雑な型を扱うことは少ないです。
ですがFEだと意外と見かけました
例えばこんな風なのとか
(実務のコードをそのまま載せるわけにいかないので適応にぼかしています)

type Props = {
  children?: React.ReactNode;
  title: string;
  id: number;
  isEditable?: boolean;
} & VariantProps<typeof customGridItem>;

BEだと複雑な型を使う事が意外と多くないのでなるほどなあ、、って感じです

セキュアなコードの書き方が分からない

「コードを綺麗に書きましょう」という観点に立った時。大体は「どのプログラミング言語、フレームワークにも言える観点」と「その言語、フレームワーク特有の観点」があると思います。私の場合はFE、もといNextにおいて後者がよく分かってません。自分で「こうすれば綺麗になりそう」という工夫をしたりググった付け焼き刃の知識でどうにかするしかありません。

既存コードを見て「こうすれば綺麗に書けそう」というものを吸収することは一定できますがそれも完璧じゃありません。その「アウトプットされた形」はわかっても「どういうメリットがあってその書き方をしたのか」という部分までは特に吸収しにくいです。想像するしかありません。その場合おそらく既存コードのいいところを吸収しきれていない可能性は高そうだなと思っています。

よかったこと

BEで取得したデータがどう活用されているかわかる

私はBEにばかり着目していたせいでBEで作ったコードがFEでどのように用いられていたのかあまり意識していませんでした。配属初期は、色々情報過多だったので追ってなかったのですがそれがズルズルこのタイミングまできてしまってましたね(ここは反省点かなと思います)

ですがある程度FEのコードを読めるようになってくるとその辺も紐解けるようになってきました。これができると今後、FEの方との連携がスムーズにいけるんだろうなあと思うのでいい経験でした。

よりプロジェクトやプロダクトに詳しくなれる

先ほどに通ずる部分もあるのですが、BEしか見てない自分にとっては当然プロダクトについても追いきれていない部分がありました。その部分でもいい経験になったかなと思います。

プロジェクトのコードが良い場合にはいい教材になる

これは既存のいいコード(定義は諸説あり)がある場合限定なのですが、プロジェクトのコードが良い場合にはいい教材になるとも思いました。FEはBEに比べるといろんな道具を使う必要があります。ライブラリやAPIなどの道具は一定、適当な使い方をしてもどうにかなってしまう場合があるかなと思います。

例えば以下だとボタンのコンポーネントを作る際に色をpropsで渡して変えたらいいのに色別にコンポーネントを作ってたりとか、、

FEは基礎が曖昧な分、こういうことをやらかしがちな世界なのかなと思ってます。
その点自分のプロジェクトを見る感じおかしな使いかたをしている部分をあまりみかけなかったのでいろんな道具のいい教材になりました

// RedButton.jsx
import React from 'react';

const RedButton = ({ onClick }) => {
  return (
    <button style={{ backgroundColor: 'red', color: 'white' }} onClick={onClick}>
      Red Button
    </button>
  );
};

export default RedButton;

// BlueButton.jsx
import React from 'react';

const BlueButton = ({ onClick }) => {
  return (
    <button style={{ backgroundColor: 'blue', color: 'white' }} onClick={onClick}>
      Blue Button
    </button>
  );
};

export default BlueButton;

// GreenButton.jsx
import React from 'react';

const GreenButton = ({ onClick }) => {
  return (
    <button style={{ backgroundColor: 'green', color: 'white' }} onClick={onClick}>
      Green Button
    </button>
  );
};

export default GreenButton;

まとめとおねがい

以上、「バックエンド一本だった新卒エンジニアが急にFEをやって困ったことと良かった事」でした!
FE初心者がかかげる疑問ってこういうものがあるんだなあという視点の材料になればと思います

そしてここからがお願いなのですが是非この記事のコメント欄にここまでの問題のいい対処法の投稿をお願いしたいです。
知見が溜まっていくことによって私FE初心者のエンジニアにとって大きな道標になると思いますのでどうかよろしくお願いします🙇🙇🙇🙇🙇🙇🙇