タオバオフロントエンドエンジニア：国内ウェブフロントエンド開発10日間

私はずっと、この「Ten Days Talk」を書いて、Web フロントエンド開発における私の経験について語り、ついでに、私の周りの多くの人々の困惑や当惑に答えたいと思っていました。あまりテクノロジーについて語るつもりはありません。技術的な経験を通して得た反省の方が重要だと考えています。

私は常に自分を「ジュニア」フロントエンド開発エンジニアだと考えてきました。一方では、この分野に携わってまだ数年しか経っていません。他方では、環境のせいかもしれませんが、テクノロジーを深く掘り下げていないこともわかっています。もちろん、最も重要なことは、インターネットの台頭に関われたのは幸運だったということです。現在の状況は、スキルは低いが需要が高い「トレンドセッター」のグループを生み出し、私たちの「技術の本質」に対する洞察に大きな影響を与えました。長年にわたり、体系的な「フロントエンド技術」の伝道活動が行われなかったため、ほとんどの人のフロントエンド技術に対する理解は、厳密に表現されていない求人募集の説明から始まり、Webフロントエンド開発自体の曖昧な位置付けを反映しているだけです。多くの Web フロントエンド エンジニアにとって、禁断の果実を味わう興奮は長くは続かず、キャリア プランを考えたり、自分に合った成長の道を探したり、自分のスキルのボトルネックを認識したり、突破口を探したりしながら、混乱の連続に陥ります。残念ながら、Web フロントエンド テクノロジが広く受け入れられるようになったのはごく最近のことであり、模範となるような成功モデルは多くありません。しかし、状況は必ずしも悪いわけではありません。結局のところ、Web フロントエンド技術は「技術」であり、コンピューター サイエンスと同じ部門から来ています。インターネットの急速な台頭により、霧に包まれ、私たちの目がくらみ、現状をはっきりと見ることができない状態になっています。

では、Web フロントエンド技術職の境界をどのように定義するのでしょうか。Web フロントエンド技術の価値はどこに反映されるのでしょうか。フロントエンド エンジニアの価値は、希少で貴重であるということだけに反映されるのでしょうか。フロントエンド エンジニアのジュニア、中級、上級、エキスパートの各レベルをどのように定義するのでしょうか。私は現在どこにいるのでしょうか。次に何をすべきでしょうか。フロントエンド技術の「道」とは何でしょうか。これらの疑問について、ほとんどの人が考えたことがあると思います。この「Ten Days Talk」の見解は少し極端かもしれませんが、読者の皆さんには、これらの発言を入門書として受け止めていただければ幸いです。

1日目: 禁断の果実を初めて味わう

[神は「光あれ！」と言われ、光がありました]

すべての生物、太陽の光、雨、露は、宇宙の始まりにおける自然の創造から生まれました。神が光を創造する前の世界がどのようなものであったかは、私たちには想像できません。しかし幸いなことに、フロントエンド開発には神々のような神秘的な魅力はありません。この技術的な仕事の構想、形成、発展には独自の軌跡と起源があります。もちろん、これは非常に理解しやすいことです。厳密に言えば、ジェリー・ヤンとファイロがスタンフォード大学のコンピュータ室で Yahoo! を設立した当時、Web フロントエンド技術はすでに世間の注目を集め始めていましたが、当時はよく知られた名前ではありませんでした。それ以来、「ブラウザベースの開発」はソフトウェア開発の新たな分野となり、Web フロントエンド技術の中核にもなりました。つまり、いつ、どこで、どんなシステムやデバイスであっても、ブラウザをベースにしていれば、Web フロントエンド開発の範囲内になります (もちろん、この定義は非常に狭いですが、後述します)。

