Golangへのラブレター

私は 7 年近くにわたって Go を書いてきました。しかし、私がテクノロジー業界でのキャリアをスタートしたのはそこではありませんでした。

私の最初の仕事は、バックエンドとデータベースというコアコンピテンシーを備えた場所でした。 Bootstrap は、当時、数年間にわたって事実上フロントに置かれていたライブラリであり、彼らにとってはまったく新しいものでした。

UI/UXはほとんど後付けでしたが、クライアントが大手会計会社だったので問題ありませんでした。顧客は青色とたくさんの四角い箱に満足していました。

また、私にはコンピューター サイエンスの伝統的な背景はなく、ずっと独学で勉強してきました。おそらくそれが、そもそもフロントエンドにたどり着いた理由でもあると思います。そこは私を置くのに最も安全な場所でした。

そこで私は他のことと同じように、Google に「フロントエンドの学習方法」と入力して学習を開始しました。

当時、React は人気の点で Angular から脱却したばかりで、まだフック前の古き良き時代にありました。私は最終的に React に習熟し、今後 2 年間は主に React (および JS/TS) を書くことになりました。

しかし、何かが起こり続けました。新しいツール、ライブラリ、フレームワークが毎日出荷されていたため、すべてが一貫して古いように見えました。 使わなければならなかった そして追いついていきましょう。

過去 10 年間で React が大きく成長するにつれて、人類が知っているすべての要件をカバーする必要があると彼らは考えているようです。クラスや Redux から関数コンポーネントやフックへの移行は、最初は素晴らしいと感じました。これらを効率的に使用し、やり取りされる大規模な状態オブジェクトまたは驚くべき数の状態オブジェクトを管理するには、博士号が必要です。 useState 各コンポーネントで。

ありがたいことに、私はもう React はあまり書かず、そのルーツ、つまり昔ながらの HTML に戻ってきました。そして、ありがとう モンタナ州出身の男 SPA アプリで得られるインタラクティブ性の 90% は今でも得られます。

それでは、私がなぜ Go を使用すべきだと思うのか、そして私が Go に夢中になった理由を説明しましょう。

概要を知りたいだけの場合、多くの場合、何かを行う方法は 1 つしかなく、それによって製品の構築に集中できます。

選択肢が限られている

Go を書いていると、問題の解決策が、さまざまなチーム、人、プロジェクトにわたって共通の結論に収束する傾向があることがよくわかります。

少し前、私は、使用していた検証ライブラリでは、私が望んでいたことが簡単に実現できないことに不満を感じていました。そこで私は他の優秀なエンジニアがやっているのと同じことをして、独自のソリューションを書くのに数日を無駄にしました。

結局のところ、これは自分の時間だったので、くそったれです。

中盤くらいから、他の人がやったことを調べ始めましたが、複数の異なるプロジェクトにわたって、問題の解決策は非常に似た方法で実装されていました。

もちろん、これは、最初のライブラリがコードをコピーした後に追加されるすべてのライブラリが原因である可能性があります。しかし、それは私の一般的な経験ではありません。 Golang の厳密な機能セットにより、同様の問題に対する解決策は収束しているようです。

私がよく目にする批判の 1 つは、Go では開発者がコードで自分自身を「表現」することを許可していないというものです。正直言って、それはでたらめです。あなたはピカソではありません。居心地の良いオフィスに座って、タブから直接コンブチャを飲むために多額のお金をもらっています。

必要に応じて、システム設計やエレガントなソリューションで自分自身を表現してください。ただし、コードはそのままにしておいてください。

コミット履歴を調べずに、Go コードベースに対する個人の貢献を見つけることは非常に困難です。奇抜なことや自分のスタイルを持つ余地はあまりありません。繰り返しますが、かなり退屈に聞こえますが、デジタル製品の構築と出荷を重視する場合には、非常にうまく機能します。

解決策はあなたが焦点を当てることです。

シンプルな構文と簡単なオンボーディング

構文は非常に最小限で、学ぶべきキーワードは 25 個のみで、そのうちの 3 分の 2 は必要になるでしょう。

拾うのが信じられないほど早いです。私がコンサルタントとして働いてきたチームに Go を紹介すると、たいていの人は 1 ～ 2 週間後には良い Go を書きます。学校を卒業したばかりか、別の方法で働いているか、別の言語で豊富な経験があるかどうかは、あまり関係ありません。

一般に人々は Go をすぐに習得する傾向がありますが、これはその読みやすさから来ていると思います。

私にとって、それは、8 ストーリー ポイントを費やして書いた Rust コードを見るほど美しくはありません。スプリントの終わりにコンパイルが完了すると、関係者の期待と一致していなかったことがわかります。

いいえ、実用的で退屈なので、自分の仕事のより興味深い部分であるべき問題に集中できるようになります。どのリンター スタイル (またはどのリンター) を使用するかについて議論する必要はありません。それはあなたにとって決定され、チームの全員にとって同じです。

必要なものがすべて 1 か所に

