Goの仮定

ゲームGoには非常にシンプルなルールがありますが、マスターになるのは簡単ではありません。パターン、テリトリー、その他の戦略的コンセプトを考える方法を学ぶ必要があります。 Go言語は、このゲームの名前と同じように誤って命名されていません。 サンフランシスコでの最近の集会でのスピーチの中で、ロブ・パイクは囲Proのことわざに言及しました。これは、単純で詩的なフレーズで複雑な戦略を説明しています。 これらの仮定は、ゲームGoに精通している人にとってより深い意味を持ち、精通していない人にとっては空のフレーズに見えるかもしれません。 また、この非技術的なレポートでは、Go言語の「仮定」を同様の方法で発明することを提案しました。



それらのいくつかを次に示します。

• メモリを共有して通信するのではなく、通信してメモリを共有します。
• 並行性は並列処理ではありません。
• チャンネルのオーケストレーション。 ミューテックスはシリアル化します。
• インターフェースが大きいほど、抽象度は低くなります。
• インターフェイス{}は何も言いません。
• Gofmtのスタイルは誰のお気に入りでもありませんが、gofmtは誰のお気に入りでもあります。
• 少しのコピーは、少しの依存関係よりも優れています。
• CgoはGoではありません。
• クリアは賢いよりも優れています。
• 反射は決して明確ではありません。
• エラーは値です。

これはPythonのZenに少し似ています。 あなたはそれらに同意しないかもしれませんが、これらの仮定は囲inのイディオムとアプローチを反映しています。 レポートに基づいてそれぞれを詳しく見ていきましょう（投稿の最後のビデオ）。





「メモリの共有について話さないでください。 通信してメモリを共有します。」 （メモリを共有して通信するのではなく、通信してメモリを共有します）

この仮定は誰もが知っています; Goの競争的なプログラミングパターンに関するレポートと投稿で繰り返し聞かれています。 この仮定は、チャネルおよびゴルーチンの動作メカニズムの本質を理解することを目的としています。関数は同じメモリを共有せず、安全に通信し、チャネルを介してデータを送信します。



「競争は並列性ではない」 （並行性は並列性ではない）

並行性という言葉がロシア語にうまく翻訳できるかどうかはわかりませんが、要点は、並列処理は同じコードの単なる並列実行であり、マルチコアを最大限に活用するソフトウェア-競争力のあるソフトウェアは競争力、つまりロジックを構築する方法ですプログラム。 初心者は、これらの2つの概念を混同することがよくあります。 同じ名前のPikeの優れたパフォーマンスがあります。まだ誰がいないかを確認してください。



チャネル-オーケストレーション、ミューテックス-シリアル化 （チャネルオーケストレーション、ミューテックスシリアル化）

いつミューテックスを使用するか、いつチャネルを使用するかについての前回の記事（ 「Goでのミューテックスでのダンス」 ）のトピックの適切な仮定。 ミューテックスは、何かへのアクセスの実行を単純にシリアル化しますが、ゴルチンとチャネルは、プログラムの部分間の複雑なアーキテクチャとデータ交換構造を持つプログラムを作成するツールを提供します。



インターフェースが大きいほど、抽象化が弱い

Goの新参者、特にJavaを使用する人は、多くの場合、インターフェイスは大きく、多くのメソッドを含めるべきだと考えています。 また、インターフェイスの暗黙的な満足度によって混乱することもよくあります。 しかし、インターフェースで最も重要なことはこれではなく、それらを取り巻く文化であり、この仮定に反映されています。 インターフェースが小さいほど便利です。 パイクは、彼が書いた3つの最も有用なインターフェイス（io.Reader、io.Writer、およびインターフェイス{}）が、3つについて平均0.666メソッドを持っていると冗談を言っています。



ゼロ値を有用にする