2000年以降、ブラウザ技術は徐々に成熟し、Web製品はますます豊富になり、中国では多くの若者がインターネットを使い始めました。注目すべき点は、ほとんどの人がインターネットに触れるようになったのはブラウザの機能に対する好奇心からではなく、ブラウザウィンドウの豊富なコンテンツに惹かれたことです。私たちの思考モードは最初から小さなウィンドウに制限されていたため、長い間「視覚」を「機能」と見なし、Web製品は情報を表示するために使用されているに過ぎませんでした。業界に初めて入った人たちは例外なく、「コンテンツ」よりも「ビジュアル」を重視していました。まずはページを美しく見せること、HTML/CSSに着目し、その後「ビジュアルプレゼンテーション」という方向でさらに深掘りしていきました。そのため、このタイプの人々は「ビジュアル」に惹かれ、Web ページからキャリアをスタートします。構造化された HTML ときちんと記述された CSS に魅了されます。シンプルでエレガントな UI とすっきりとしたページ デザインを好みます。その後、視覚効果に触れ始め、jQuery を使用して視覚効果を実装します。これを手がかりに、Dom、Bom、およびブラウザーのレンダリング メカニズムについて詳細な調査を開始します。これらの人々にとって、HTML/CSS は攻撃用の武器のようなもので、JavaScript は防御用の盾のようなものです。

別の経路から Web フロントエンドに接するグループ、つまりフロントエンドに転向したエンジニアもいます。彼らはバックエンド言語開発のバックグラウンドが強く、データの読み書きから始めて、徐々にブラウザ側に触れ、JavaScript ライブラリに触れるようになりました。最初は js ロジックを html コードに追加し、後に html と css を絡め始めました。彼らは OO、明確なロジック、コードの構造のよさを好み、インターフェースの背後にある「プログラミング言語」とデータ ロジックにもっと注意を払います。これらの人々にとって、html/css は盾のようなもので、JavaScript は攻撃用の武器のようなものです。

これら 2 つのタイプの人々は互いに補完し合っていると言えます。それぞれがブラウザの本質の一部を理解しています。一方のグループはレンダリング エンジンをよく理解していますが、もう一方のグループは JS エンジンを宝物のように考えています。実際、どの部分の利点も、優れた製品を生み出すために活用できます。ほとんどのフロントエンド エンジニアは、これら 2 つのソースに自分の影を見つけることができます。しかし、この 2 つのタイプの人々の思考パターンと視点は非常に異なるため、不必要な対立が形成されています。たとえば、一部の企業では、Web フロントエンド技術は単純に「ページをカットする人々」と「js を書く人々」の 2 つの部分に分かれています。そうすることで、仕事の分担が明確になり、効率性が向上するように見えるかもしれませんが、従業員のキャリア開発に大きな害を及ぼします。 2日目の「プロフェッショナル学者」セッションではさらに議論が行われます。

私は2番目のカテゴリーに属します。つまり、大学卒業後はERPソフトウェアやデスクトップソフトウェアに携わったり、通信会社に入社してTCP/IP関連のプログラムを作成したりできると考え、学校ではC/JavaとC#を真剣に勉強しました。キャンパスリクルートでYahoo Chinaを選んだのは、当時（2008年）Yahooがまだある程度有名だったことと、Yahooの方が技術的な会社だと聞いたからです。それ以来、私はYahoo Chinaにのめり込み、やめられなくなりました。

Yahoo に在籍していた頃、非常に誠実な技術学校と関わる機会があり、フロントエンド技術に関する基本的な考え方を形成するのに役立ちました。この考え方は今日まで私に影響を与え続けています。

【上品なアカデミックスタイル】

