Linux開発プロセス：ゲームはろうそくの価値がありますか？

Linuxは30年近く前から存在しています。このOSの初期の頃、Linus Torvalds自身が、Linux開発に貢献している他のプログラマーによって書かれたコードを操作していました。その後、バージョン制御システムはなく、すべてが手動で行われました。現代の状況では、同じタスクがgitを使用して解決されます。



確かに、この間ずっと、何かは変わっていませんでした。つまり、コードはメーリングリスト（または複数のリスト）に送信され、Linuxカーネルに含める準備ができていると見なされるまで、そこでレビューおよび議論されます。 しかし、コードを操作するこのプロセスが長年にわたって成功裏に使用されてきたという事実にもかかわらず、それは絶えず批判されてきました。たとえば、これ







MicrosoftのSaraNovotnyによる最近の記事は、インターネット上で多くの騒ぎを引き起こしました。その記事によると、Linuxカーネルの開発に使用されたコードコラボレーション手法は時代遅れです。 Linux開発者コミュニティが若い専門家をそのランクに引き付けたいのであれば、これらの方法をより現代的なものに置き換えるのがよいと言われています。これらのアイデアをめぐる議論の中で、彼らの擁護者と反対者は衝突しました。



私の立場から、Linuxカーネルの開発に関するいくつかのアイデアを提供できると思います。ほぼ10年間、私はLinuxや同様の方法で編成された他のプロジェクトのコードを書いています。 Red Hatにいたとき、x86カーネルインフラストラクチャコード、KVMハイパーバイザーとQEMUエミュレーターコード、およびXenハイパーバイザーコードに貢献しました。他のプロジェクトの開発にも参加しました。私は約7年間Linuxをあまりしませんでしたが、それはC ++（SeastarフレームワークとScyllaDBデータベース）での作業に時間を費やしたからです。..。これらのプロジェクトは両方とも、Linux開発で使用されているものと非常によく似た方法で開発されました。私は現在、ソフトウェア開発プロセスがLinuxで使用されているものとほぼ正反対であるDatadogでリードエンジニアとして働いています。これは、他のWeb企業での開発の編成方法にはるかに近いものです。



それで、私はどちら側にいますか？ Linuxの開発プロセスが気に入らないことをすぐにはっきりさせておきます。これは、新しい開発者にとっての障壁であるだけでなく、コードの高い生産性に対する障壁でもあると確信しています（そして、それは電子メールに関するものではありません）。これは、開発者が経験する否定的な感情の原因です。そして、私が仕事をどのように組織するかについて決定を下す独占的な権利を持っているプロジェクトについては、そのモデルに従うつもりはありません。



しかし同時に、Linux開発プロセスの多くの批評家は、その擁護者がそれを求めて激しく戦っているという事実は、Linuxコミュニティが伝統と口実の下で変更する気はありません。これは事実ではありません（Linuxコミュニティにはそのような人々がいると確信していますが）。 Linuxカーネル開発プロセスは、ユーザーにいくつかのユニークで重要な利点をもたらします。同じ原則を他のプロジェクトに適用する場合、そのようなプロジェクトはそれからのみ利益を得るでしょう。



電子メール以外の他のツールは、それらを使用する人に指示しますが、かなり厳格な作業スキームであり、Linuxからそのような利点を奪います。そして、メーリングリストは討論者の注意を引く注目に値するメカニズムにすぎません。 Linux開発者の参入の障壁を下げることができるツールが必要です。開発プロセスの欠陥を修正できるツール。さまざまな組織がLinux開発組織の長所を認識できるようにするもの。このようなツールは、ソフトウェア開発業界全体に大きな違いをもたらす可能性があります。



非常に有益なこれらのメカニズムの多くがあります。会話が長引くことのないように、私が最も重要だと思うものの1つに焦点を当てます。私はその本質を明らかにし、その強みにもかかわらず、それが開発者に非常に多くの否定的な感情を引き起こす理由について話すために最善を尽くします。また、一方では他のプロジェクトに利益をもたらすことができる理由、もう一方ではLinuxにとって非常に重要である理由についても説明します。