ポイントは、コンストラクターを使用せずに、型のnull値を有用にする方が良いということです。 もちろん、コンストラクター関数が必要な場合もありますが、型の変数を「そのまま」動作させることができる場合、これは常に有益です。 例は、標準ライブラリのbytes.Bufferまたはsync.Mytex型です 。 bytes.NewBufferやbytes.NewBufferString（）などのコンストラクターがありますが、空の値はすぐに使用できるバッファーです。



空のインターフェースは何も言いません（インターフェース{}は何も言いません）

この仮定は、インターフェース-「振る舞い型」が何かを意味するに違いないことを示唆しています。 インターフェイスを作成する場合、それは何かを意味し、特定の目的に役立ちます。 空のインターフェイス（インターフェイス{}）は何も意味せず、何も意味しません。 使用する必要がある場合もありますが、多くの場合例外です。理由はありませんが、インターフェイス{}を使用しないでください。 初心者は多くの場合、空のインターフェイスを再利用しますが、スタックオーバーフローに関する多くの質問がそれらについてです。



Gofmtのスタイルは誰のお気に入りでもありませんが、gofmtはみんなのお気に入りです）

習慣に苦しんでいる多くの初心者は、Goのコードが好きなようにフォーマットされていないことに不満を漏らしています。 Gofmtは単一のスタイルであり、個人の好みではありません。 go fmtユーティリティの作成者であるGriesmeyer自身でさえ、別のフォーマットスタイルを好みます。 しかし、フォーマットが承認されてからgofmtはどこでも常に使用されています-当然のことと考えてください。 経験豊富なプログラマーはgo fmtを救いだと考えています。他の人のコードでの作業が大幅に簡素化されるためです-他の言語でさまざまなスタイルのフォーマットを使用するのは過去のものです。

新しい言語がこのアプローチを採用することは注目に値します（例： rustfmt ）-これはデイブチェイニーが彼の講演 「Go Legacy」で語ったことです-新しい言語は、単一のフォーマットスタイルとこれを提供するユーティリティがなければ完全とは見なされなくなります。



少しのコピーは、少しの依存関係よりも優れています

これはすでにプログラミング全般に当てはまりますが、Goでは標準ライブラリと文化全体の両方で見ることができます。 これは 、 「重複は悪い抽象化よりも安い」というよく知られたインストールを部分的に反映しています。 Pikeは、Googleの初期の頃、ほとんどがコードの再利用に関心があると言われたと語っています。 インポートすることで1つの繰り返し行を書くことを避けることができるなら、そうする必要があります。 Pikeによると、Googleはこのアプローチのためにコードの問題にまだ取り組んでいます。 多くの場合、機能は（最初のリファクタリング前）同様であるか、依存関係の機能の一部のみが必要であり、150kbの依存関係をインポートするよりも5行を記述する方が効率的です。 例として、 strconvパッケージのIsPrint関数-unicode.IsPrint（）の機能を複製しますが、テストでは機能が同じように機能することを確認します。 要約すると、正当な場所にコードをコピーすることを恐れないでください。



syscall呼び出しを含むコードにはビルドタグを含める必要があります （syscallは常にビルドタグで保護する必要があります）

最近翻訳された記事「簡単に移植できるGoコードの書き方」のトピック。 Goのsyscallパッケージについて不満を言う人もいます-変更する必要がありますが、移植はしません。 ただし、syscallは定義によりプラットフォーム依存の呼び出しであるため、高品質のクロスプラットフォームコードを作成する場合は、syscallを使用するファイルにビルドタグを常に追加してください。



Cgoは常にビルドタグで保護する必要があります）

まったく同じ理由で-cgoを使用するときは常にビルドタグを追加します。 Cを呼び出すと、実際に何が起こっているのか誰にもわかりませんが、ほとんど確実に移植性がありません。



Cgoは行かない （Cgoは行かない）

GoでCコードを使用するのがいかに簡単かを多くの人が喜んでいます。 もちろん、これが必要な場合もありますが、パイクはCgoを一度も使用したことがないことを認めています。Goの世界では、メモリ、安定性、セキュリティ、ガベージコレクションについて明確な理解があります。 Googleの90％のケースでは、誰かが「私のプログラムがクラッシュしたので、それを理解するのを手伝ってください」と言うと、Cgoであることがわかります。



