当たり前を疑うフロントエンドの近道

2021-05-28

フロントエンド開発を行う際、普段から気をつけていることがいくつかあります。

自身の経験をもとに、今よりも良い実装ができるようになるかもしれないコツをだらだらっと書いていこうと思います。

会社のコードが正しいと思わないこと

とくに正社員の方に多いのですが「会社のコード＝世間一般的なコード」だと思われている方が非常に多いです。

ですが自身の経験から踏まえると、残念なことに会社のコードって間違った記述がされている割合のほうが多いと感じることは少なくありません。

なぜ会社のコードが正しく書かれていないのか、いくつか思い当たるフシがありまして。

フロントエンドの環境は移り変わりが激しいとよく言われますが、ここ 1, 2 年くらいはさほどトレンドが大きく変わっていないと思っています。

とはいえ、それ以前のフロントエンド環境については本当に目まぐるしく状況が変わっていたのも事実です。

そんな目まぐるしく状況が変わっていく最中に得た知識で書かれたコードは、現環境では通用しないものも決して少なくないです。

たとえば Angular は大きく採用率を下げましたし、React であれば今どき class 構文でコーディングを行うエンジニアはいないわけで。

でもこれらの知識って、常にトレンドを追っていなければ得られない知識なわけで。

会社の古いコードばかり追いかけていると、どうしても古い知識ばかりが身についてしまいます。

これはとても強く言いたいのですが。

フロントエンド開発を行う際、もしわからないことがあれば、まずは各々の公式サイトを読むようにしましょう。

公式サイトがなければ npm もしくは GitHub の README を調べるべきですし、それでも情報が見当たらなければ GitHub の Issue や PR から情報を探すべきです。

フロントエンドの技術は主にアメリカで、ついで中国で開発されたものになります。

そのため必然的に公式のドキュメントの多くは英語で書かれているのですが。

英語に対して抵抗感を持つ日本人は決して少なくなく、みんなどうしても個人や会社の技術ブログ、Qiita や Zenn などから情報を得がちです。

しかし公式でない日本語の情報は間違っている情報も非常に多く、アップデートが行われないため陳腐化しているものも非常に多いです。

公式サイトを読まずに非公式の情報から知識を集めていると、本人は正しいコードを書いているつもりでも、グローバルな目線から見るととんでもないコードを書いてしまっていた、なんてケースもよく目にします。

これは 10 年ほど前、自分がまだ正社員として働き始めたころの話なのですが。

まだ自分の書くコードのレベルが低く、先輩からレビューしてもらっているときに、

「コードの根拠は可能な限り公式サイトから持ってくるようにしたほうが良いよ」

というアドバイスを頂きました。

当時は『別に個人のブログを参考にしたってイイじゃんね』と生意気にも思っていたのですが、今となってはこの指摘は大切なことだったんだなぁと、強く感じます。

フロントエンドの技術について日本の Google で検索を行うと、大体上位には個人のブログや Qiita が引っかかってしまい、公式サイトを見つけるのも一苦労です。

そのため、調べ物をする際はなるべくアメリカの Google で調べるクセをつけたほうが良いと思います。

とくに開発経験の浅いエンジニアに多いのですが。

なんの根拠も持っていないのに自分が書くコードに絶大な自信を持っている方がおられます。

そこでいざコードレビューでコードの意図を確認すると『なんとなくです』とか『よくわかりません』という曖昧な返事ばかりが返ってくるという始末。

で、そうやって適当に書かれたコードが会社に納品されてしまっていると、そのコードを引き継いだエンジニアはまた間違った知識を得てしまうわけで…。

自分は普段、業務でフロントエンド開発を行っていますが、プライベートでもフロントエンド開発を行っています。

ですが、業務で書くコードとプライベートで書くコードでは、かなり書きっぷりが異なります。

会社で書くコードは会社の方針があるため、コードの正しさは会社の方の判断に委ねられているわけで。

モダンさやメジャーさの追求はプライベートで追い求め続けるようにしています。

皆さんもぜひ一度自分の常識を疑ってみて、初心に帰って各技術について公式のドキュメントを読んでみるのはいかがでしょうか。