モブプログラミングに向いてない私の話

Programming

新型コロナウィルスの影響も長引いてますが、皆さま無事お過ごしでしょうか。私は幸い無事です。

日ごろチームでソフトウェア開発をしているのですが、近年社内ではペアプログラミングやモブプログラミングが流行しています。私のいるチームでもここ二年ほどモブプログラミング（ないし類似のプラクティス）に取り組んできました。

モブプログラミングについて正確にどのようなものかは以下の記事などをご参照いただければと思います。簡単にまとめると、要求分析やコーディング等幅広い開発作業を、同じ場所に集まったチームの共同作業でこなしていくというものです。このご時世ですので、最近はオンラインのミーティングルームに集合する形式でしたけど。

www.agilealliance.org

ここから先は、非常にパーソナルな、私に限定された体験になります。どの人・チームにも適用できる話ではありません。ではありますが、どの人・チームにも適用できない体験というそのこと自体を共有したいと考えて書いています。

2020-10-21

HTTP 100 Continue in Go

使おうとするたびに忘れて調べなおすのでメモ。

HTTP のレスポンスコード 100 は、クライアントが大きなデータを送る前に送信ヘッダレベルでリクエストの受付が可能か調べて、処理可能ならいったん返すためにある。

用途例： Authorization ヘッダによる認証, Content-Length によるサイズチェック

Go の http.Client では Transport で ExpectContinueTimeout を 0 以上に設定し、リクエストヘッダに Expect: 100-continue を入れれば、自動で 100 Continue を待機してからボディを送るようになる。

http.Server は request.Body から読みだすと自動で 100 Continue 応答をクライアントに投げる。なので 200 以外のエラーは Body から読みだす前にヘッダをチェックして返すようにすれば良い。

2020-08-31

To mock, or not to mock, that is the question

Programming

さて、テストコードなんて書きたくなかった私ですが、世の流れには逆らえず今はせっせとテストコードを量産しています。開発完了＝試験完了＝出荷可能が求められる忙しない世の中でありますから。

目下開発しているのは Kubernetes 向けのネットワークソフトウェア Coil のバージョン 2 なんですが、この開発では main 文以外はすべて自動テストする徹底ぶりです。他にも近年様々にテストコードを書いてきた過程で、以下の知見を得るに至りました。

外部依存はなるべく実物を使う
- etcd を使うなら etcd を用意、ネットワークをいじるなら network namespace を用意、...
内部依存はなるべくインタフェースで依存注入する

多分この結論に似たことはあちこちで言われている気はするのですが、結論に至った理由が大事と思うため、以下少し書きます。あ、以下モックと言ってる用語は専門的には stub だったり test double だったりするかもしれませんが、細かいことは気にしないでください。

誰かの役に立てばいいブログ

by ymmt2005

ダイエット

root 権限がいらない Squid Docker イメージを作った

Kubernetes 専門家として知るべき 47 のこと

あけまして Ubuntu 20.04 開発環境

モブプログラミングに向いてない私の話

HTTP 100 Continue in Go

To mock, or not to mock, that is the question