当時、ヤフーの技術学校は最盛期で、多くの「お父さん」級の専門家がいました。それが醸し出すハックの雰囲気は、私を酔わせるほどで、私はその雰囲気に抗うことができませんでした。当時、私は夜遅くまで残業して大量の文書やソースコードを読むことさえ好んでいました。それは本当に心地よかったです。私はヤフーのエンジニアの控えめで実用的で細心の「サービス精神」に深く感動し、この目立たない優れた品質は、ヤフー製品のユーザーエクスペリエンスと高品質の技術出力に大きな影響を与えました。では、「サービス精神」とは何でしょうか。それは、製品の顧客、プロジェクトを引き継ぐ人、開発した機能を使用する人など、人々に奉仕することであり、そのため技術ドキュメントがコードに付随する標準機能になることを意味します。したがって、エンジニアはコードを通じて互いに通信することができます。これはエンジニアの基本的な資質であり、明確なアイデアでプロジェクトを完了し、価値のある技術文書を提供することです。これは、プログラムが他のプログラマー向けのものである場合はさらに重要になります。家電製品を製造するときに取扱説明書を提供する必要があるのと同じです。そのため、YDN は当時、世界中のプログラマーの間で最も人気のある技術文書ライブラリになりました。このエレガントで実用的な「学術的な雰囲気」は、人々にユニークで魅力的だと感じさせます。

奇妙なのは、このような学術的な学校が中国系コミュニティではこれまで見られなかったことだ。オープンソースという本来の利点を持つ Web フロントエンド技術コミュニティでさえ、盛り上がりはありません。優れた技術コピーを書くことは、空に登るよりも本当に難しいことがわかります。私が目にしたいわゆるドキュメントのほとんどは、データを出力するコード内のステートメント ブロックをコピーして貼り付けただけです。データ形式がなぜこのように設計されているのか、フィールドが変更された場合はどうするのか、エンコードとデコードの要件は何かなど、重要な情報については何も言及されていないか、開発者がこれらの問題について考えていないようです。そのため、コードの品質や保守性を重視してきましたが、この「サービス」意識が浸透していなかったためか、これまで効果が出ませんでした。この種の認識は、あなたが行うことのあらゆる細部に影響を及ぼす可能性があるため、以下で何度も言及されます。そして、最初に打破すべきなのは精神的なもつれです。

意識の問題に加えて、もう一つの側面は技術的な問題、つまり文章スタイルです。これはエンジニアが最も嫌う問題でもあります。これがエンジニアのボトルネックの突破を妨げる主な問題だというのは信じられないことです。このレベルの昇進で失敗する人を私は数え切れないほど見てきました。多くのエンジニアは優れた技術力を持っていますが、それを表現できないのです。焦点を絞らずに大量の情報を列挙したり、コードの詳細について退屈な方法で話したり、といった具合です。技術を理解している上司に出会えるほど幸運でない限り、プログラマーになる運命から逃れる方法は本当にありません。しかし、ほとんどの人は依然として議論し、意見が一致しません。 Web フロントエンド開発の分野では状況はさらに悪化しています。フロントエンドエンジニアはリファクタリングを最も好んで行いますが、要求が速い中で「保守性の向上」や「パフォーマンスの向上」といった漠然とした言葉でリファクタリングの時間を稼ぐことは難しいです。はっきり言って、あるリファクタリングによってもたらされる実際の価値を定量化することはできず、「コードがすっきりした感じになる」というだけかもしれません。フロントエンド エンジニアのこの衝動的でお世辞を言う技術的複合体を、以下の「疑似アーキテクチャ」で分析します。そして、これはフロントエンド エンジニアに最も欠けている資質の 1 つです。つまり、データを使って話し、厳密な科学的議論を使って自分の意見を裏付けることです。あなたの上司は愚かではないので、きっとあなたに価値のあることをやらせてくれるでしょう。

もちろん、状況は必ずしも悪いわけではありません。中国系コミュニティでは多くの作家が登場し、彼らは質の高い文章を使って技術的なアイデアを広めています。これは、優れた文章スキルを養うことができるという良い兆候です。職場、特にフロントエンドエンジニアという特殊な職種では、この基本的なスキルが、ニーズの優先順位を考え、乱雑なニーズから重要なポイントを把握するのに役立ちます。なぜなら、真剣にメールを書き始めると、このような考えがすでに含まれているからです。

