3.5年、50万行の囲.。 パート1

これは、ネイトフィンチの記事の翻訳です- オリジナル （2017年3月24日公開）

Go- Jjujuで書かれた最大規模のオープンソースプロジェクトの3.5年の作業の後、2017年1月31日はCanonicalでの最後の日でした。

執筆時点では、メインのJujuリポジトリは3,542ファイル、540,000行のGoコードです（この数には65,000行のコメントは含まれていません）。 標準ライブラリを除くすべての依存関係を考慮すると、Jujuには9,523個のファイルが含まれ、その中には1,963,000行のGoコード（331,000行のコメントを除く）が含まれています。

このプロジェクトの約7,000時間の作業から学んだ教訓を次に示します。

Jujuチームの全員が私に同意しているわけではなく、コードベースが非常に大きいため、1年間作業してコードの2/3を見ることができないことに注意してください。 そのため、次のことを懐疑的に考えてください。

ジュジュ

Jujuは、NomadやKubernetesなどに似たサービスオーケストレーションツールです。 Jujuは（主に）2つのバイナリファイルで構成されます：クライアントとサーバー。 サーバーはいくつかの異なるモードで動作できます（サーバーがいくつかの異なるファイルの形式になる前は、99％同一であったため、配布しやすいファイルを作成する方が簡単でした）。 サーバーは、選択したクラウドで実行できます。 個別のマシンで複数の追加インスタンスを実行でき、それらは中央サーバーによって管理されます。 クライアントおよび補助マシンは、RPC over Webソケットを介してメインサーバーと通信します。

ジュジュは一枚岩です。 マイクロサービスはありません。1つのバイナリファイルが必要です。 Goは競争力に優れているため、ゴロチンが何かをブロックすることを心配する必要はありません。 したがって、すべてを1つのプロセスで使用すると便利です。 シリアル化や他のプロセス間相互作用によるオーバーヘッドを回避できます。 これにより、コードの相互依存性が高まりますが、開発において責任の分離が常に最優先されるわけではありません。 結局、モノリスは小さなサービスの束である場合よりも開発とテストがはるかに簡単であり、正しいコード分割とカプセル化はコードの混乱を避けるのに役立ちました。

パッケージ管理

Jujuは自動販売機を使用しません。 私の意見では、それは価値があるだろうが、プロジェクトは通常のツールが登場する前に開始され、自動販売の使用への移行はそれに費やす時間の価値がなかったようだ。 現時点では、ロジャー・ペッペのゴッドセップ （ちなみにこれはgodepはありませgodep ）を使用して改訂版をキャプチャしています。 確かに、彼には問題があります-彼はあなたのGOPATHの他のパッケージを混乱させ、指定されたコミットに従ってそれらを設定します。そのため、自動販売機を使用しない別のプロジェクトをビルドすると、マスターからではなく依存関係がビルドされる可能性があります-光。 ただし、リビジョンをコミットすると、反復可能なビルドが得られ（外部リポジトリで実際に誰もひどいことをしない限り）、問題はありませんでした。 ただし 、コミットのハッシュを含むファイルは常に競合ポイントでした。合併。 多くの場合、多くの開発者によっても変更されるため、遅かれ早かれ、2人がこのファイルの同じ行または隣接する行を変更したときに状況が発生するはずです（注： godepsユーティリティは、ソースを更新するファイルを使用しますパッケージとインストールされるコミットのハッシュが示されます）。 これは本当の問題になったので、これらの競合を自動的に解決するユーティリティの作成を開始しました（ godepsはコミットされたコミットの日付を保存するため、ほとんどの場合、最近のコミットを選択するだけです）。 glideを使用する場合、および単一ファイルに依存関係ハッシュを保存する同様のツールを使用する場合、問題は残ります。 これを修正する方法がわかりません。

全体として、私はパッケージ管理が大きな問題であると感じたことは一度もありませんでした。 私たちの日常の仕事では取るに足らないことです。したがって、パッケージマネージャーが不足しているために人々がGoを真剣に受け止めないという話を読むのはいつも奇妙でした。 ほとんどのサードパーティのリポジトリは安定したAPIをサポートしており、コードを特定のコミットにバインドすることもできました...それは問題ではありませんでした。

プロジェクト組織

