TDDの権化、t_wadaさんによるTDDワークショップに参加しました

t_wadaさんによるTDDの1dayワークショップに参加しました

2018/2/27(火)にTDDのスタンドの使い手 id: t-wada さんによる、1日ワークショップに参加してきました。 一ヶ月以上もブログ書くのが遅れてしまった…

ワークショップアジェンダ

ワークショップは以下のような流れですすみました。

  • TDDについての講演
    • 講義とライブコーディング
  • ペアプロ
    • 全員参加のコードレビュー大会

TDDについての講演

テスト駆動開発とは何かというところから始まり、TDDがうまくいかない(主に技術的でないもの)原因を学び、TDDを実際に行うためのサイクルをライブコーディングを交えつつ披露していただきました。

こちらの詳細な内容については、 以下で非常によくまとめていただいていたので詳しい内容は割愛して僕の感想だけ書こうと思います。(講義時のメモをまとめたら全く同じ内容の記事ができてしまったため)

developer.ntt.com

予測可能性について

講義の中で、今はまだソフトウェアが工学(Engineering)になりきれておらず、予測可能性が低いという話をされていました。

まさに目からウロコといった表現で、実体験としてこういうことを感じており非常に心に響きました。言い方をかえると「書いてみないとわからないことが多い」という当たり前のようなことですが、設計してるときはついつい忘れがちになります。 わりと緻密に設計をしたつもりでも、いざコードを書いてみると全く想定していないところで動かないことは頻繁にあり、今までは単に「辛い」と女子高生のような語彙力の低さを撒き散らしていたので、これからは「予測可能性が低いから(ｷﾘｯ)」と言おうと思います。

どうやって「動作するきれいなコード」へいくか

ソフトウェア工学の世界では予測可能性が低いので「動かない汚い -> 動く汚い -> 動くきれい」(動かない汚いって単体で見るとすごい表現だな)というステップを踏もうとします。 そのために取れる手法のうちの一つがTDDというわけです。 しかし、このステップを進もうとするときにどす黒い感情が我々の前に立ちはだかります。

  • 堕落
    • 動いてればいいじゃん
  • 焦り
    • 動いているから、もっとほかのところ、次のところをやるべきではないか
    • 内発的な焦りと外発的なプレッシャー
  • 恐れ
    • 動くコードをきれいにしていく過程で動かなくなったら意味ないじゃん
    • しかし、ソフトウェアの世界が日進月歩なので動いているものを手をいれて変えないと、いつか動かなくなる

これらはそれぞれ誰にでも経験があるだろうことで、もっと言えばみんな上司とか偉い人から言われたことあるよね????(ぼくはあるよ)。

こいつらを乗り越えないと「動かない汚い -> 動く汚い -> 動くきれい」といった順番に乗れず、予測可能性が低い方法(しつこい)を取らざるを得なくなったり、動くけど汚いコードのまま過ごすはめになるわけです。

TDDではこの中でも特に「恐れ」に対抗する手段としてとれる手法とおっしゃっていました。

TDDのサイクル

- 次の目標を考える
- その目標を示すテストを書く
- そのテストを実行して(予想どおり)失敗させる(Red)
- 目的のコードを書く
- テストを成功させる(Green)
- テストが通るままでリファクタリングを行う(Refactor)

TDDのサイクルを載せました。TDDではこの中でもrefactoringが一番折れやすく、ないがしろになりやすい(「堕落/焦り」ですね)のでここは普段のプログラミングや日課に紛れ込ませてやるのがいいとおっしゃっていました。

(例えば、テストと目的のコードをたくさん書いたあと、次のスプリントはまるまるリファクタリングさせて下さい！ よりも日々の中にリファクタリングを積んでしまったほうが良い。スプリントまるまるリファクタリングに費やすと新規機能が0なのでSMやPOからしても指示や承諾がしづらい)

ペアプロとコードレビュー大会

さて、午後からはペアプロの時間でした。お題は Semantic Versioning(参考: Semantic Versioning 2.0.0 | Semantic Versioning)です。

1時間半程度のペアプロをしてその後全員参加のレビュー大会をする、という流れを二回繰り返しました。

載せて良いのかわかりませんがその時のペアプロしたものと、あとからいろいろと変更を加えたものをおいておきます。

github.com

私はpython3 + unittestを利用して課題に取り組みました。 行った感想としては

  • ペアと一緒に要件を書き出していって、書き出した順に実装していたのですが、もう少し順番を考えたほうが良かった。
    • 今回はスピード勝負ではないので問題ないといえば問題ないんですが、一番複雑なところから手を付けてしまった。
  • 要件の洗い出しについては「近いところを詳しく、遠いところはざっくりと」ということをt_wadaさんがおっしゃっていて、非常に重要な感覚だなぁと思いました。色々な要件を実装する際に最初からすべて考えようとすると、前提条件の実装が動いていないので非常にコストがかかる感じがしました。そろそろ実装するぞ(=近い所)というところだとすぐ実装を決められます。最初から全ての要件を綺麗にしようとすると予測可能性があれということをこの時間のうちに体感できました。
  • python的な書き方に少々つまずき、綺麗でない実装になってしまった
    • ちゃんとgitに上がっているやつは直しています。commitログをみるとすごい複雑なif文が表れますｗ

全体的な感想

  • Testを書くこと自体もそれほど得意ではなく(やったことはあるが体系的に学んだことがない)、TDDに関しては完全にノータッチだったのでイチから学ぶ機会を頂いて非常に良かった。
  • 単純にペアプロしてレビューするのが楽しかった。
  • 企画してくれた先輩にとっても感謝します。