したがって、Yahoo のテクノロジーの推進は比較的成功し、広範囲に及んだ。鍵となるのは、堅固な技術的基盤と優れたライターという 2 つの側面です。真の技術専門家とは、剣道の技を深く探求するだけでなく、秘密のマニュアルも作成するなど、その両方を兼ね備えた人でなければなりません。これは、Yahoo! の優雅で学術的な雰囲気の原動力でもあります。国内の多くの技術団体がこの分野で成果を上げたいと考えているが、まずはこのことをしっかりと考えるべきである。

【基準の破壊と確立1】

ヤフーの技術運営は非常に標準化されており、前述のように技術、組織、文化などすべてが整然としており、ベンチマークとして見なすことができます。当然、国内の多くの技術チームやコミュニティの模範となっています。一時期、さまざまな「仕様」が普及し、さまざまな「基準」が普及したため、品質にばらつきが生じていました。

本当に必要な仕様とはどのようなものでしょうか。Yahoo の技術仕様にはどのような魔法があるのでしょうか。本物の仕様を構築するには、どのようなアイデアを使うべきでしょうか。仕様にはどのようなライフサイクルがあるのでしょうか。これらの質問について明確に考えることで、多くの Web フロントエンド エンジニアの精神的負担が大幅に軽減され、一部の技術の本質を理解し、盲目的にトレンドを追うことを避けることができます。

確かに標準は必要ですが、優れた標準は実用的で「問題を解決」するものでなければなりません。たとえば、プロジェクト用に構築された DPL には、開発の重複を減らすための共通のビジュアル コンポーネントを含めることができ、また、増分開発のコード慣性を確立するために OPOA プロジェクトのイベント配布原則を指定できます。逆に、ページ パフォーマンス インジケーターやレスポンシブ デザインの原則など、不適切な仕様は「抽象的」すぎるように見えます。また、他人の経験から学ぶことはできますが、他人から借りるには大前提があります。つまり、自分のプロジェクトの重要な問題を理解し、それらの重要な問題の解決を優先する必要があり、外国の標準が問題を解決できるということです。したがって、仕様はデスクマニュアルであり、一連の問題に対する解決策であり、「チュートリアル」ではなく「辞書」である必要があります。規範の源泉は「問題」であることがわかります。したがって、CoffeeScript を使用してプロジェクトをリファクタリングしたいとき、CommonJS 仕様を導入したいとき、ページに Bootstrap を統合したいとき、車輪の再発明を計画して JS ライブラリのセットを作成したいとき、アセット パッケージ ツールのセットを書き直したいときは、これらのものがどのような問題を解決するかを考えてください。新しい問題を引き起こし、物事を複雑にすることはありませんか。新しいことを試すためですか。それとも、さまざまな新しいテクノロジーを使用しており、それらに精通していることを履歴書に書くためですか。

仕様を策定するには動機が必要です。その動機はプロジェクトの要件から生まれ、さらに製品の理解と把握から生まれます。これは、初級の Web フロントエンド エンジニアが中級、さらには上級になるための重要な転換です。ソフトウェア エンジニアリングの分野では「アーキテクト」の役割が古くから存在しており、アーキテクトはプロジェクトの要件分析や概念設計および詳細設計の段階によく存在します。私が見てきたのは、Web フロントエンド エンジニアの考え方が「インターフェース」に限定されすぎているということです。彼らは、製品要件から遠く離れすぎています (これはビジュアル デザイナーの仕事だと考えている)、データ ロジックから切り離されています (これはバックエンド エンジニアの仕事だと考えている)。その結果、フロントエンドの仕様はほとんどが一般的でプロジェクトとは無関係になり、おもちゃのようになっています。

Yahoo の技術仕様の本来の優れた点は、問題を解決した点です。したがって、標準の使用を学ぶときは、もう 1 つ「なぜ彼らはこれをするのか」という質問をする必要があります。実際、これらの質問を明確に考えると、「山に遭遇したときに切り抜ける」という創造的な思考が自然に頭の中に形成されます。

【規範の破壊と確立 2】