標準ライブラリは本当に素晴らしいです。プロジェクトが確実に維持され、更新のために大量の書き直しを行う必要がないため、プロジェクトにある程度の落ち着きをもたらします。

Web に関連して構築したいことのほとんどは、標準ライブラリだけを使用して実行できます。特定の部分を改善するライブラリは他にもありますが、厳密に必要というわけではありません。

しかし、おそらく同じくらい重要なことですが、Golang ツールチェーンにはリンターとリンティング ルールを適用する方法の標準が付属しています。これは通常、ほとんどの開発者が意見を持っているものですが、実際には価値を追加するものではなく、異なるスタイルが使用されている場合は価値を奪うだけです。 1 つだけ使用して、そのまま使い続けてください。

Go は Web 開発に向けて機が熟しています

近年、Go エコシステムのプロジェクトにより、Go のみを使用してフルスタック アプリを構築することがさらに簡単になりました。

私の意見では、Go でのフルスタック開発を推進するのに役立つエコシステムから出てきた主なものは、Templ です。

その開発者たちは、私たちが目にしている「問題」の 1 つは、多くのフロントエンド/フルスタック開発者が SPA のやり方しか見ていないことだと (言い換えて) 話しています。ハイパーメディア、アンカー タグ、およびフォームは、本来の形式では奇妙な概念です。そこで、彼らはコンポーネントで考えることができ、しかも完全に有効な HTML であるものを作成したいと考えました。

Django、Rails、または Laravel の開発を行ったことがある場合は、このフロントエンドの方法はおそらくよくご存じでしょう。

基本テンプレートを使用してアプリケーションをラップし、特定のページのいくつかのビューとボタンやテーブルなどの抽象要素をコンポーネントに組み込んで再利用できるようにすることで、API は JSON 駆動ではなくハイパーメディア駆動になります。

JSON ベースの API の場合と同様にコントラクトを作成しますが、コントラクトのコンシューマであるクライアントは API とより緊密に結合されます。

皮肉なことに、この緊密な結合により、重大な変更が発生する可能性が低くなり、メンテナンスが軽減され、システム全体の推論が容易になります。この方法で開発する場合、フロントエンドまたはバックエンドだけを担当する開発者は存在しません。あなたもその両方であるはずです。

もちろん、優先することもできますが、この 2 つは非常に近くにあるため、変更とその影響を見つけやすくなります。

単純なデータベース層

私が初めて Go を使い始めたとき、データベース層は最も繰り返しの多い部分の 1 つでした。クエリ ステートメントを設定したり、行を構造体にスキャンしたりするための「=+」がたくさんあります。SQL を書いていましたが、実際にはそうではありませんでした。

Sqlc はフォーラムで頻繁に言及されますが、それには十分な理由があり、SQL の領域に留まり、私が抱えているクエリの大部分を解決できます。

タイプセーフなコードを生成することで多くの定型文を削除し、結果をスキャンしてデータベース構造と一致するものを取り込み、フィールドが正しいことを検証します。

動的クエリを実行するときは他のものに手を伸ばす必要がありますが、squirrel のようなものをミックスに追加するのは非常に簡単です。また、SQL から生成されたメソッドを依存関係としてデータベース構造体に追加するだけで非常に簡単にできるため、両方を持つことは簡単です。

導入は楽しいです

単一バイナリ展開の楽しさを一度味わってしまうと、もう戻るのは困難です。

非常に簡単に行うことができます。VPS をレンタルし、Systemd にサービスを追加するだけですぐに実行できます。

しかし、Go を書いたことがある人なら経験したことがあるかもしれませんが、Go は Docker と非常にうまく連携します。単一のバイナリを構築して出力することを考えると、非常にスリムな Docker イメージを取得できます。 10mbsスリムみたいな。 Python でそれをやり始めただけで、すぐに 1GB に近づいてしまいます。でもストレージは安いと思います。

私は移行の実行などのために、アプリといくつかのツールを含む Docker イメージを構築することが多いのですが、最終的に Docker イメージが 100 MB 程度になることがよくあります。

同時実行性

同時実行性について話さずに Go の評価を投稿するのはかなり難しいです。とても良いのですが、正直あまり使いません。

私は通常、データ処理を行う必要があるときは常にこれを利用しますが、ほとんどの仕事ではそれほど一般的ではありません。これは依存するパッケージに組み込まれており、比較的簡単なアプローチであるため、より親しみやすくなっています。

必要な場合はそこにあります。

パフォーマンスと効率性

他の人に Golang を紹介しようとするときに、これをミックスに投入すると常に便利です。

それが Go を選択する主な理由ではありませんが、API がほぼ箱から出してすぐにパフォーマンスを発揮し、RAM を大量に消費しないことを知るのは非常にうれしいことです。実行内容によっては、クラウド リソースの使用量が減るため、経済的なメリットが得られる可能性があります。

私は現在、メモリのオーバーヘッドが無視できる小さな VM 上でかなりの数のアプリをホストしています。

---