またまた間が…
これではダメだとわかっていても、ちょっとしたことで忘れてしまいますね…
34 API設計の黄金律 (マイケル・フェザーズ, Michael Feathers)
APIの設計というのは、難しいとよく聞きます。体験したことのない私には実感のない話ですが、APIの設計のための分厚い本があったりするので難しいのでしょう。
API自体のユニットテストというのはよく見かけます。
確かにそれがないAPIはどうしても使用の際にテストから読み取れる実装コードの意図というものが読めなかったりして、苦労します。
ただエッセイに書いてあるような、APIを利用するコードに対してテストというのは初めて聞きました。
確かにAPIを使ってコードを組み上げた時に、ユニットテストができない状況というのは、問題です。
それをAPIを開発する際にしっかりと意識するというのは重要で、「APIを提供するときは、API自身のテストだけでなく、必ずそのAPIを利用するコードのユニットテストも書く」という黄金律に則って、開発するというのがよい方法ですね。
35 超人の神話 (ライアン・ブラッシュ, Ryan Brush)
・・・うーん、身にしみる言葉ですね。
「超人はいない」
どうしても超人にみえてしまう人というのは少なからずいて、「この人なら、すぐに解決してくれる」と思えるような人がいます。
ただ、もちろんそれは実際には異なっていて、より詳細な設計、開発に関する問題の発生に関しては、聞く側の方がより詳細な問題や状況への理解があることは少なくないはずです。
確かに同じように見える問題が、実は全く異なる経路をたどってたどり着いた、全く別の問題であることもよくあります。
私自身も質問をされて、「それはどういう場面で？」と聞きかえしたりすることもよくあります。大体聞き返すときはその問題に対して複数の回答があると知っているくらいの知識がある時なのですが、そうでない場合には間違った回答を与えているかもしれません。
自分自身もそういうときがないわけではないので、気をつけなければなりません。
質問するときは、しっかりとその問題の周りの情報を自分なりに収集・分析して、それを提示できる状態で質問するということを心がけるべきですね。
「何も言わなくてもわかってくれる」のは自分だけですね。
36 ハードワークは報われない (オルヴ・モーダル, Olve Maudal)
私がアジャイル開発の本で読んだ「ハードワークを控える」というのとは少し異なる意味でのハードワークを控えるですね。
人間の集中力というのは1日8時間程度が限度で、それ以上は効率が落ちるという話があります。
ただ、このエッセイではそれとは別に、効率を上げたりするために知識を深めたり、しっかりとした準備を行う時間が必要で、そういった努力のための時間を使えないような働き方をしているのは賢明ではない、と言っています。
確かにコードを書くときに、ひたすら書いていれば確かに出来上がるのですが、まるで関係のない知識が役に立つこともよくありますし、ひっそりと考え方などに影響していたりします。
そういう時間を奪うようなスタイルで仕事を続けるのはたしかに「報われない」かもしれませんね。
最後に
またもなかなか触れることのできていない部分が多くありました。
ただ、APIの設計や仕事というのはこれから先、どこかで直面する問題なのでしっかりと心にとどめておきたいですね。
質問の仕方、これについても私自身気をつける点は多いです。相手が「分かってくれる」ではなく、相手が「分かるように」することが重要ですね。