新しい技術がターゲットを絞ったものではなく、少なくともプログラマーの清潔さと欲求を満たすものである場合、その「負担」はどこから来るのでしょうか? 初心者にとって、唯一の価値のある学習教材はこれらの仕様かもしれません。仕様が価値がないのであれば、どこから始めればよいでしょうか?

私が今言ったのは、規範に頼ることではなく、規範について考え、規範が私たちに植え付けた考え方を取り除くことです。新人はおそらくWikiで多くの指標、結論、実践を読んでおり、プロジェクトの開始時に多くの「ステレオタイプ」な負担を加えており、プロジェクトの重要な要件と重要な問題に対する洞察と判断にも影響を及ぼしています。負担が重すぎると、軽々しく戦いに臨むことができなくなります。Wikiに記載されている指標と仕様は決定的なものであり、多くの練習を経て得られたものです。多くの練習を経て初めて、これらの結論を真に理解することができます。たとえば、DomReady時間とhttpリクエストの数の間に因果関係はありますか？ httpリクエストの数が増えると、本当にページのパフォーマンスが低下しますか？ どのような条件下でパフォーマンスが低下しますか？ これらの記事と結論からは答えを見つけることはできません。

具体的な例を挙げると、Kissyは最近DPLをリリースしましたが、これも結論がたくさんあります。たとえば、そのレイアウトは古典的なダブルウィングデザインを採用しており、フローティングコンテナによって実装されています。では、このアプローチは揺るぎない「標準」なのでしょうか？Taobao Auto Insuranceのホームページを見てください。レイアウトコンテナはすべてインラインブロックです。トップレベルのコンテナの幅を削除する限り、レイアウトコンテナ自体はブラウザの幅に応じて自然な水平/垂直配置を調整でき、端末の幅に簡単に適応できます。

たとえば、Taobao 旅行プラン プロジェクトのデプロイメント方法では、依存関係の管理に Loader を完全に使用していません。代わりに、依存関係の階層を最小限に抑え、スクリプトを使用してビジネス ロジックをマージします。これにより、ビルド プロセスに構文チェックやコード スタイル チェックを簡単に追加できます。

本来のプログラミング思考を捨て、新しいアイデアと新しい方法を使って的を絞って問題を解決するというこのようなアプローチは、明らかに人々に爽快感を与えます。プログラミングの楽しさは、ルーチンを破ることにも反映されています。Xiao Maはかつて「標準を作ることは、標準を破ることだ」と言いました。これらの標準が仕事に負担をかけないようにしてください。簡単なページを作り始めると、ためらったり、手放せなくなったりするのです。大胆に実践することによってのみ、あなたは本当に自分自身の「結論」と「基準」を導き出し、その「結論」の意味を本当に理解することができます。より多くのコードを書けば書くほど、熟練度が上がり、成熟した技術的視点を形成しやすくなります。

このプロセスにおいて、私たちの唯一の敵は怠惰です。考えるのを怠ると、問題を真に発見することができず、当然、自分の意見を形成することもできなくなります。繰り返しになりますが、あらゆる規範、方法、結論、実践は、プロジェクトにおける問題を解決することを目的としています。したがって、私たちが接する「8部構成のエッセイ」スタイルの規範や基準も、特定の問題を解決するために提案されたものです。これらの問題について明確に考え、方法の背後にある「原因」を理解すれば、私たちの心の中に自然に「結果」が生まれます。

そのため、「今に焦点を当てて適切な薬を処方する」という品質が非常に価値あるものになります。たとえば、ダブルウィングレイアウト方式は、1セットの（html）コードが複数のレイアウトデザインに適応するという問題を解決するために設計されています。ここでもレイアウトは固定製品に対して固定されており、端末への適応はありません（モバイル端末に適した畳み込みレイアウトのベストプラクティスはないようです）。これがダブルウィング登場の背景です。現在、ターミナル環境は5年前と比べて大きく変化しています。問題はもはや「複数のレイアウト」ではなく「ターミナルの適応」です。これが私たちが直面している問題であり、新しい技術的解決策を考え出す必要があります。

