📝

ほぼ週間Go言語 2025/10/27

に公開

今週もプログラミング雑記からGo言語に関する話題と、その他特に気になった話題をより抜きでお送りします。

Go言語

https://medium.com/@kp9810113/10-go-hacks-that-made-my-code-the-fastest-on-the-team-914c3ea28e52

Go言語によるサービスを高速化するために筆者が実践した10のテクニックを紹介。推測ではなくpprofによるプロファイリングを徹底し、bytes.Bufferやsync.Pool活用、スライスの事前容量確保、無制限なゴルーチンの抑止、リフレクション回避、高頻度ループ処理のインライン化、GOMAXPROCSの実測調整、監視メトリクス追加など現場で有効だった具体策を解説。これらの手法により、サービスのレイテンシやメモリ効率が劇的に改善し、チーム内トップの速度を実現した体験談です。


https://levelup.gitconnected.com/why-senior-go-developers-never-trust-timezones-and-what-they-do-instead-18896e3717bf

Go開発でタイムゾーンを信頼せず、時刻データは常にUTCで管理・保存し、表示時のみローカル変換することが推奨されています。サマータイムや各地の複雑なタイムゾーンの影響による不具合を防ぐためであり、時間の間隔処理にはtime.Durationを使用。さらにテスト時は現在時刻やタイムゾーンを抽象化し、安定したテストを実現するのがベストプラクティスです。


https://medium.com/@theopinionatedev/the-hidden-performance-tax-of-go-interfaces-no-one-talks-about-this-3d4a693099d5

Goのインターフェースは抽象化に便利だが、間接参照やヒープ割り当てが発生しやすく、性能が低下する「隠れたコスト」がある。高負荷な場合は具体型の使用やプロファイリングによる最適化が推奨される。


https://levelup.gitconnected.com/how-to-implement-gossip-protocol-for-distributed-systems-using-go-a-practical-guide-6808c43b1c6e

この記事はGo言語による分散システム向けゴシッププロトコルの実装ガイドです。ゴシッププロトコルは、各ノードがランダムな仲間と情報を交換し、クラスタ全体へ効率的に健康状態や更新情報を伝播します。主要パラメータ(ファンアウト、周期、バッファサイズ)や伝播戦略、実装上の工夫(API化、仲間選択アルゴリズム等)について解説し、Goでのサンプルコードを通じて高可用・高拡張性システムへの応用方法を紹介しています。


https://medium.com/@ankur_anand/killing-o-n-how-timing-wheels-expire-10-million-keys-effortlessly-in-golang-9a6b8709fd91

このMedium記事は、Golangで数百万~千万件規模のTTL付きエントリを効率的に期限切れ処理する方法を紹介しています。従来の全件走査(O(n))はスケールせず、レイテンシやCPU負荷が増大します。それに対し「タイミングホイール」方式は、エントリを期限ごとにグルーピングし、該当バケットだけを処理することでO(1)に近い効率を実現。実際に1,000万件でも高い性能を維持できます。記事では手法の詳細とベンチマーク結果、実装例が紹介されています。


https://medium.com/@harishpillai1994/golang-concurrency-cheat-sheet-for-interviews-e50de34b802c

Goの並行処理の主要な仕組み(goroutine、チャネル、mutex、WaitGroup、contextなど)の使い方や、ワーカープールやパイプラインなどのパターンをまとめたチートシートです。実務・面接で役立つように、スレッドセーフなコードやレースコンディション対策、拡張性のある設計まで端的に解説しています。


https://engineering.mercari.com/blog/entry/20251016-e2e-tests/

メルカリのグローバルアプリ開発では、「すべての開発者がE2Eテストを書ける」ことを目指し、Goの標準テスト(go test)で書ける独自フレームワークを実現しました。従来のE2Eテストの属人化や複雑な環境構築などの課題を解消し、開発者が日常的に使う技術で、型安全性やIDE補完、デバッグ容易性などを活かせる設計です。サーバ・DBをプール管理することで並列実行や自動クリーンアップも実現しています。Kubernetes上でも効率的に実行でき、コードカバレッジ計測も標準対応。AIの活用で非Goエンジニアもテスト作成が可能となっています。


https://blog.lufia.org/entry/2025/10/21/175617

Goのエラーハンドリングを簡略化するために「try」というライブラリを作成し、使用方法や内部実装について解説しています。ライブラリはC言語のsetjmp/longjmpと同様にスタック操作を応用し、実装にはGoのABI仕様を利用しています。ただし、Go公式が保証していない挙動に依存しているため、安定運用には不向きです。この記事では実装上で得られた知見やスタックの挙動についても詳しく述べられています。最後に、Go関連イベントの告知もあります。


