淘宝テクノロジーの年次特別号「学習は流れに逆らう船のようなもの、前進しなければ後退する - エンジニアの 2023 年成長総括特別トピック」を新たに創刊しました。特別トピックには 10 名を超えるエンジニアの真摯な歩みが含まれています。端末、サーバー、技術品質などをカバーする 2023 年の経験を考えます。技術分野では、これは同僚とのコミュニケーションを歓迎します。この記事はシリーズの 2 番目です——
最初の記事: 「私の 10 年間のテスト開発の旅について語る」
サーバー開発エンジニアの Tianwei は、
2023 年に淘宝テクノロジー アカウントで 6 つの記事を公開しました。彼は技術情報、ビジネスの蓄積、個人的な反省について
話しました。
合計 2023 年をお答えください
毎年冬になると、「応答せよ1988」を見る時期がやってきます～確かに、「応答せよ1988」は私が最も感動し、共鳴したテレビシリーズです。各章はテーマについて語り、人々が感じる最も単純な感情を表現しています。暖かい〜
この冬、一年を総括する機会があるのは、まさに「初雪」に出会うのと同じように、とても美しいことです。今年はイントラネットでたくさんの記事を書きましたが、外部のインターネットで共有できる記事もいくつかあります。これらの共有記事をベースにいくつかの章を作成し、「応答 2023」を「撮影」したいと考えています。私の最も単純な考えと感情を伝えるために〜
感動の「応答せよ1988」
第 1 章 数年前に作成: メタファーの実験
毎年年末になると、早めに地元に帰って休むために、数日余分に休暇を取っています。 2023 年初頭の春節の前に、チームは順番に「ドメイン駆動設計の実装」という本の共有を完了しました。私は DDD (ドメイン駆動設計、ドメイン駆動設計) に常に非常に興味を持っていたので、春節のこの時期に、理解をまとめてください。
当時の状況では、「適切な時期、適切な場所、適切な人々」がすべて揃っていた（十分な休暇、本を読んだ新鮮な記憶、そして仕事での経験）があったと言えますが、「すべての準備ができていて、必要なのは東風だけでした。」どうやって始めればよいのか、どこから始めればよいのかわかりません。
当初は本の概要に基づいて各章の理解と記録を書こうと思っていたのですが、いつも「面白みが足りない」「刺激が足りない」と感じていました。ある一点について真剣に考えた後、突破口を見つけるために「メタファー」関連の検索アイデアを使用し始めました。まず、子供の頃に見た漫画や、映画の高得点など、私が深く感銘を受けたものから始めました。大学、そして在学中の学習経験... ...そして、DDD を学習していたときの私の感覚と組み合わさって、ぼんやりとした、抽象的な、発散的な...
突然、私の頭に浮かんだのは、映画「フォレスト・ガンプ」で、みんながフォレスト・ガンプと一緒に走っているシーンでした。しかしフォレスト・ガンプが立ち止まると、誰もが呆然とした表情を浮かべた。
この「リンク ポイント」は、私を特に興奮させます。それは、フォローして学習するプロセスに似ているだけでなく、より考えさせられるものでもあるからです。たとえ「フォロー」していなくても、実際に努力していても、自分の思考と判断力が欠如していると、成長が非常に遅くなることがよくあります。良い検証ポイントは、潮が引いて先導者がいないときに、資産を置き忘れていないかどうかということです。独立して学び、前進する方法はありますか?
したがって、この記事はこの点を導入として使用し、最初に DDD を学習する過程での混乱現象を説明し、次に設計原則を指標として使用して、個人的な認識と思考について説明しています。全体が一貫していて、よく共感できます。
第 2 章: メモには及ばない: 知識を求めて
「一日中それについて考えていますが、それは一瞬で学んだことほど良くはありません。かがんでそれを眺めていますが、洞察力を得るために登るよりも優れているわけではありません。」経験を積み重ねて早く成長したいなら、読書などを通じて他人の経験や考えを理解し、理解と成長のサイクルを短くすることができます。
前回の記事「DDD理解」から久しぶりの記事です。学習内容そのものだけでなく、どの本を読むか、見つけるかなど、内容や方向性の決め方にも学習の難しさを反映しています。どの点を研究するかは難しく、不確実性がいっぱいです。
この記事では、生産業務や組織構造などの非技術的な側面に関連する「ビジネス レベルの分解」に焦点を当てます。この記事の背後にある、技術的な考え方の重要な補足です。 :
-
1つ目は「好奇心」と「知識欲」です。仕事では技術的な部分でみんなでコミュニケーションを取り合って話し合うことが多く、雰囲気が強いですが、「事業構造」「生産関係」など、 " , " 「戦略目標」やその他の「上位レベル」の部分が議論される機会はほとんどありません。この部分は「優れたビジネスセンス」につながることが多く、主に経験と洞察力に依存するとよく言われますが、核心はやはり「本当に理解して研究することに興味があるか」ではないかと思います。
-
2つ目は「学んだことを応用する」という心構えです。 前章でも触れましたが、DDDの記事を書く過程で「抜粋と理解」だけでは「面白み」が足りず、見どころが少ないと感じていましたが、これは主観的な判断であり、まだ「価値点」を認識していませんでした。構造化されたシステム知識を前にして、それが新しい視点を表現していなくても、リンクがうまくできていれば、それをうまく学ぶことは楽しいことです。たとえば、この視点を仕事に導入すると、周囲の人や物事と「共鳴」し、より良い「総合力」を形成することができます。
-
3つ目は「感性」と「意識」です。私が日々感じている「リンク配信の仕事」は、「DDDでのドメインの仕事」と重なる部分があまりなく、技術的には「真似」のような恥ずかしいものです。蓄積の面では、自分の仕事の指針を提供するために、いくつかの適切な「思考のトップレベルのカテゴリ」を見つけることが緊急に必要です。この「感覚」をもとに、ビジネスレベルでの「ビジネスデコンストラクション」と技術レベルでの「アプリケーションモデル」という2つの大きな指針が徐々に確立され、「DDD」は弱まり、今ではそこまで戸惑うことはなくなりました。仕事では常に「違和感」を感じながら、深く考え、微調整していくことで「ちょうどいい」感覚を見つけることができますが、それもまた「時代とともに進む」プロセスです。
記事を書く理由は仕事だけでなく、生活からも来ます。 『考える力：より良い判断を下す方法』はその一例です。
家が遠いので、毎日朝のラッシュに乗って長い距離を車で通勤しなければならないのですが、ここの交差点ごとの車線選択が何度も繰り返されますが、そんな日はめったにありません。スムーズで満足のいくものであり、常にそれ以上のものを見つけることができます。自分自身の判断ミス、または初心者ドライバーの場合などの偶発的な出来事が原因である可能性があります。
悲しいのは、人生も同じように、選択と判断に満ちているということです。したがって、仕事と生活における判断と選択の問題についての私の理解を一般化して説明し、このモデルに従って、もつれや繰り返される「時間の無駄」を減らしたいと思います。
整理してみると、「選択と判断」のポイントは3つあると思います。
-
1つ目は、判断の核となる要素であり、「思考モデルを改善する」というよりは、「情報を補完する方法を見つける」ということです。
-
2 つ目はモデルです。コアは依然としてインプットとアウトプットの定量的な式に基づいていますが、階層的です。
-
重要な要因がある場合、経験に基づいて、多くの場合考えずに判断できます。
-
多くの要因がある場合は、モデルを試し、さまざまなオプションの ROI を計算し、トレードオフを行う必要があります。
-
複雑な要因がある場合には、シミュレーション、実験結果に基づく判断、試作検証、ABテストなどもこの考えを反映します。
-
3 つ目はスキルです。回答の質を向上させるために、いくつかの判断戦略と関連リソース (顧客のニーズ、他の人の意見、明確な価値ポイントなど) を使用して選択と判断の回答を改善する方法を紹介します。
私が言わなければならないのは、この記事を書いたにもかかわらず、運転の「煩わしさ」は依然として存在しているということです。結局のところ、パターンやテクニックは完全な情報がなければうまく機能しません。しかしだからといって、この研究が無意味だというわけではなく、「前に新しい車がいるかどうかにもっと注意を払う」「橋を降りるときに前方の走行状況にもっと注意を払う」など、意識的に行動するようになります。 、特定の情報を収集した後は、「合理的な意思決定」を達成することもでき、自分の間違いを認め、「もしも...」に執着する必要がなくなります。
ケースを探しています: 紙の上で話す
昨年、「23のデザインパターン」と「6大デザイン原則」を理解した記事を書きましたが、皆様から「お褒めの言葉」をいただく一方で、「このことについて語っていただけますか？」という声も心に響きました。取引における特定のアプリケーション?
確かに、私たちは「紙の上で話す」ことや「簡潔に」話すことに慣れていることが多いですが、いざ実装となると、シナリオに関わる多くの細かい問題を解決する必要があり、複雑で一定の時間がかかります。個人的には「空虚な話」は好きではないのですが、残念ながら組織が大きすぎてシステムが多すぎて、あまり構築に関わったことがないので本当に話すことがないような気がします。 。
一歩下がって、他の人のコードを読んで理解しようとすることはできますが、実際の要件を満たしていなければ、その多くは見られず理解できないことを認めなければなりません。また、私はこれまでフォワードトレードのみを行ったことがあり、リバーストレードには参加したことがないため、トレード全体の視点も欠如しており、あえて「正確に」何かを言うことはできません。
しかし、一方では、いくつかの逆の要件に参加し、逆のシステム構造を理解し始めた一方で、より重要なことに、「エンタープライズ アプリケーション アーキテクチャ パターン」という本を読んだ後、非常に当たり障りのないものに感じました。 、それを心から感じるには、あまり上手に話す必要はなく、「現状の8割」を表現するだけで十分かもしれません。それ以来、私は自信を持ってこの一歩を踏み出すことができました。
このプロセスは実際には「機会をつかむ」ことであり、一方では自分の経験を補完し、完成度を高めることであり、他方では、うまく話せるかどうかの主観的な判断です。自信と勇気の向上。しかし、この過程で偶然のきっかけとなったのは、外部からのインプットを目にしたことであり、比較を通じて、いくつかのハイライトを書くことができると感じたとき、私は慎重さや臆病さがなくなりました。
このステップを踏まないと「もう少し待てばもっと良くなる」という状態が続きますが、このステップを踏めば継続的な改善が行われます。 「紙で話す」ことができ、コストも高くないのであれば、なぜわざわざ「紙で話す」のでしょうか？
私の作品: 曲がりくねった小道は静かな場所に通じています
-
-
任仙琦さんは、有名な作品がたくさんあるのはとても幸運だと語った。この作品の背後にある感情は何ですか? もしかしたら、私が皆の記憶に残り、頻繁に言及されることを望んでいるのかもしれません。あるいは、皆を助け、影響を与え続けるキャリアを持ちたいと思っているのかもしれません。これは本当に美しいことです。
個人的な経験から言えば、私はビジネス開発者として、ビジネス ニーズを評価し、コードを書き、オンラインに移行し、運用と保守を行い、一定期間が経過すると立場を切り替えて新しいサイクルを開始します。しかし、この長いプロセスの中で、私は常に周りの人々が終わりのない流れで「構造」を探求し、創造し、再構築しているのを見てきました。しかし、自分自身を振り返ってみると、説明が不足しているように思えます。 。
この種のアイデアはここ数年は明らかではなかったので、私はまだインプットに焦点を当てていました。しかし、年が経つにつれ、私は次のような疑問について考えるようになりました。仕事？この作品は純粋に欲しい、持っていると理解することができます。しかし、もっと深く考えてみると、私はやはり、私の数年間の努力を説明し、皆さんに認めてもらうための集合体となるような作品を作りたいと思っています。その背景には、言いたくても言い表せない、困難で孤独な旅がある。
幸いなことに、私はプロトタイプ システムを通じて「作業」と「非作業」の間に独立した論理空間を発見し、システム構造の理解をエクスポートし、4 つの記事 (「思考」、「アーキテクチャ」、「プロトタイプ」、 「実戦」）。この記事は、私が理解している知識の「引き算」であると同時に、独創的なテーマに基づいて簡潔にまとめられているので、非常に興奮します。これが出発点であり、学習した多くの知識やシステムに変換され、リンクされます。
「曲がりくねった道は隠遁へ導く」という言葉は、「作品」の論理を表すとても良い言葉だと思います。第一に、このプロセスは実際に非常に曲がりくねったものであり、比較的合理的な核心に到達するまでに、「山を山として見る、山を山として見る、山を山として見る」といった、しばしば矛盾した思考を繰り返す必要があります。第二に、出発点は見られたいという願望かもしれないが、結局のところそれはまさに「静かな場所への扉を開く」ことであり、それは繰り返しの自己認識の向上である。 、それは深くて平和な方向です。
『応答せよ1988』を観た後、エッセンスはまだこの美しい内容を手放すことを躊躇しています。
この記事は2023年に公開されたいくつかの記事をもとにストーリーや感想を語ります。振り返ってみると、どの記事も本当に難しかったです。今の大学受験のようなものでした。当時の「勢い」を取り戻すのは難しいです。しかし、私が言いたいのは、私たちは「読者」の気持ちを大切にしているので、この「粘り強さ」は今後も続くということです。まさに私、前に進むモチベーションです〜
サーバーサイドテクノロジー| 技術 品質 |
この記事は、WeChat パブリック アカウント - ビッグ タオバオ テクノロジー (AlibabaMTT) から共有されたものです。
侵害がある場合は、削除について [email protected] までご連絡ください。
この記事は「OSC ソース作成計画」に参加していますので、読んでいる方もぜひ参加して共有してください。
