先週、あるCppJiebaの使用者からのメール相談に触発され（なぜ多くの人がissueではなくメールで相談するのか不思議です）、CppJiebaのコードをリファクタリングし、各APIを高度に統合しました。ユーザーにとって使用がより簡単で、より始めやすくなりました。そして、CppJieba v3.0.0とNodeJieba 1.0.0をリリースしました。
これら2つは私がGitHubで最もスター数が多い2つのプロジェクトで、メンテナンスしてからもうすぐ2年になります。GitHubをより良く見せるだけでなく、収穫は非常に大きいです。GitHubはIT界全体の知識の宝庫で、ここ数年最も多くの知識を学んだのは、ほとんどがGitHub上のオープンソースプロジェクトからです。
よく学生からオープンソースプロジェクトをどう学ぶかと聞かれるので、オープンソースプロジェクトを学ぶいくつかの方法についてブログを書くことにしました。
最初はすべて非常に簡素
その日、私はNode.jsコード考古学について微博を投稿しました：
ソフトウェア考古学は本当に面白いです。非常に古いバージョンをチェックアウトして、nodeの最初の頃のMakefileを見ると、突然ゲームのイージーモードを開いたような気がします。
当時、卑しい興奮を感じました。なぜなら、Node.jsの最初も非常に簡素だとわかったからです。しかし、簡素はしばしばシンプルを意味します。例えば、最初のNode.jsはMakefileを使用して管理されていました。すべてのコンパイル可能ファイルが一目瞭然でした。現在のnode-gypではなく、大量のソースコードがあり、これらのファイルの相互関係を理解するだけでも長くかかります。
これらは私がCppJiebaを書き始めた時と同じです。C++という言語の標準ライブラリの欠陥、C++11の普及がいまいちで、多くの一般的な機能のライブラリは、みんなboostのようなライブラリを使用しています。私と同じように感じる人が多いかどうかわかりませんが、C++のコードを使用するたびに、最も嫌なのは、様々な依存コードをインストールする必要があることです。しかも、依存コードのバージョン問題で、インストールが失敗することがよくあります。この状況はLinux上で特に深刻で、vczhがLinuxでソフトウェアをインストールすることを皮肉ったことさえあります：「使用説明ではなく、使用攻略を見ている。」
だから、私は最初からサードパーティライブラリに依存しないと決め、必要な関数はすべて自分で書きました。そのため、私がよく使うC++ライブラリlimonpが生まれました。最初のコードは非常に簡素でしたが、少なくとも、私のプログラムは依存ライブラリをインストールすることなく直接実行でき、超軽量でした。もちろん、単体テストはgtestに依存していましたが、gtestのソースコードを自分のプロジェクトコードに統合しました。
事実、これは非常に重要です。やはり、依存がなければ、傷つくこともありません。そして後に、ideawuのSSDBもそうでした。このようなオープンソースプロジェクトこそ、ユーザー体験を重視するオープンソースプロジェクトです。
自分のコードスニペットを蓄積する
practiceというプロジェクトがあり、自分のコードスニペットを蓄積するために使用しています。新しい技術に触れる時、いくつかの小さな練習コードを書く必要があり、練習コードをこのリポジトリに入れます。実は、これらの小さなスニペットは大きなプロジェクトの種です。Node.jsコード考古学でわかるように、最初のNode.jsも作者の実験的なコードで、JavaScriptを使用して非同期IOサービスを書く実験的なコードでした。（最初のコードは、サービスがリクエストを受け取った時、jsソースファイルを読み込み、実行結果を返す、ただそれだけでした。）
例えば、私が書いた簡単なHTTPサーバーも、いくつかの小さな実験的なコードから組み立てられました。例えば、socketの送受信、HTTPヘッダーの解析、BlockingQueueを使用したスレッドプールの構築など。これらは一般的なコードですが、組み合わせるとプロジェクトになります。そして、これらのコードスニペットを書くことは、新しい技術を学ぶのに非常に役立ちます。後で振り返って見ることもでき、今はGitHubという良いコミュニティがあり、以前プログラミングを学んでいた時よりずっと便利です。
前人の肩の上に立つ
これはよく理解できることで、他人の分析ドキュメントを活用することです。Redisのソースコードを深く読むなら、まず『Redis設計と実装』を読んでからソースコードを見るのが良いでしょう。迷路を歩く時、誰かが地図をくれたようなもので、ずっと楽になり、沿道の風景も楽しめます。
しかし、理解できないのは、なぜ多くの人が硬くなめるのが好きなのかです。私は非常に新しいオープンソースプロジェクトに遭遇し、関連する前人のドキュメントが検索できない場合のみ、硬くなめざるを得ません。しかし、現在、オープンソースプロジェクトの作者はドキュメントを重視しており、一般的に自発的にいくつかのソースコードドキュメントを書いています。
学習の観点から言えば、オープンソースプロジェクトはスター数が多ければ多いほど良いわけではない
オープンソースプロジェクトはスター数が多ければ多いほど良いわけではなく、あなたにとって読みやすければ読みやすいほど良いです。一般的に、現在の仕事に近いほど読みやすいです。仕事に近い場合、ソースコードを読むことで開発やリファクタリングのインスピレーションが得られます。いくつかのファイル名、クラス名、ソースコードのコメントを見るだけで、どのような技術が使用されているかわかり、関連技術の記事や論文を検索して詳細に研究できます。これらはすべて非常に役立ちます。
読むソースコードが自分の仕事の内容と全く関係ない場合、理解も不十分で、数日で忘れてしまいます。基本的に、自慢する時の自慢話にしか残りません。
高性能なコードを見ることばかり追求するのは実は良くありません。「コードは人間が読むために書かれ、ついでに機械で実行できるだけです。」しかし、多くのスターオープンソースプロジェクトは性能が非常に重要で、時には読みやすさを少し犠牲にして高性能を実現しなければなりません。そして、スター数が多いスタープロジェクトは、考えることが多く、互換性、運用のしやすさなど、すべてかなりのコード量です。そして、これらは実はプロジェクトの核心ではありません。ソースコードを読むには、核心が読みやすければ読みやすいほど良いです。
いくつかの感想
最近、オープンソースプロジェクトの作者がますます注目され、オープンソースプロジェクトがますます功利的になっていると感じます。
オープンソースプロジェクトの本来の目的を忘れないでください。それは知識のより良い共有と伝播のためです。
転載请注明：开发者关系 »