メッセージとパッチをコミットする

Linuxカーネル開発の世界では、ルールがあります。カーネルに含めることを目的としたコードは、個別のパッチに分割する必要があります。それらのそれぞれは、たった1つの問題を解決する必要があります。パッチごとに意味のあるコミットメッセージを用意する必要があります。そのようなメッセージは、それらが説明するコードよりも長いことがよくあります。



これは、他のプロジェクトに一般的に欠けているものの代表的な例です。 GitHubの最新のプロジェクトで見たコミットメッセージのほとんどは、「8月25日の変更」のように見えるか、「関数Xの実装」のようにわずかに（ただしわずかに）良くなっています。将来、誰かがこのようなコードを見る必要がある場合、そのような変更がコードに加えられた理由を理解するのは簡単ではありません。これらのコミットで修正されるバグのいくつかは微妙かもしれません。このようなエラーがどのように正確に修正されたかわからない場合は、簡単にプロジェクトに戻ることができます。短くて意味のないコミットメッセージを読んでいると、バグが発見された状況に気付かないかもしれません。



これが小さな例です。Linuxカーネルへのコミットを見てください私の親友のヨハン・ワイナーによって。別のプロジェクトで、同様のコミットへのメッセージが「警告の削除」のように見えることは想像に難くありません。そして、ここで説明したコミットのメッセージを読むと、プロジェクトに害を及ぼすことなく、これらの警告を取り除くことができる理由、これが実際に悪いことを引き起こさない状況、そして何について学びます。ある日このコードを変更することが決定された場合は、規則に従う必要があります。



多くの組織にこれを行う人々がいると確信しています。ただし、Linuxカーネルで作業する場合、このビジネスに関与するすべての人がこれを行う必要があります。したがって、コミットメッセージを読むことで、対応するコードの変更について理解するために必要なすべてのことを理解できると確信しています。エラーについて話している場合は、それがどのシステムで発生したか、どのような状況で発生したか、なぜ他のシステムに影響を与えなかったのか、このエラーがプロジェクトに戻らないように注意する必要があることについて学習します。



この種の作業は、どの組織でも非常に望ましいものです。これにより、他の人（および開発者自身がしばらくして自分のコードに目を向けたとき）が、コードに変更を加える理由を理解し、コードがそのように機能する理由を理解しやすくなります。これにより、新しいプログラマーがプロジェクトを簡単に知ることができます。これにより、古いエラーが返されるという問題が解決され、問題のコードとは無関係に見えるコードが何かを壊す可能性が低くなります。



他のプロジェクトでは、これは「非常に望ましい」です。しかし、Linuxでは、次の2つの理由で絶対に必要です。

1. Linux . , . Linux, , - . , , , . ( ) , Linux. , Linux.
2. (). Linux, . , 2020 , Linux , LTS-. , , - , Linux LTS-, Linux. , 2000- , . , , Red Hat .

バックポートは通常、複数の並列製品ラインを維持する必要がない現代のオンライン企業にとっては問題ではありません。彼らは何かを作成し、それをユーザーに渡します。それで終わりです。しかし、バックポートが機能するようになると、事態はさらに複雑になります。開発者（おそらくプログラムの作成者ではない）は、現在のコードベースとはわずかに異なる古いコードベースにコードをわずかに適合させる方法を決定する必要があるかもしれません。そして、リスクを最小限に抑えるソリューションは、多くの場合、大規模な変更セットの特定の部分を実装するためだけにパッチを作成することで構成されるソリューションです（多くの場合、そうです）。バグを修正するための5行のコードを含む2,000行のコミットを想像してみてください。また、APIをリファクタリングした後にこのエラーが発生したと想像してください。あなたは何を選びますか：膨大な一連の変更に基づいて、または十分に文書化され、十分に文書化された、分解されたパッチに基づいてバックポートを準備しますか？私は、数え切れないほどのバックポートを作成した人として、そのような質問にどのように答えるかをすでに知っています。