Jujuは80％のモノリシックリポジトリ（monorepo）で<github.com/juju/juju>にあり、残りの20％のコードは別のリポジトリ（<github.com/juju>）にあります。 モノリポジトリを割り当てることには長所と短所があります...コード全体で大規模な変更を加えるのは簡単ですが、それはおそらくfoo/bar/baz/bat/alt/special安定したAPIを必要としないことを意味します... そして、これは、このモノリポジトリからパッケージをインポートする人にとっては全くの狂気に変わり、パッケージは今後もほぼ同じ形で存在し続けると考えています。 もちろん、この場合は自動販売機で節約できますが、アップグレードが必要な場合は幸運を祈ります。

また、モノリポジトリは、API、責任の分担についての警戒心が低く、コードが相互依存していることを意味していました。 私たちが不注意だったと言うわけではありませんが、APIの責任、品質、および安定性の区分が同じであるため、メインのJujuリポジトリ以外のものははるかに標準化されているように思われます。 もちろん、外部リポジトリのドキュメントも優れていて、これ自体が大きな意味を持ちます。

外部リポジトリの問題は、パッケージの管理とリポジトリ間の変更の同期化でした。 外部リポジトリを更新した場合、外部変更の使用を開始するには、その後メインリポジトリを変更する必要がありました。 もちろん、2つのgithubリポジトリに対してこれをアトミックに行うことは不可能です。 また、コード検査やテストの失敗などのためにメインの変更を行うことができない場合があり、外部リポジトリに互換性のない変更があり、この外部リポジトリに変更を加えることを決定した人はつまずきます。

もう1つ言います。ユーティリティリポジトリは悪です。 多くの場合、以前のバージョンのJujuのutilsリポジトリのサブパッケージに修正をバックポートしましたが、他の多くの無関係な変更がこの修正に追いつくことに再び気付きました。 それは、1つのリポジトリにあまりにも多くあるからです。 あらゆる種類のひどいブランチ、「クランチ」、「コピーアンドペースト」をしなければならなかったことが判明しましたが、一般的にこれはすべて悪いことであり、そうしません。 utilsパッケージとリポジトリにnoとだけ言ってutils 。

普遍的なシンプルさ

Goのシンプルさは、間違いなくJujuプロジェクトの成功の大きな要因でした。 以前に採用した開発者の約3分の1だけがGoで働いていました。 残りは新参者でした。 1週間後、ほとんどの新規参入者はすでに非常に経験を積んでいます。 製品のサイズと複雑さは、開発者にとって言語自体よりもはるかに大きな問題でした。 より経験豊富なGo開発者が、GoでXを作成する最善の方法についてチームから質問を受けたことがありましたが、それは非常にまれでした。 これを以前の作品のC＃と比較してください。以前の作品では、言語のさまざまな部分を常に説明していました。

Goプログラミングの経験がある開発者だけでなく、一般的に優秀な開発者を雇うことができたため、シンプルさはプロジェクトにとって大きな恩恵でした。 つまり、この言語がコードの新しい部分を理解する上で障害になることはありませんでした。 Jujuは非常に巨大だったため、プロジェクト全体の詳細を誰も知ることができませんでした。 しかし、同時に、ほとんどすべての人がコードにアクセスし、エラーを含む100行程度の行と、それがどのように（多かれ少なかれ）実行されるかを知ることができました。 新しいコードを学習する際の問題のほとんどは、どの言語でもそうであるように、アーキテクチャとは何か、情報はどのように伝達されるか、期待は何か（元：期待）です。

Goには魔法がほとんどないので、Goでこのプロジェクトを実装するのは、他の言語よりも簡単だったように思えます。 他の言語にある魔法はありません。 一見シンプルで理解しやすいコード行に予期しない機能を与えることができる魔法。 古いGoコードを学習するとき、「Goがどのように機能するのか」と疑問に思う必要はありません。Goコードの一部にすぎないからです。 もちろん、これは、洗脳される複雑なコード、隠された期待、前提条件がないことを意味するものではありません...しかし、少なくともこれは、基本的なアルゴリズムを曖昧にする言語機能の背後に隠されていません。

テスト中

テストキット

Jujuでは、 gocheck Gustavo Nieyemerを使用してテストを実行しました。 gocheckの機能のおかげで、フルスタックテストを実行し、各テストの前にJujuサーバー環境とmongoデータベースを自動的に展開することができ、開発者のオーバーヘッドが削減されます。 テストが作成された後、それらは非常に大きいことが判明しましたが、この「ベースセット」をテストセットの構造に埋め込むだけで、すべての汚れた作業が自動的に行われます。 その結果、各テストで多くのアクションが実行されたため、ユニットテストは非常に生産的なラップトップでほぼ20分間実行されました。 このような大量のテストコードにより、テストコードは脆弱になり、理解とデバッグが困難になりました。 テストが成功または失敗した理由を理解するには、テスト関数のオープン中括弧の前に実行されたすべてのコードを理解する必要がありました。セットにセットを埋め込むのは簡単なので、多くの場合、このオープン中括弧の前にLOTが行われました。

