React コラム フロントエンドエンジニア プログラミング

僕がReact一年目で学んだフロントエンド開発の仕事の掟

2021年1月23日

僕がReact一年目で学んだフロントエンド開発の仕事の掟

#React #フロントエンドエンジニア

僕はこれまで6年ほどIT業界で仕事をしています。

 

プログラマーとしての仕事では、RubyやReactをメインに書いてきました。

 

とは言っても、ちょこちょこ色んな仕事やってるんで、勿論他のコードも書けます。

 

PHPとかPythonとかGoとかもいじったことあるけど、キャリアとして言うのはRubyとReactって言ってます。

 

それで、今日は僕がReactのフロントエンドエンジニアとして働いたとき、

 

一年目と二年目で、二つのチームにアサインされて学んだフロントエンド開発の掟みたいなものを話してみようと思います。

 

フロントエンドとバックエンドの違い

 

まず、そもそもフロントエンドエンジニアとバックエンドエンジニアの違いは、

 

機能を実装するか、見た目を実装するかの違いです。

 

見た目と言っても静的な見た目だけではなくて、リッチな動きを実現できるUXというものも作ります。

 

これまで、フロントエンド開発というのは、Jqueryなどの低品質なJavaScriptライブラリによって汚染されまくってしまって、

 

フロントエンドのソースコードが大変な事態になってたわけで、だからこそリッチなUIを作り出すのが大変な作業でもあったと思うんですよね。

 

でも、昨今のReactやTypeScriptやVue.jsなんかが出てきたことにより、フロントエンドのエンジニアが本格的に専門的な知識を要するものとなってきました。

 

それまで、フロントエンドエンジニアというのは、どちらかといえばCSSを書くコーダーであり、JSはそのおまけじゃないかみたいな、

 

むしろ下に見られてた雰囲気すらあったと思うんだが、もうそんな時代ではない。

 

今やフロントエンドエンジニアの報酬はバックエンドの複雑な処理を書くのと同等かそれ以上に高いものとなっています。

 

なんせ、バックエンドもfirebaseなどが普及すればするほど、バックエンドのサーバー言語の役割も少なくなるからね。

 

Reactはコンポーネントにまとめる

 

はい、では本題に入っていきましょう。

 

Reactを書くときに大切なのは、Reactはコンポーネントで一個づつ部品を切り離すというイメージで作るというものです。

 

例えば、あなたが画面にボタンとテキストインプットと、ラジオボタンを作ろうとしたら、

 

ボタンコンポーネントと、テキストコンポーネントと、ラジオコンポーネントが、それぞれCSSを使って作られたコンポーネントにまとめられてます。

 

僕たち現場の人間は、ある意味その再利用可能なコンポーネントを呼び出して、パラメータに色とかサイズとかを指定して、画面に描画できるってことです。

 

もし、そういうコンポーネントがないのであれば、自分で作ってチームで使えるようにするのが大事。

 

コンポーネントはそれぞれ独立していて、CSSとHTMLソースは一個のコンポーネントの中にカプセル化される感じです。

 

だから、基本は原則として、ボタンというコンポーネントがあったとして、もしボタンBというコンポーネントを仮に作らなきゃいけないのだとしたら、

 

フロントのエンジニアは、他のコンポーネント群(HTMLとCSSとJS)のカプセルの中を汚さずに、

 

仮に似たようなものだとしても、あえて別のコンポーネントに切り出して、

 

コピーして使えるコードはコピーして新しくコンポーネント化させるのが大事ですよ。

 

Reactの現場ではディレクトリ構造がチームによって違う

 

次、

 

基本的に僕はバックエンドのエンジニアでRubyを書いてたとき、

 

Railsっていうバックエンドのフルスタックフレームワークを使ってソースを書いてたんだけど、

 

これは誰が書いても、どこに何があるか大体わかるようにディレクトリの設計が分けられています。

 

だから、どの現場に行っても、どこに何があるかはわかります。

 

が、Reactの場合は、そうじゃない。

 

フルスタックのフレームワークとか使ってなければ、大概、多くの現場で微妙にでも確実に、

 

色々とディレクトリ構成が違ったり、コンポーネントのバージョンがあったりして、

 

過去のバージョンから部品を抜き出したりすると怒られたりします。

 