さて、バックポートの有無にかかわらず、変更を注意深く文書化することに大きな重点が置かれている場合、プロジェクトはこのように編成されることの利点に対して高い代償を払わなければなりません。ここで、プログラマーはコードだけでなく、コードを再編成してプロジェクトの作業ルールに合わせる方法にも注意を払う必要があります。



これらのコードリファクタリングのいくつかは単純です。 git add -pコマンドを使用して、変更のバッチに何を入れるかを選択することについて話しているとしましょう。プログラマーが個々のコードフラグメント間の循環的な依存関係に直面すると、事態は少し複雑になります。この関数をプロジェクトに追加した後にプロジェクトに追加されるタイプのオブジェクトを返す関数を想像してみてください。この状況に対処するには、コードを使用する必要があります。その結果、完成したプロジェクトには入りませんが、一時的な解決策の役割を果たすだけです。



これらすべてがプログラマーに頭痛の種を追加しますが、そのようなタスクが完全に解決できないとは言えません。外科的精度で、行うすべてのことを、使いやすく便利な断片に分割したとします。実際の問題は、他のプログラマーがあなたのコードを見始めた後に始まります。どの組織でもコードレビューは非常に重要です。専門家は他の誰かのコードを読み、それに対する変更を提案（または要求）します。



プログラマーが、一連の修正の最初のパッチに存在する特定のメソッドに新しいパラメーターを追加するように求められたとします。また、このメソッドが後続のすべてのパッチで使用されると仮定しましょう。



これは、プログラマーが最初のパッチに戻って、メソッドに新しいパラメーターを追加する必要があることを意味します。その後、次のパッチは適用できなくなります。したがって、プログラマーはこれがなぜそうなのかを戸惑うだけでなく、すべてのエラーを手動で修正する必要があります。個々のパッチがすべて以前にテストされていた場合、これらのテストの結果は古くなっているため、パッチを再度テストする必要があります。



作業の再編成は小さな問題です。しかし、すでに行われたことをやり直すことは、はるかに深刻な問題です。



Linux開発者コミュニティとこのコミュニティに関係する人々に伝えたいことは次のとおりです。もちろん、これはすべて実行可能です。しかし、これが若い専門家の参入障壁ではない場合、私は「参入障壁」と呼ばれるものすら知りません。すでに行われたことの再編成、書き直し、やり直しに時間、労力、神経、コンピューターリソースを費やす必要性は、プログラマーが目指していることではないことは明らかです。この点で、私は定期的にこの形式で現れる1つのアイデアに出くわしました：「...しかし、優れたプログラマーはこれに問題はありません。」また、次のように表現されています。「しかし、それはプログラマーに特定の考え方、まさに優れたプログラマーが持つべき種類を教えます。」この種の推論は私には不誠実で役に立たないように思えます。確かに：このメソッドのすべての長所をリストしましたが、これらのコードリファクタリングはすべて面倒で退屈な作業であることがわかりました。それはアパートの掃除に例えることができます。家がきれいに保たれているととても良いと誰かが言ったとしましょう（私はそれに同意します）。同じ人が床を掃除機で掃除することはかなり可能ですが（私はできます）、彼はそうしないことがよくあります。この理由は単純です。彼には他にももっと重要なことがあります。たとえば、Roombaロボット真空クリーナーを持っていることを非常に嬉しく思っているのはそのためです。このことで、私は清潔さを楽しむことができ、同時に自分で物事を整理することに従事することもありませんでした。これは、Linuxの世界以外の人々に向けられた私の次の考えに私をもたらします。これらすべてのコードリファクタリングは面倒で退屈な作業です。それはアパートの掃除に例えることができます。家がきれいに保たれているととても良いと誰かが言ったとしましょう（私はそれに同意します）。同じ人が床を掃除機で掃除することはかなり可能ですが（私はできます）、彼はそうしないことがよくあります。この理由は単純です。彼には他にももっと重要なことがあります。たとえば、Roombaロボット真空クリーナーを持っていることを非常に嬉しく思っているのはそのためです。このことで、私は清潔さを楽しむことができ、同時に自分自身を片付ける必要がなくなりました。これは、Linuxの世界以外の人々に向けられた私の次の考えに私をもたらします。これらすべてのコードリファクタリングは面倒で退屈な作業です。それはアパートの掃除に例えることができます。家がきれいに保たれているととても良いと誰かが言ったとしましょう（私はそれに同意します）。同じ人が床を掃除機で掃除することはかなり可能ですが（私はできます）、彼はそうしないことがよくあります。この理由は単純です。彼には他にももっと重要なことがあります。たとえば、Roombaロボット真空クリーナーを持っていることを非常に嬉しく思っているのはそのためです。このことで、私は清潔さを楽しむことができ、同時に自分自身を片付ける必要がなくなりました。これは、Linuxの世界以外の人々に向けられた私の次の考えに私をもたらします。同じ人が床を掃除機で掃除することはかなり可能ですが（私はできます）、彼はそうしないことがよくあります。この理由は単純です。彼には他にももっと重要なことがあります。たとえば、Roombaロボット真空クリーナーを持っていることを非常に嬉しく思っているのはそのためです。このことで、私は清潔さを楽しむことができ、同時に自分で物事を整理することに従事することもありませんでした。これは、Linuxの世界以外の人々に向けられた私の次の考えに私をもたらします。同じ人が床を掃除機で掃除することはかなり可能ですが（私はできます）、彼はそうしないことがよくあります。この理由は単純です。彼には他にももっと重要なことがあります。たとえば、Roombaロボット真空クリーナーを持っていることを非常に嬉しく思っているのはそのためです。このことで、私は清潔さを楽しむことができ、同時に自分で物事を整理することに従事することもありませんでした。これは、Linuxの世界以外の人々に向けられた私の次の考えに私をもたらします。Linuxの世界以外の人々を対象としています。Linuxの世界以外の人々を対象としています。