したがって、私たちには、真剣に考え、荷物を軽くし、大胆に実践し、革新し、問題を発見し、（潜在的な）問題を実際的な方法で解決する能力が本当に必要なのです。固定観念の束縛から解放されると、突然の悟りの感覚を感じるでしょう。

2日目: インペリアル・カレッジの学者

【学者の経歴】

Webフロントエンドエンジニアは、インターネット分野にのみ存在する特殊な職種です。近年のインターネット業界の急成長​​により、フロントエンドエンジニアの需要が急増し、人材の供給がほぼ枯渇しています。大手企業の技術リーダーも同じような悩みを抱えていたはずだ。「信頼できるフロントエンドエンジニアを採用するのは非常に難しい」

その理由の 1 つは、現在のフロントエンド エンジニアの多くが転職してきた人々であることだと考えています。結局のところ、これはまともな学校では教えられていません。彼らは「ページの切り取り」について教えることは何もないと考えていますし、HTML/CSS が言語であることさえ考えていません。転職については詳しく説明する必要はありません。誰もが現在の市場の需要を狙っています。その結果、ジュニアのフロントエンドエンジニアは山ほどいるものの、中堅・シニアレベルの人材はなかなか見つからず、コンピューターサイエンスの学位を持つ人材はさらに希少です。これは一方では教育部門の遅れた認識を反映しており、他方では大多数の人々が迅速な成功と即時の利益を熱望していることも反映している。もちろん、最も重要な理由は、中国のいわゆる「第一世代のフロントエンドエンジニア」が十分な伝道活動をしなかったことです。これにより、基盤と可能性に対する人々の態度は、以前の無視から現在の軽蔑へと変化しました。いわゆる基礎とは、大学で学ぶ基本的なコンピュータコースのことです。いわゆる潜在能力とは、傲慢さや衝動性を防ぐ実用的な仕事のスタイルです。これらについては、この記事の後半で何度か触れます。

専門学校を卒業した学生にとって、良い家庭環境があることはそれ自体が有利です。事実は、これらの人々がフロントエンド技術における成長軌道に一定のパターンを持っていることを証明しており、彼らのほとんどは予想どおりにスキルボトルネックを突破することができます。人は大学を卒業してから、最も満足できる仕事に就くまで、いくつかの段階を経ることになります。

最初の2年間はスキルを学ぶ段階です。この段階の主な焦点は、専門スキルの向上です。少なくとも2年以内に平均レベルに追いつく、いわゆる「中級」です。この段階の人は通常、ソフトスキルにあまり注意を払わず、コミュニケーションスキルは平均以下です。基本的に与えられた仕事を何でもやり、完了できない場合は残業します。要求の合理性を十分に理解しておらず、プロジェクトをあまり制御していません。スキルの向上の余地があり、会社で最も必要な人材ではありませんが、成長の余地はたくさんあります。

2～3年働いている人は、フロントエンドのスキルが安定している傾向があり、これがスキルの最初のボトルネックです。そのような人は仕事に熟練しており、ページをすばやくカットできる可能性があります。コードは比較的標準化されているように見え、熟練した作業員です。彼らはコミュニケーションスキルと、人やプロジェクトをリードするなどのいくつかの専門スキルの蓄積に重点を置き始めます。少なくとも彼らはこの認識を持っており、プロジェクトを推進し、ビジネス関係者とニーズを競う経験を持っています。これは、中堅レベルの人が持つべき専門スキルに到達したことを意味します。ただし、特に「ページカットが専門」および「スクリプトの作成が専門」の人にとって、特定の主題に対する偏った態度を持つ可能性が最も高いのは、このときであることに注意する必要があります。結局のところ、html / css / jsは切り離せないものであり、3つすべてを有能なフロントエンドエンジニアが習得する必要があります。自分が偏っていることに気づいたら、注意が必要です。自分のギャップを明確に理解し、ボトルネックの存在を認識して、「中級」レベルへの移行の基盤を築く必要があります。

