国内オープンソースプロジェクトについての私の考えそれぞれの考えや意見には限界があるかもしれないので、何らかの見解を提示する前に、全員が批判的な観点からアプローチし、それをよく考える必要があります。 プロジェクトのオープンソース化は非常に崇高で興味深いものです。これは私が常に抱いてきた考えです。海外のTJや中国のUncle Tomのようなオープンソースの先駆者たちは、常に私の技術的なアイドルでした。 彼女たちと私に共通していたのは、髪のボリュームが少ないことだけでしたが、それが私にとってはいくらか慰めになりました。 したがって、これらの優れたオープンソース プロジェクトを読むことは、私にとって大きな成長に役立ち、また、真に価値のあるオープンソース プロジェクトを作成する方法も学びました。 しかし、ここ2年間、GitHubのトレンドを見ていると、どうしても少し気まずさを感じ、無力感も覚えるようになりました。国内のオープンソースプロジェクトが本質的に搾取的なケースを数多く目にしてきたので、メモ用紙にこんな一文を書き留めずにはいられませんでした。
さて、愚痴はここまでにして、優れたオープンソースプロジェクトについての私の考えをまとめたいと思います。 プロジェクトの自己生成構造の観点からプロジェクトのディレクトリ構造は明確です。 ファイル/フォルダの命名規則により高い読みやすさが保証されます。 明確で完全なReadmeの紹介
適切に構造化された詳細な package.json ファイル(またはプロジェクト説明ファイル) プロジェクトの実現性の観点から
もちろん、基盤となる技術的ソリューション (オペレーティング システム、基本言語など) など、検討できる他の方向性もありますが、それらは現在の状況からかけ離れているため、今は脇に置いておきます。 国内のオープンソース プロジェクト/コミュニティのネガティブな傾向は、採用における「退化」をどのように加速させているのでしょうか。
ここ2年ほど、大手テクノロジーコミュニティに就職活動や面接関連の記事が溢れていることに気づいていますか?記事の質は大きく異なり、ほとんどすべての記事が似たり寄ったりです。真剣に技術記事を読みたいなら、何度もスクロールダウンして時間をかけて探す必要があります。なぜなら、上位のおすすめ記事は、基本的に面接や大企業への就職に関する記事で占められているからです。 就職活動には準備が必要ですが、個人的には過剰な準備は必要ないと思っています。そうでないと、必ずと言っていいほどお馴染みの「面接王」と「キャベツみたいな就活生」の愛憎関係に陥ってしまうからです。
ここでは、面接の質問に過度にさらされると、なぜ質問が増えることになるのかを分析します。 面接官は考えました。「どんな質問をしようか?」コミュニティにはたくさんの面接経験者がいるので、きっと皆さんも準備されているはずです。もっと挑戦的な質問をしてみましょう。 求職者はこう考えました。「最近、いろいろな面接体験談を読んでいるのですが、大手企業も中小企業も、面接の質問はとても難しい。もっと練習しなくちゃ。」
はい、まだ終わりではありません。次はGitHubにある1000以上の面接/筆記試験の質問です。ぜひ練習してみてください。もしこれらの質問を解いた後でも大企業に入社できなかったとしても、それは質問のせいではなく、あなたのせいです。 ああ、こんな環境で育ったプログラマーたちは、将来の技術開発に向けてどれほどの想像力を働かせることができるのだろうか。これは、私が憧れるもう一人の人の名言を思い出させる。
私はまた、想像力が火星にまで達した外国人の友人のことも思い出しました。
したがって、このセクションでは主に次の 3 つの点を述べたいと思います。
これはこれらの活動を否定するものではなく、コーディングの課題に過度に重点を置くことを控えるようにというものです。時折、価値あるオープンソースプロジェクトに携わることは、面接の可能性を高めることに繋がります。実際、私は3年近く就職活動と面接を受けてきましたが、面接の準備を一切したことがありませんでした。 オープンソース プロジェクトに取り組むことでどのようなメリットが得られますか?これまでのセクションで議論した点から、貴重な洞察を抽出してください。それでは、本日の本題に移りましょう。 オープンソースプロジェクトに参加することで何が得られるのか?これは、オープンソースプロジェクトに携わりたいと考えているほとんどの人が抱く疑問でしょう。そして、多くの人が誤解している点もあります。一見単純な質問のように見えますが、実は単純な質問の方が複雑な場合が多いのです。 オープンソースプロジェクトは、プロジェクト経験を積み、履歴書を充実させ、知識基盤を強固にし、知名度を高めるのに役立つと考える人もいます。私も以前はそう思っていました。しかし、このオープンソースマインドセットは初心者にしか通用しません。オープンソースプロジェクトは技術的なスキルを深め、履歴書に記載できる可能性はありますが、最終的には忘れ去られてしまうというのが一般的な結論です。 したがって、この問題を検討する前に、私はいつも自分自身にいくつかの質問をします。
上記の 4 つの質問に答えることで、オープンソース プロジェクトに取り組む際の目的と枠組みがより明確になり、そこから何を得られるかについてもより意識できるようになります。
したがって、結果を追い求めすぎてはいけません。価値あるオープンソースプロジェクトを生み出す過程で、私たち自身の価値も自然と高まっていくのです。H5-Dooringプロジェクトを開始する前に、私はすでに上記の4つの疑問に完全に答えていたので、プロジェクトの最終的な結果は誰の目にも明らかです。H5-Dooringの最初のバージョンを完成させた後、4つ目の疑問を解決するために、同じ志を持つ数人の友人を選び、一緒にイテレーションを行い、プロジェクトが事前に計画されたスケジュールに沿って前進し続けることができました。 非常に効率的で迅速に反復できるオープンソース プロジェクトをゼロから構築するにはどうすればよいでしょうか? 私自身の経験を証拠として、オープンソース プロジェクトを改良するプロセスについてお話ししたいと思います。 なぜこのプロセスがハート型なのかは聞かないでください。ただ、オープンソースの作者10人中7人が愛からこの活動を行っているということをお伝えしたいのです。(だから、この素晴らしい人たちに心の中で感謝の気持ちを伝えたいのです!) 1. 対象計画期間まず、なぜこのプロジェクトを行うのかを明確にした上で、オープンソースプロジェクトの明確かつ包括的なロードマップを作成する必要があります。例えば、バージョン1.0にどのような機能を含める必要があるか、どの機能は優先度が高く必ず完了する必要があるか、そしてどの機能は緊急性が低く後からでも完了できるかなどです。そのためには、4象限法を最大限に活用する必要があります。 次に、機能を明確に定義し、要件プールを管理することが重要です。一度にすべての要件を受け入れるのではなく、要件をフィルタリングする方法を学びましょう。ユーザー自身が自分が作成している要件を理解していない場合もあるため、レビューは不可欠です。 上記の目標計画と管理の原則に従うことで、明確で効率的な目標計画を作成できます。 2. プロジェクトインフラ構築フェーズプロジェクトのインフラストラクチャフェーズでは、主に初期プロトタイプの作成が行われます。この段階は、プロジェクトリーダーが基盤を構築する上で極めて重要です。テクノロジーの選択、アーキテクチャ、ソリューション設計全体について、包括的な理解と実装計画が必要です。これは、将来のチーム開発、イテレーション、そしてプロジェクトの最適化の基盤となります。そうでなければ、混乱に陥ってしまいます。H5-Dooringは初期段階でこのアプローチを採用しました。まず、私はプロジェクトのワークフロー全体を設計し、GitHubでオープンソース化しました。これにより、同じ考えを持つメンバーのグループを見つけ、メンテナンスと最適化を行うことができました。 3. チームビルディングフェーズチームビルディングも重要なステップです。まず、創業者は以下の資質を備えている必要があります。
上記の特性のうち少なくとも 3 つを備えている場合にのみ、非常に効率的でまとまりのあるチームを構築できます。 同時に、同じ価値観を共有し、プロジェクトに興味を持ち、一定の実行力を持つ協力者を選ぶことでのみ、オープンソースプロジェクトは着実に発展していくことができます。したがって、チームが大きいからといって必ずしも進捗が速いわけではなく、チームが小さいからといって必ずしも進捗が遅いわけではありません。だからこそ、多くの友人がDooringに参加したいと言い出した際には、私は個人的に彼らと話し合い、基本的なアセスメントとスクリーニングを行いました。現在、DooringXチームは小規模ですが、メンバー一人ひとりが独自の専門性を持っており、将来必ず素晴らしいプロジェクトにしてくれると確信しています。 4. チームのコラボレーション/調整期間チームワーク/結束とは、タスクを割り当てるときに私たちがお互いに行うコミュニケーションと相互作用を指します。 共同開発者一人ひとりに、共通の目標とそれぞれの役割を明確に伝える必要があります。この段階は、チームを評価するのに最適な時期です。各チームメンバーの得意分野、対応可能なタスク、そしてプロジェクトを通して成長・向上につながるタスクを把握することができます。 そのため、定期的なコミュニケーションは不可欠です。ドアホッピングの初期段階において、相性の合わない友人がいることに気づきました。時間がない人もいれば、価値観の違いがある人もいました。これらはすべてコミュニケーションを通して解決する必要があり、解決できない場合は断固たる態度で対処する必要がありました。プロジェクトの発起者は個人的な感情を過度に考えるべきではありません。誰にとっても比較的快適な環境を作ることが最も重要です。結局のところ、誰もがそれぞれ達成すべき目標を持っているのですから。(少し別れ話のようですが、この辺で止めておきます🐷) もう一つの重要なポイントは、才能を活かすこと、そして優れた提案には謙虚に耳を傾けることです。誰もがチームに貢献する存在であり、それぞれが責任を負っています。目標という大きな流れに沿って継続的に前進していくためには、適切な役割を適切な人材に割り当て、優れた人材がチームを率いて共に成長していくことが重要です。創設者はプロジェクト成功の原動力となるため、優れた提案や開発の方向性を受け入れ、自らの限界を見極める必要があります。結局のところ、誰もがそれぞれの強みを持っているのです。 5. バージョンの反復とレビュー期間プロジェクトの各段階では、振り返りと反省が必要です。そのため、タスクの完了は単なる第一歩に過ぎません。長期的な発展の鍵は、プロジェクトをどのように改善していくかにあります。チーム全員が提案を出し、それぞれの視点を共有し、開発の方向性について議論し、常にブレインストーミングを行い、最良の結果を達成します。もちろん、PDCAサイクルと同様に、慎重な管理とトレードオフも不可欠です。 価値あるオープンソースの方向性とプロジェクトを共有するオープンソースプロジェクトの実用性に関するセクションで、オープンソースの方向性を選択することについて既に説明しました。しかし、選択はあなた自身の好みと強みに基づいて行うべきです。以下に、オープンソースの方向性として考えられるものをいくつか挙げます。
創設者たちは皆とても親切なので、次のような既存のオープンソース プロジェクトに参加することもできます。
この記事は、WeChat公式アカウント「Fun Talk About Front-End Development」から転載したものです。以下のQRコードからフォローできます。転載の許可については、「Fun Talk About Front-End Development」公式アカウントまでお問い合わせください。 |