自律的な組織を作る目的で行った施策が、実質的にホウレンソウの運用にも役立っていたので、ホウレンソウの視点からまとめました。 報告・連絡・相談、通称ホウレンソウは重要だとよく言われますが、マネージャになって「報告・連絡・相談をしろ」と言ったことはありませんでした。
私は普段、「報告」、「連絡」、「相談」という言葉を使わず、「連携」だとか「連絡」と総称して呼んでいますが、 この記事ではできるだけ分けて使うようにしました。
続きを読む 報告・連絡・相談の重要性自律的な組織を作る目的で行った施策が、実質的にホウレンソウの運用にも役立っていたので、ホウレンソウの視点からまとめました。 報告・連絡・相談、通称ホウレンソウは重要だとよく言われますが、マネージャになって「報告・連絡・相談をしろ」と言ったことはありませんでした。
私は普段、「報告」、「連絡」、「相談」という言葉を使わず、「連携」だとか「連絡」と総称して呼んでいますが、 この記事ではできるだけ分けて使うようにしました。
続きを読む 報告・連絡・相談の重要性参考書籍は Test-Driven Development By Example、 日本語版は テスト駆動開発入門です。
今回読むのは Section III のところです。 テスト駆動開発のパターン について書かれています。
Test の独立性についてですが、 Kent Beck は過去の経験から次のように綴っています。
First, make the tests so fast to run that I can run them myself, and run them often. That way I can catch errors before anyone else sees them, and I don’t have to dread coming in in the morning. Second, I noticed after a while that a huge stack of paper didn’t usually mean a huge list of problems. More often it meant that one test had broken early, leaving the system in an unpredictable state for the next test.
続けて書かれていますが、 ひとつの問題が発生した場合に失敗するテストはひとつであるべきです。 問題の特定を楽にするために。
そんな独立性の高いテストを作る手頃な方法として、 “実行順序に依存しないテスト” が挙げられていますね。
Kent Beck は彼の経験から、 目的を達成するためには (プログラムで実現すべきことを実現するためには) やることを全部書き出すというのがいい と結論づけています。 Money Example
の中でも ToDo List を作っていました。
ToDo List のメンテナンスにも注意が必要です。 Kent Beck は新しい ToDo が増えたとき、 既存の ToDo 含め 次の3つのカテゴリに分けます。
テスト駆動開発において ToDo List に書かれるのは Test として実装するべき事項です。 具体的には Section I
の Money Example
に載っていたものです。
Kent Beck は 大変丁寧なことに、 ToDo の書き方まで説明してくれています。 これは早く実践していきましょう。
Kent Beck はテストを先に書く理由について、 次のように書いています。
確かに、 実装が先に終わってテストがおまけになってしまう、 そんな経験が多々あります。 更に Kent Beck は テストのモチベーションのサイクルについても言及しています。 テストのモチベーションは開発者にとって一番大事かもしれません。
参考書籍は Test-Driven Development By Example、 日本語版は テスト駆動開発入門です。
Money Example の次は jUnit のようなテストツールを作ってみるお話です。 30以上の言語で使われている xUnit は、 今や巨大な資産ですが、 そういったものは自分で作れるものなんでしょうか。
読んでみると、実際にやっていることは難しくなさそうです。 肝となるのは 一連のテストの結果 (実行・成功・失敗したテスト数) をどうやって保持するかではないかと思いました。 独自にテストフレームワークを作るときに役に立ちそうです。
社内でも独自にテストフレームワークを作っている人がいます、 かなりシンプルにできるそうです。 その人によると、 PHPUnit などのテストフレームワークは いろんなファンクションや機能をつけているから複雑になっているそうです。 そうじゃないと使ってもらえないからだとも言っていましたが。
JUnit や PHPUnit は TestCase
だったかのクラスを継承してテストコードを書いていくので 今回説明されていたやり方と同じですね。 でも rspec だと describe で書き始めたりするし クラス の 定義 で始めるわけでもないので 本書とは別のアプローチかもしれません。
参考書籍は Test-Driven Development By Example、 日本語版は テスト駆動開発入門です。
Franc-ly Speaking
のところ(29ページ)からです。 Franc
を導入して複数通貨に対応させるんですね。 39ページに至るまでの流れを見ていくと次のようになります。
Dollar
を複製する。 テストコードも複製する。Money
と 継承クラス Dollar
, Franc
に分ける。Money
クラス に共通のものを集約する。Dollar
から Money
へ、 子クラスから親クラスへメソッドを移す手順には要注意ですね。
途中、 toString()
というメソッドを、テストコードを書かずに追加しています。 この判断基準は重要なのでまとめておきます。
次の条件を満たす場合は、テストコードを書かなくてもOKとします。
普遍的にまとめた記述が今のところ出てきていないので toString()
追加の際の説明をまとめたものになっています。
toString()
程度 だったらテストを書いてもよさそうですが、 もっと複雑なものに成った場合には テストを書かずに進めた方がいいんでしょうか。 これは実践あるのみですね。
その後 Money Example
の演算の実装と、 全体を俯瞰した傾向、 テストの品質について重要な記述がありますが、 ひとつひとつ紹介すると長くなるので割愛します。 でもひとつだけ気になる記述があるので紹介します。
Easy to read for programmers – Unsynchronized documentation is scarce. The tests will be more valuable if they are readable, giving an interesting second perspective on the messages hidden in the source code.
テストを書けば仕様も理解しやすくなるかもしれないと思いました。
キットカット ショコラトリー スペシャルを食べました。 市販のいつものキットカットとは味が違います。 とても上品な感じがします。 今回食べたキットカットは、日本を代表する「ル パティシエ タカギ」のオーナーシェフ高木康政氏が開発した大人のキットカットです。
私が手に入れた キットカット は次の 5つ です。
ウエハースとナチュラルチーズを包んだ作品。 チョコレートの甘さと しっかりとしたチーズのコクが楽しめます。 チーズとチョコレートだと打ち消し合うような気がしてしまうんですが、チーズの味も濃厚でチョコレートの甘さも効いています。
苺の甘さとホワイトチョコレートの甘さが混ざりあった作品。 素材の味が活きています。 じっくりと味わいながらいただきました。
厳選された宇治抹茶ときなこのコラボレーション。 濃厚な抹茶の旨みとコクに包まれながらも きなこの香りが楽しめます。 とっても上品な味がしました。
爽やかなオレンジの一品。 濃い感じは一切なく、とても爽やかで また食べたいと思う味です。 チョコレートのイメージがガラッと変わります。 東京エリア店舗限定品だそうです。
上品な辛みをミルクチョコレートで包んだ作品。 口に入れた瞬間、ジンジャーの香りが広がります。 ジンジャーだけどまろやかな甘味もあって絶妙な味わいです。
この中で私が一番おいしいと思ったのは、キットカット ショコラトリー スペシャル オレンジカクテルでした。 爽やかな感じが忘れられません。
本当においしいので是非たべてみてください。