Frontend Fundamentals Discussion

• この記事はDeepLAIを活用して翻訳しています。

Frontend Fundamentals Discussionとは？
Tossが運営するFrontendに関する全てのことを扱う韓国のドキュメント及びコミュニティです。

今日はそのトピックの中で、「Boolean typeへの暗黙的型変換についてどう思いますか？」という議論について説明します。

質問文は下記のような内容です。

const someFunction = (value?: string) => {
  if (!value) {
    return ...
  }
  // ...
}；

上のようなタイプスクリプトコードで、valueがない(undefined)場合はearly returnをしたい時、上のようなコードがいいコードだと思いますか？
valueがboolean型ではないので、if (!value)条件文はvalue引数がない場合をチェックしたいのか、「」のように空文字列である場合をチェックしたいのか意図が不明だと思います。

なので、if(value==undefined)のようなコードの方が意図が明確だと思います。

しかし、上記の例のように書かれているコードを一日に何度も見かけますが、皆さんはどう思われますか？

A. ブールアン型への暗黙の型変換は問題ない。
B. ブールアン型への暗黙的型変換は良くない。

最も多くの反響を得た意見はこれです。

私は、if文や三項演算子の条件式には、常にブルアン値だけを使うべきだと思います。

予測可能性の観点から、コードは書いた人の意図が正確に現れることが重要だと思います。 ところで、if (!value)のようなものは、value !== undefinedを意図しているのか、value !== '' を意図しているのか、コードだけでは意図がわかりにくいと思います。

また、if(条件)の条件でブールアンが来ない可能性がある場合、後で大きなエラーが発生する可能性があります。 このドキュメントやESLintの厳密なブールアンの検証のドキュメントが教えてくれるように、予想外に常にtrue、または常にfalseと評価される可能性があります。

コードの意図を明確に表現し、エラーの可能性を減らすためには、ブール値の値だけを使うのが良いのではないかと思います！

他にもこんな意見もありました。

人によって違いがあるとは思いますが、私は暗黙的型変換をすることが意図が不明確だとは思いません。 だから、時には使ってもいいという意見です。 私にとっては、!valueを見ると「valueがどんな値でもfalseで評価されたらreturnしてほしい」という意図が伝わります。

むしろ、暗黙的型変換を使うなら、大丈夫かどうかの基準は明確/不明確よりもエラーの可能性に焦点を当てた方がいいと思います。 valueが特定の値かどうかに応じてロジックを処理する必要があるなら、value === 「」やvalue === undefinedのような条件文を書いた方がエラーの可能性を減らすことができるので、より望ましいと思います。

例の状況もそうですが、valueがない(undefined)場合にearly returnをしたい状況ならvalue === undefinedがエラーの可能性を減らす方法だと思います。 逆にundefined、null、''に関係なくfalsyで評価される値の時に全てearly returnをしたい状況なら暗黙的型変換を使ってもエラーが起きる可能性は少ないと思います。

時々は暗黙的型変換を使って、時々は明示的型変換を使うのは統一性を損なうので、これが少し不便(?)であれば、es-toolkitなどで提供してるisString, isNillのような関数を積極的に使うのも一つの方法だと思います！

皆さんはどう思いますか？スレッドで自由に意見してください！
もしくはDiscussionページに来て直接意見を書いてもいいです。
AIを活用し、コミュニティの人たちも積極的に参加するので、無理をしないでください。

• この記事はDeepLAIを活用して翻訳しています。

今回は引き続き、「フロントエンドのガラス張りの天井は実在するのか」という議論について紹介したいと思います。

質問は以下のような内容です。

質問は以下の内容です。

こんにちは。ジュニアフロントエンド開発者のチョン・テミンです。

先日、就職活動中の友人と会話をしていて、こんな話を聞きました。

「フロントエンドは後々上がるところがないから、バックエンドに変えようと思ってる。」

当時は「えー、それはちょっと極端じゃないですか？
最近はむしろその言葉がずっと心に残っています。

会社の中を覗いてみると、高年功序列の開発者はバックエンドの方が多いみたいで、
全体的なアーキテクチャー設計や技術的な意思決定もバックエンドエンジニア中心に流れている感じがします。

フロントエンドは比較的製品実装に近い位置なので、
'それ以上'の方向性が比較的曖昧に見える瞬間もあります。

もちろん、ユーザーエクスペリエンスに集中するという点や
パフォーマンスの最適化、アクセシビリティ、デザインシステムなども
本当に深い分野だと思います。

それでも、キャリアのスケーラビリティの面では
フロントエンドにガラス張りの天井があるのではないか？
という疑問を持つようになりました。