Linuxコミュニティの外部の人たちに言いたいのは次のとおりです。Linuxでの作業に使用される開発プロセスには非常に真の強みがあります。一部のツールは、Linuxで動作しているタスクに完全に対処できません。たとえば、GitHubは、既存のコードの後に​​常に新しいコードが追加されるプロジェクトで優れた機能を果たします。もちろん、git push --forceコマンドを使用して、特定のブランチをリポジトリに強制的に含めることもできますが、コミットに添付されたコメントは実際には「宙に浮いた」状態になり、このコミットの説明は無意味になります。



最新の開発ツールは非常に単純化されています。これらを使用すると、特定の条件が発生したときに一部のアクションの実行をトリガーでき、継続的な統合およびプロジェクト展開プロセスをサポートし、コードの変更についてプログラマーに通知し、他の多くのタスクを解決します。しかし、それらは確かに、誰かの作業の結果を、作業が簡単で便利な小さな断片に分解するプロセスを複雑にします。プレーンテキストの電子メールの使用は非常に複雑ですが、この作業の編成は、特定の目標につながる開発プロセスの適用を妨げるものではないことに注意してください。



既存の開発プロセスを放棄することで、Linuxエコシステムがどれだけ勝ち負けたのか（何も失わなかったのか）を客観的かつ正確に評価できたとしても、何も変わることはありません。事実、人々が以前に実際に非常にうまく示したものを保存しようと努めるとき、現在の状況は人間の本性を完全に示しています。

この状況から抜け出す方法はありますか？

Linuxコミュニティがその開発方法論から得られるのと同じ利点をさまざまな組織に提供できるツールがあれば、それはすべての人にとって非常に有益であると心から信じています。そして、そのようなツールが存在した場合、おそらくLinuxコミュニティでさえ通常のテキストメールをそれらに置き換えることができます。



そのようなツールがどのように見えるかという質問に対する答えはありません。しかし、私は自分自身にチャンスを与えて、それらについて少し考えさせます：

1. Git — . , , , , . GitHub, - git-, «-» Linux, git, . , -, , , , . Git . CSS HTML, — , CSS HTML- . , HTML CSS? , , , .
2. , , , , , . , , , ? . , : « create_foo() , create_bar()», : « create_bar() y, ». , , . , , , , GPT-3, , .
3. , , , , - , . , , , . , , , , , , , , , .

-, Linux?