ライブラリ・ツール

https://wails.io/

  • WailsはGo言語で美しいクロスプラットフォームデスクトップアプリを開発できるフレームワークです。
  • ネイティブUI要素(メニューやダイアログなど)を活用したアプリ構築が可能です。
  • 普段使い慣れたWeb技術(HTML/CSS/JavaScript)を利用してデスクトップアプリを開発できます。
  • Wails CLIを使うことで、プロジェクトの生成・ビルド・パッケージ化が素早く行えます。
  • ドキュメントや導入ガイドも用意されており、GitHub、Twitter、Discordなどコミュニティも活発に活動しています。

つまり、「Go×Web技術」を活かして素早く高機能なデスクトップアプリを作りたい開発者向けのプロジェクトです。


https://github.com/matthalp/go-meridian

go-meridianはGo言語向けの、型安全なタイムゾーン管理ライブラリです。time.Timeのタイムゾーン情報が型内で保持されず、誤った取り扱いが起こる問題を解決します。Meridianではタイムゾーンを型に直接エンコードし、異なるタイムゾーン同士の混同をコンパイル時に防止します。14種類の主要タイムゾーンに対応し、カスタム追加も可能。APIは直観的で、UTC型や東部標準型などゾーンごとに異なる型・関数を提供し、タイムゾーン変換も型安全に行えます。CI/CD自動テストやリント、カバレッジ計測も整備済みで、拡張性にも優れています。


その他

https://tech.findy.co.jp/entry/2025/10/20/070000

この記事は、Kent Beck氏がFindy主催の「開発生産性Conference 2025」で行った基調講演「開発生産性測定のトレードオフ『グッドハートの法則』はもっと悲観的に捉えるべきだった」の日本語訳全文(前編)です。内容は以下のとおりです。

  • Beck氏は「エクストリームプログラミング」の提唱者で、25年ぶりに来日し講演。
  • ソフトウェア開発生産性向上のための指標活用について、その危険性と本質的な問題を指摘。
  • 「グッドハートの法則」(指標が目標になると、もはや良い指標でなくなる)をテーマに、指標(例:PR数、コード行数など)による圧力が本来の成果を歪めてしまう危険を述べる。
  • 一時的には機能しても、指標を管理手段(コントロールレバー)として使うことで、その有効性も仕組み自体も損なわれる。
  • 単なる「指標のバランス」や複数指標の導入でも問題は解決せず、むしろ混乱を招く可能性。
  • Beck氏自身も開発の定量的測定は肯定するが、それは制御や管理のためではなく、理解・学習・洞察のためであるべきと強調。
  • 本質的な改善のためには、数字で単純に評価する誘惑から脱し、創造性や人間の洞察を重んじる必要がある。
  • 後編では、AI時代の測定・リーダーのアプローチなど更なるテーマが展開される予定。

まとめ:
ソフトウェア開発における「生産性指標」は、制御や管理ツールとして使うと本来の目的を見失い、仕組み自体を壊すリスクがあるため、より深い理解と慎重な運用が必要である、という警鐘が鳴らされています。

https://tech.findy.co.jp/entry/2025/10/21/070000

Kent Beck氏による基調講演の日本語訳全文記事の後編です。この講演では「グッドハートの法則」と開発生産性指標に関する考察がまとめられています。

主なポイントは以下の通りです:

  • 価値の道すじとして、ソフトウェア開発の成果が「労力(Effort)→アウトプット→成果(Outcome)→影響(Impact)」の段階で生まれ、労力に近い指標ほど測定しやすいが、システムを歪めるリスクが高いことを解説
  • 指標による制御が組織や行動を歪めてしまう構造的な問題があり、単なる測定と制御は区別すべき
  • AI時代の開発では、AIの活用により労力とアウトプットは劇的に増加・効率化するが、指標への圧力が加われば本質的な問題は変わらない
  • 若手育成では、アウトプットより「どれだけ学んだか、成長できたか」を重視し、長期的な価値創造につなげるべき
  • 指標を管理するリーダー・マネジャーの役割としては、圧力による制御をやめ、目的の浸透や意識向上を促すことが大切。測定は理解や改善意識のために使い、制御の手段にしない
  • 最後のまとめとして、グッドハートの法則による歪みを避けるには、測定自体は否定せず「圧力をかけない」ことが重要、創造性と自律性を促す組織文化が肝要とされる

講演全体を通じて、開発現場での生産性指標の扱い方・人材育成・リーダーシップに対する示唆が多数語られています。

株式会社BALEEN STUDIO

Discussion