そこで皆さんにお聞きしたいんです。

1. フロントエンドのキャリアにも「ガラスの天井」があると感じますか？
2. シニアフロントエンドになるために、どのような方向性を持っていますか？
3. シニアフロントエンド開発者であれば、その先にはどのようなキャリアがありますか？
4. また、役割の枠を超えて、影響力を広げるために、どのような試みをされていますか？

同じようなことを考えたことがある方、
フロントエンドで順調にキャリアを積んでいる方の話を聞きたいです。
ジュニアとして進路を描いていく上で、とても参考になると思います。

最も多く寄せられたのは、次のような内容でした。

少し慎重になりますが、現時点では「ガラスの天井がある」と思っています。
ただ、このガラスの天井は私たち自身が作ったガラスの天井である可能性もあると思います。

バックエンドと違って、フロントエンド開発者という概念が韓国に登場したのは、まだ10年ほどしか経っていません。 つまり、現在フロントエンド開発者という肩書きをつけて仕事をしている人の中で、ある程度キャリアを積んだと言われる人は、「まだ10年目」程度ということでもあります。 それだけ、まだ熟していない若い業界です。

なので、「フロントエンド開発者がどこまでできるのか」というのは、**今現業で働いている私たちが作っていくものだと思います。
もし、私たちがフロントエンド開発者はガラスの天井があると思って何の挑戦もしないのであれば、今から10年後に働いているフロントエンド開発者は、今よりももっと強いガラスの天井に直面するかもしれません。

言い換えれば、今フロントエンド開発者として働いている私たちが日々行っている業務、話しているこの瞬間も、フロントエンド開発者という職業の可能性を定義していることに参加しているのかもしれません。

「フロントエンド開発者出身のCTOはなぜバックエンド出身のCTOよりいないのか"というような疑問もよく耳にします。
これも、フロントエンド開発者のキャリアや年輪がまだ熟していないからかもしれませんが、単に私たちが挑戦しないからかもしれません。

もし私たちがこの仕事を本当に愛しているなら、この仕事の可能性も自分たちで作っていくものだということを忘れないでほしいと思います。

次に人気があった意見は次のとおりです。

近年、ソフトウェアにおいてUXの重要性が高まっていることが、フロントエンドの専門性を高めるのに大きな役割を果たしたと思います。
特にスマートフォン中心のハードウェアの変化により、ユーザーとの接点が多くなり、アプリ/ウェブを扱うフロントエンドの比重がますます重要になっていると感じます。

市場が大きくなるにつれて、様々な年代やバックグラウンドのフロントエンド開発者が多くなり、自然とキャリアを考える方も増えていると思います。

フロントエンドのキャリアにもガラスの天井はあるのでしょうか？
個人的には、「ガラスの天井があるというより、まだできていない」と思っています。
フロントエンドベースのCTOがほとんどいないので、ガラスの天井を感じる機会すらなかったというか。

以前は、バックエンド中心のクラシックな技術を扱ってきた人がエンジニアとして長く成長する時間と機会があり、そのおかげで自然にCTOになる仕組みができたと思います。
しかし、今は流れが違います。 ユーザーエクスペリエンスと接点の重要性が高まり、フロントエンド出身のリーダーも必ず出てくると思います。
私たちがその変化を作っていく世代だと思います。

シニアフロントエンド以降のキャリアの方向性は？
私は現在シニアフロントエンドエンジニアとして働いていますが、その後のキャリアは会社によって異なりますが、だいたい2つの方向に分かれると思います。

マネージャー(Talent Manager): チームを成長させる役割。

エンジニア(Technical Expert)： 技術的なリーダーシップを強化する方向

2つのトラックを行き来しながら自分の方向性を定めていく流れが自然なようで、ある時点で大きな決断をすることになると思います。
技術中心ならCTO、ユーザー中心ならCPOといった道も開かれていると思います。

役割を超えて影響力を広げるための試み
私はTPM/PM/POの役割にも足を踏み入れようとしています。
フロントエンドシステムをより良くするために、より早く価値を届けるために、より広い視点が必要だと感じたからです。

そして、個人的には「最終的な技術者」なんてないと思っています。
会社に必要な問題を解決する人が結局一番かっこいいし、バックエンドでもフロントでも行き来できる人が本当に柔軟で強い人だと思います。

このテーマは世界中の全てのフロントエンド開発者が一度は悩んだテーマではないかと思います。
皆さんはどう思いますか？スレッドで自由にご意見をお聞かせください！

または、Discussionのページに来て直接意見を書いてもいいです。

AIを活用し、コミュニティの人たちも積極的に参加するので、無理をしないでください。