将来的には、代わりに、テストのために標準ライブラリに固執します。 標準ライブラリを使用したテストは、通常のGoコードと同じ方法で記述され、依存関係は明示的でなければなりません。 テストの開始時にコードを実行する場合は、メソッドをそこに配置するだけで済みます...メソッドをそこに配置する必要があります。

瓶の中のtime

timeパッケージは、テストとテストコードの呪いです。 30秒後にタイムアウトするコードがある場合、どのようにテストしますか？ 完了するのに30秒かかるテストがありますか？ そして、何かがうまくいかない場合、残りのテストは30秒間実行されますか？ これはtime.Sleepだけでtime.Sleep 、 time.Afterまたはtime.Tickerます...一般に、これはテスト中の災害です。 また、テスト時（特に-raceスイッチで開始するとき）のコードは、実稼働時よりもはるかに遅く実行される可能性があることは言うまでもありません。

解決策は時間をモックすることです...これはもちろん、些細なことではありません。なぜなら、 timeパッケージは単なるトップレベル関数の束にすぎないからです。 したがって、 timeパッケージを使用する場合はいつでも、代わりにtimeラッパーである特別なインターフェイスを取得し、この偽のtimeをテスト用に渡す必要があります。これは既に制御できます。 これにより、既製のアセンブリを作成し、コードの変更を配布する時間が大幅に増加しました。 長い間、それは常に安定したテストのソースでした。 これらはほとんどの場合に行われるテストですが、ある日CIマシンが思慮深いものであった場合、いくつかのランダムテストは失敗しました。 また、数十万行のテストがある場合、一部のテストが失敗する可能性が高く、ほとんどの場合、前回と同じテストではありません。 フレイキーテストの修復は、「ほくろを殺す」ゲームに似ていました（元：モグラを叩きます。9つの穴からほくろが突き出るスロットマシンで、ハンマーで叩かなければなりません） 。

クロスコンパイル幸福

OSとアーキテクチャのすべての組み合わせの正確な数はわかりませんが、Jujuサーバーは、WindowsとLinux（CentosとUbuntu）だけでなく、amd64だけでなく、ppc64le、arm64、s390xなどのエキセントリックなアーキテクチャも含め、多くのアーキテクチャ向けに間違いなく構築されています。

Jujuは、gcコンパイラがサポートしていないアーキテクチャに最初にgccgoを使用しました。 このため、gjuがとらえどころのないナンセンスを出したJujuでいくつかのミスがありました。 gcが更新され、すべてのアーキテクチャをサポートし始めたとき、追加のコンパイラをプロジェクトから除外してgcでのみ動作することを非常に嬉しく思いました。

gcに切り替えたとき、アーキテクチャ固有のエラーはほとんどなくなりました。 サポートされているJujuアーキテクチャの幅が広く、これらのエキセントリックアーキテクチャがCanonicalに多くの影響力を持つ大企業で使用されているという事実を考えると、これは素晴らしいことです。

OS固有のエラー

最初に、Windowsサポートの組み込みを開始すると、OS関連のエラーがいくつか発生しました（すべてUbuntuで開発されたため、CIが機能するまでWindows固有のエラーは発生しませんでした）。 基本的には、2つの一般的なファイルシステムエラーに要約されます。

1つ目は、デフォルトでテストのパスに直接スラッシュを使用することです。 たとえば、構成ファイルがサブフォルダー "juju"にあり、 "config.yml"と呼ばれることがわかっている場合、テストでは、ファイルへのパスがfolder + "/juju/config.yml"であり、Windowsであることが確認できますfolder + "\juju\config.yml"でなければなりません。

テストでも新しいディレクトリを作成するときは、特に文字列とスラッシュを組み合わせてではなく、 path.Join代わりにfilepath.Joinを使用します。 filepath.Joinは、OSの正しいスラッシュを使用します。 パスを比較するには、常にpath.ToSlashを使用して、既に比較可能な標準ビューにパスをキャストします。