このハードルを乗り越えた後、3年以上勤務した人のスキルは大部分が安定しています。一部の人は新しいフロントエンド技術を研究し、日常業務を巧みにこなし、優れたソフトスキルを持ち、「借用」を狙っています。コードにも一定の構造があり、「コード移民労働者」のボトルネックを突破し始めています。彼らはチームの雰囲気、トレーニング、作業環境に対して個人的な要求を持っています。一般的に言えば、このような人々は潜在能力のある典型的な「中級」エンジニアですが、すぐにキャリア開発の2番目の技術的ボトルネックに遭遇するでしょう。

3、4年以上働いていて、常に新しいスキルの突破口を探している人が数人います。最も明らかな現れは、彼らが「基礎となるプロトコル」、つまりHTTP、サードパーティアプリケーション、システムドッキング、製造ツール、ワークフローなどに注意を払い始めることです。この時点で、思考の焦点は「ページを切る」ことから「解決策を考え出す」ことに移っています。たとえば、サイトを立ち上げたい場合、サイトのフレームワークを構築し、サイトのその後の（フロントエンド）開発におけるすべてのリスクを予測し、1つずつ解決策を提供できます。プロジェクトのその後の開発で問題が発生した場合、提供された「マニュアル」を確認するだけで答えを見つけることができます。このタイプの人は、標準的な「シニア」Web フロントエンド エンジニアです。

計画を立てることは非常に難しい作業であり、エンジニアには経験、技術、オーラなど多くのハードスキルが求められます。特に、技術的な基礎に対する要求は非常に高いです。

【中途半端な僧侶】

では、フロントエンド開発に転向する人はどうでしょうか。実は、開発の軌跡は専門の学者と非常に似ていますが、時間の幅はもっと長くなるかもしれません。特定の知識ポイント（HTTPプロトコルなど）の本質を理解するには、より多くのエネルギーを費やし、より多くのプロジェクトを実行し、より多くの反省と要約を行う必要があります。もちろん、これは単なる一般的な状況です。

さらに、これらの人々は多くの固定観念の束縛から解放される必要もあります。ここで、アダムの「Web フロントエンド開発を育成する方法」を読むことを皆さんにお勧めします。もちろん、あなたを道に導いてくれる信頼できる先輩がいれば、幸運は自然に千倍になるでしょう。

しかし、何があっても、私は常に、偶然であろうと故意であろうと、プロの学者であろうと後発者であろうと、まずは興味を第一にするという原則を守るべきだと信じています。そうすれば、「うまくやりたい」という気持ちが湧いてきます。私は自分の要求を他人に押し付けることはできません。そのため、多くの業界リーダーが自身の成功への道を振り返るとき、最も多く言及するのは「自分の仕事を愛し、仕事がもたらす課題を受け入れる」ということです。 NCZakas はかつて、次のように皆を励ましました。

「Web 開発者への私の最大のアドバイスは、自分の仕事を愛することです。クロスブラウザ開発の課題を愛し、インターネット技術のさまざまな異端を愛し、業界の仲間を愛し、ツールを愛してください。インターネットは急速に発展しており、それを愛さなければついていけません。つまり、もっと多くのことを読んで、もっと多くのことをして、自分の才能を日々成長させる必要があります。仕事の後は何もせずに過ごすことはできません。自分のために何か役に立つことをしなければなりません。オープンソース ソフトウェアの開発に参加したり、良い本を読んだり、素晴らしい人々のブログを読んだりできます。他の人が何をしているのかを知るために、頻繁にカンファレンスに参加してください。早く成長したいのであれば、できることはたくさんあり、努力は必ず報われます。」

原題：Taobaoフロントエンドエンジニア：国内WEBフロントエンド開発10日間

キーワード: タオバオ、フロントエンド、エンジニア、国内、WEB、開発、10日間、ずっと書きたかった、ウェブマスター、ウェブサイト、ウェブサイトのプロモーション、お金を稼ぐ