だから、僕たちフロントエンドの新人とかで、新しい現場に入るときは、まずはRractのディレクトリ構造とかをよく見てみるといいです。

 

画面を描画するページはどこにあって、コンポーネントの部品はどこに書かれていて、今使ってるバージョンの部品はどこにあって、

 

それから、もし画面のレイアウトを変えるならばどこにCSSを追加していけばいいか考える必要があるってことです。

 

コンポーネントがかぶる

 

reactの現場に入ってコンポーネントを作っていると、

 

大体画面の作成から実装は始まると思うんだけど、その中で使うコンポーネントは、

 

多くのが他のコンポーネントの一部だったりします。

 

例えば、ボタンやモーダルは他のコンポーネントから呼び出して使う。

 

そういう場合、他のエンジニアが、そのコンポーネントを作ってたら、作ってるコンポーネントが被ったりします。

 

ですから、僕ら新人のフロントエンドエンジニアは、

 

自分が書いてる画面のデザインを実現するには、他の人が今作ってるコンポーネントを利用できるのではないか?

 

と考えて、チームで色々リードエンジニアに聞いてみるといいです。

 

「このコンポーネントって作ってますか?」とか「このコンポーネントに指定のパラメータを渡したら、こうなるようにちょっと変えてもらえないか」とか。

 

こういうコミュニケーションができるようになると、早くコードを納品できるよになり、無駄な実装が避けられます。

 

Reactは大丈夫でもCSSをかけないと死ぬ

 

Reactなどのフロントエンド開発をする際に、

 

やっぱり結局一番大事なのはCSSだなって思っています。

 

正直、Reactはフロントエンドの画面を描画するのを助けるだけであるわけで、

 

使い方を覚えてしまえば、やりたいことはできるようになるわけです。

 

例えば、ボタンを押したときにモーダル出すとか。

 

APIから値を受け取ってループで回してテーブル作るとか。

 

そういうのは慣れれば大丈夫です。

 

でも、CSSはReactを学ぶのと同じくらいちゃんと学ばないと死ぬ。

 

なんてくか、CSSってどうせ画面の見た目を綺麗に装飾するだけだから舐めてていいだろうみたいな雰囲気が、

 

僕の頭の脳裏にあったんですよ。

 

だから、CSSの要素名とかを一言一句読まずに、なんとなく流し読みすると大変なことになります。

 

なぜ、思い通りに画面に描画されないのかわからず死んだりします。

 

だから、CSSは一言一句覚えましょう。

 

そうすれば、Railsのスパゲッティモデルを読むよりは簡単だと思うから。

 

TypeScript書けないと死ぬ

 

最後、ReactはもはやデファクトスタンダードでTypeScriptが導入されてることが多いです。

 

TypeScriptっていうのは、マイクロソフトが開発した、JSに型をつけられるってやつで、

 

よりバックエンドの静的言語みたいな思想のコードが書けますよっていうものなんだけど、

 

TypeScriptをよく学ばないと、独自の型が関数の型定義になってたりして、

 

なんで呼び出しても呼び出せねえだよエラーなんだよみたいな状況になりかねない。

 

色んな型が列挙されていて、関数を呼ぶだけでも初心者には大変な深いソース全体の理解が必要になってきたりします。

 

もう面倒くさくて、列挙されらパラーメタに全部?とかつけてオプショナルにしても、そんなコードをprに出せませんよねw

 

だから、TypeScriptを学んでおかないと、実装に詰まります

 

今日の話しは以上です

 

おすすめ関連記事

 

Pocket
LinkedIn にシェア

React入門者へおすすめ動画&書籍おすすめ!

フロントエンド入門者へおすすめ動画&書籍おすすめ!

  • この記事を書いた人

藤沢瞭介(Ryosuke Hujisawa)

りょすけと申します。18歳からプログラミングをはじめ、今はフロントエンドでReactを書いたり、AIの勉強を頑張っています。off.tokyoでは、ハイテクやガジェット、それからプログラミングに関する情報まで、エンジニアに役立つ情報を日々発信しています!

-React, コラム, フロントエンドエンジニア, プログラミング
-,

Copyright© off.tokyo , 2021 All Rights Reserved Powered by AFFINGER5.