安全でないパッケージには保証はありません（安全でないパッケージには保証がありません）

これは、 安全でないパッケージを使用して記述されたコードも移植性がないという事実に焦点を当てており、Go 1内の後方互換性の保証をカバーしていません（これはパッケージドキュメントの最初の行に記述されています）。 これまでのところ、何も変更されていませんが、何らかの理由で安全でないものを使用する場合は、将来のバージョンでは変更に適応する必要があることに注意してください。



クリアは賢いよりも優れています

Goでは、コードの明快さと読みやすさが最初に来るという仮定。 また、難解なコードではなく、明確でわかりやすいコードを書くよう努力する必要があります。 遅かれ早かれ、コードは他のプログラマーによって読み取られ、改善され、リファクタリングされ、それが明確であるほど、結果はより簡単で迅速になります。 Goはどうしてもこれを支援し、貢献します。言語の設計全体がこの目標で満たされています。



反射は決して明確ではありません

Goでのリフレクション （プログラムが独自の構造を変更する機能）はリフレクトパッケージによって実装され、人々はしばしばそれを場違いで使用しようとします。 リフレクションは非常に強力なものですが、理解するのは非常に難しく、実際、それを必要とする人とタスクはごく少数です。 パイクは、おそらくGoで最もリフレクションコードを書いたと言いますが、それをやるのは今でも嫌いです。 そして彼は、人々がリフレクションを使用しないよう奨励される必要があると信じています。



エラーは値です

すでにハブで繰り返し取り上げられているもう1つの重要な仮定は、特に公式のGoブログの記事です。 初心者はしばしばこれを理解せず、「なぜerr！= Nil everywhereならばこれらを書くべきなのか」と尋ねます。 はい、あなたはプログラミングしていないので、コードをリベットしているのです。 多くの人は、err！= Nilがtry..catchの代わりになると考えています...は、エラーを処理するための特別な言語構造です。 しかし、そうではありません; try ... catch ...でプログラムすることはできません。 Goのエラーでは、プログラムロジックが必要とすることを実行できます。



エラーをチェックするだけでなく 、適切に処理する

エラーは、チェックするだけでなく、エラーの状況が正しく処理されるようにエラーをどう処理するかを考えるために非常に重要です。 おそらく、何らかの情報でエラーを補足する必要がある場合、後で処理するために何か他のものを覚えておくことが可能です。 プログラミングの非常に重要な部分は、エラーの処理方法です。 チェックして転送するだけでなく、このエラーを適切に処理する方法を考えてください。 これはすべての言語に当てはまりますが、Goのエラーは単なる意味であるため、コード内に美しく正確なエラー処理を実装するのが簡単で、簡単に実装できます。



アーキテクチャを考え 、コンポーネントに名前を付け、詳細を文書化します

これは、コードのコンポーネント、メソッド、関数、変数に適切に名前を付けることの重要性についてです。 これらの名前は、パッケージのユーザーコードに含まれます。 また、名前が成功し、理解できる場合、プログラムの設計はより明確で理解しやすくなります。 しかし、もちろん、説明する必要がある詳細が常にあります。そして今、それらをドキュメントに入れる必要があります。



ドキュメントはユーザー向けです

関数のドキュメントでは、この関数が何をするのかではなく、なぜそれが必要なのかを説明する必要があるという事実。 これは非常に重要な区別であり、見過ごされがちです。 ドキュメントを書くときは、パッケージのユーザーの目を通してそれを見てください。



さて、簡潔さ、詩、概念主義の基準を満たす他の仮定を思い付くことができたら、気軽に提案してください。



go-proverbs.github.io



スライド（オリジナルではない、真）： speakerdeck.com/ajstarks/go-proverbs



ビデオ：