今日のバドミントン練習はエアシャトルでリフティングを30分した。連続最大回数は80回だが、ほとんどの試行は20回も続かずに失敗してしまう。難しい。

隔週の雑談⌗

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。

課題管理と adr の関係の考察⌗

数年前から adr の話題や導入した会社の記事などをみかけるようになった。私はこれまで課題管理をうまくやっていれば adr はそれほど重要ではないとあまり重視してこなかった。しかし、世の中的に認知されて流行っているものはなにかしら意義があるのだろうと最近は少し見直してきているところもある。このスライドによると2017年から流行り始めたらしい。

  • 開発に関する情報を一元管理する、または全文検索ことにビジネスチャンスはある
    • 検索のニーズや要件は多様で言語によっても違い、技術もまだまだ発展的でもあるからずっとビジネスの種になる気はする
    • gitlab issues のコメントの全文検索は有料機能なので slack 通知したチャンネルを全文検索している
      • 課題管理システムのプラグインでテキストをシステム間連携することで検索システムを別途構築できる可能性がある
      • 検索できなくてもデータのアーカイブをするという視点でもビジネスニーズに応える？
  • ベクトル検索 を検索がまだ一般的にはなっていない？
  • wiki と adr の違いの1つとして wiki になにを書いてよいかわからない問題がある
    • 文章を書けるようになるのは経験や習熟を必要とする
    • adr のようなテンプレートがあることで経験の浅い開発者も書きやすくなる狙いはある
    • 課題管理システムの wiki に adr のラッピングをして別機能としてみせるのはよいかもしれない
    • 業務の引き継ぎにも adr は役に立つのではないか？
    • adr 一覧をみたり、そこから検索することで検索効率や精度は上がるという想定
  • 大きい会社でも巨大な課題管理システムと wiki が1つだけあって一元管理しているという噂は聞く
    • ある会社では wiki は誤っている可能性があるから信用するなという教訓があった
      • wiki の情報は更新されていない可能性があるから参考にしながら必ず裏をとって業務をしなさいという話し
    • wiki を編集したら必ずレビューが必要になるプロセス
  • notion のプロジェクト管理の使い勝手はどうか？
    • テンプレートを使ってガントチャートやカンバンを作れる
      • 基本的に自分でカスタマイズできることの良し悪しがある
        • db をどんどん改良できるが、それだけに魔改造してしまう
        • 時間とともに複数人が改良すると保守できなくなっていく懸念がある
      • 中核機能をパッケージ側で提供することは堅牢性を担保する上で重要ではないか
    • タスク管理と wiki がシームレスなところはよい、はらさんは日報を書いてリンクしている
  • 会社のインフラに日々の開発情報を書いていくと退職後に参照できない
    • フリーランスのような働き方をするにはナレッジデータベースをローカルに作りたいという欲求がある
    • 組み込みの課題管理システムにより、自身のナレッジデータベースをローカルに残すという目的はよいかもしれない

仕事は楽しいかね？ の考察⌗

まとめを見返しながら、だいたいの項目は理解または支持できる。1つだけ次の項目が私には欠けていることに気付いた。

毎日1つ試し続ければ必ず上達や進歩ができる

  • 新しいことを始めると、いまやっていることを継続する時間がなくなったりしないか？
  • プロダクト開発ではがんばってもあまり成果が出ないような時期もある
    • リファクタリングやテスト追加などはまさにそう
    • そういったときも1つでも変化をもたらせれば日々の生活が変わるのか？
  • はらさんのお奨めは梅原さんの １日ひとつだけ、強くなる。 世界一プロ・ゲーマーの勝ち続ける６４の流儀
  • 本書を読んではらさんのよかったところは「試してみることに失敗はない」
    • それまでも試すことはやっていたはずなのに躊躇してしまう理由として失敗したら時間の無駄だと考えてしまっていた
    • 失敗したら嫌だと考えてしまうところがあったが、この考え方があるから vision pro を購入できる
    • やりたいことをすぐやってみるという思考につながった
  • 面倒くさいときもなるべくパソコンを使うようにしてなにかしら調べる
  • 私はオフィスにいれば、家よりはなにかしら作業するモチベーションになる
  • 目標達成や成果をあげるには環境がもっとも大事
    • 個人の感情を信頼しない
      • 人間は面倒だとすぐ怠けてやめてしまう
    • 環境を整えることでワークフローを洗練させて習慣化する
      • 日記になにか書かないといけないから調べものをする
      • 嫌々ながらでもやっているうちに習慣になってくるとワークフローが洗練していく
      • 人間の運用を変えていくなにかは普遍的な価値またはビジネスチャンスがある
    • 調子の悪いときにどうやって早く脱却するかが大事
      • ひとりでは言い訳を作ったり怠けてしまう
      • このときに他人の助けがいるのではないか？
        • 話しを聞いてもらうだけでも前へ進むきっかけになる

go の結合テスト向けカバレッジ計測の考察⌗

以前リリースパーティーで go 1.20 で結合テスト向けのカバレッジ計測の機能が入ったことを聞いていた。次のブログ記事でやり方が紹介されている。

将来的に結合テストを作るときにカバレッジ計測のカスタマイズを施したバイナリを使って api server を起動する仕組みにすればこの機能を使えることに気付いた。

まずは単体テストを実行して任意のディレクトリ (tests/coverage) にカバレッジ計測のための中間データを生成する。

$ mkdir -p tests/coverage
$ go test -cover ./... -covermode atomic -args -test.gocoverdir="$PWD/tests/coverage"
$ go tool covdata textfmt -i=./tests/coverage -o coverage.out

coverage.out がさまざまなツールの入力となる統計情報となる。例えば、このファイルを使って次のようにしてソースコードのヒートマップの html を作成できる。

$ go tool cover -html coverage.out -o coverage.html

nikolaydubina/go-cover-treemap を使うと treemap でカバレッジのヒートマップを確認できる。

$ go-cover-treemap -coverprofile coverage.out > treemap.svg

カバレッジ計測向けのバイナリをビルドする。そのバイナリを起動するときに環境変数 GOCOVERDIR に単体テストのカバレッジの中間データが含まれるディレクトリを指定する。

$ go build -cover -covermode atomic -o bin/api ./cmd/api/...
$ GOCOVERDIR="$PWD/tests/coverage" ./bin/api -verbose

このバイナリを使って起動した api server に対してリクエストを呼び出すことでカバレッジを計測してくれる。結合テストからバイナリ起動した api server に対してリクエストしたときに GOCOVERDIR に中間データが追加されていく。結合テストを完了したら最終的なカバレッジの統計情報を生成する。 

$ go tool covdata textfmt -i=./tests/coverage -o coverage.out

textfmt のヘルプをみたら同じディレクトリじゃなくてもよいみたい。

$ go tool covdata textfmt -help
...
Examples:

  go tool covdata textfmt -i=dir1,dir2 -o=out.txt

  	merges data from input directories dir1+dir2
  	and emits text format into file 'out.txt'