もう1つのよくある間違いは、Linux開発者が開いているファイルを削除または移動できるようにすることです。 また、Windowsはファイルが開かれるとファイルをロックするため、Windowsでは機能しません。 これは、 defer file.Delete()呼び出しの形で頻繁に発生し、FIFOによれば、 defer file.Delete()の遅延呼び出しの前に呼び出されたため、まだ開いているファイルを削除しようとしました。 恥ずかしい。 解決策の1つは、移動または削除を実行する前に、常にfile.Close()呼び出すだけです。 Closeを数回呼び出すことができるので、関数の最後で動作defer file.Close()を既にdefer file.Close()ている場合でも、削除する前に呼び出すのは非常に安全です。

これらのエラーはどれも難しくなく、標準ライブラリでのこのような強力なクロスプラットフォームサポートにより、クロスプラットフォームコードの開発が簡単になると思います。

エラー処理

Goのエラー処理は、間違いなくJujuの安定性に有益な効果をもたらしました。 特定の関数が失敗する可能性のある場所を知ることができるという事実は、クラッシュを予期するコードを書くのがはるかに簡単であり、それが優雅にそれを行います。

時間の経過とともに、Jujuは単に標準errorsパッケージを使用しました。 ただし、エラーの原因となったコードのパスを追跡するために、より多くのコンテキストが必要であると感じ、エラーに関するより詳細な情報を保存し、それにコンテキストを追加することも良いと考えました（たとえば、 fmt.Errorfを使用するfmt.Errorf情報は失われます）元のエラーについて、たとえば、 os.NotFoundエラーの場合）。

数年前、オリジナルのエラー情報を失うことなく、より多くのコンテキストをキャプチャする独自のエラーパッケージの開発を開始しました。 さまざまな方向に無益に投げた後、すべてのアイデアをhttps://github.com/juju/errorsに結合しました。 もちろん、これは理想的なライブラリではなく、長年にわたって新機能のために拡張されてきましたが、良いスタートでした。

主な問題は、スタックトレースなどを出力する必要があるときに、現在のファイル名と行番号を見つけるためにエラーを返すときに常にerrors.Trace(err)を呼び出す必要があることです。 今日は、Dave Cheneyの<github.com/pkg/errors>パッケージを選択します。これは、エラーが生成された時点でスタックトレースを取得し、完全なトレースを回避します。 正直なところ、エラーのあるスタックトレースは本当に便利だとは思いません。 実際には、予期しないエラーにはfmt.Errorf("while doing foo: %v", err)から十分なコンテキストがあるため、多くの場合、スタックトレースが必要です。 元のエラーのプロパティを調査する機能は便利な場合もありますが、ほとんどの場合、思っているほど頻繁ではありません。 foobar.init()がfoobar.init()ようなものを返す場合、これは本当にあなたのコードに役立ちますか？ ほとんどの場合、いいえ。

安定性

このような巨大なプロジェクトの場合、Jujuは非常に安定しています（これは、エラーが多くないという意味ではありません...クラッシュすることはほとんどないか、非常にバグが多いことを意味します）。 言語に大きく依存すると思います。 Canonicalの前に働いていた会社には、100万行のC＃コードがあり、「null reference」例外やその他の未処理の例外で非常に頻繁にクラッシュしていました。 正直なところ、Jujuプロダクションコードのヌルポインターが原因でパニックに遭遇したことは一度もありません。新しいコードで何か愚かなことを行ったときは、開発プロセスでたまにしかありませんでした。

Goマルチリターンパターンがエラーを示すために使用されると確信しています。 テンプレートfoo, err :=を使用し、常にエラーをチェックします。これにより、実際にはヌルポインターが発生する可能性が非常に低くなります。 返された変数にアクセスする前にエラーをチェックすることはGoの基本原則であるため、この規則の例外を文書化することが重要です。 追加のエラー戻り値は、コンパイラが未使用の変数をチェックするため、無視したり忘れたりすることはできません。 これにより、他の同様の言語と比較して、GoでのNULLポインターの問題がかなり軽減されます。

ジェネリック

このセクションは短いので...まあ、あなたは知っています。 ジュジュでの作業中に1、2回だけ、私は個人的にジェネリックが不足していると感じました。 また、コードのレビュー中に、他の人のソースのジェネリックを希望することを覚えていません。 C＃でジェネリック医薬品と出会った認知（知的）複雑さを「強打」する必要がなかったことを嬉しく思いました。 Goインターフェイスは99％のケースで十分であり、 interface{}意味するものではありません。 Jujuでinterface{}を使用interface{}ことはほとんどありませんでしたが、ほとんどの場合、何らかのシリアル化が行われていたためです。

続く

これはすでにかなり長い投稿なので、やめる時だと思います。 API、バージョニング、データベース、リファクタリング、ロギング、イディオム、コード検査などについて、もっと具体的なことを話すことができます。