t-wada.hatenablog.jp
t-wada さんご自身の文字起こしなのだ！
以下、前半 1/3 くらいでお話しされている、
「動作するきれいなコード」の目指し方を解説する、その前段階のお話のところ。
「まずきちんとした設計をしなさい、良い設計が得られるまではコードを書いてはなりません」 と言われるとき、では「良い設計」とは何だろうかという話になるわけですね。 これはなかなか答えの出ない難しい問いです。
良い設計を考え続けると非常に長い時間考え続ける罠に嵌ってしまいがちです。 良い設計には明確な終わりがなく、無限に良い設計を追い求めてしまいがちです。
第1の感情は Shame、「羞恥心」です。
「まだこの設計を他の人に見せるのは恥ずかしいな」とか 「まだ考えきっていない気がする。他の人に見せるのは気が引ける」
というような感情です。
次の感情は Vanity、「虚栄心」です。
「いまに見ていろよ。誰にも文句の付けられない設計をしてやるぞ」とか 「対象のドメインを鮮やかに切り取った、皆をあっと言わせるような設計をしてやろう」というような感情です。
そして Perfectionism、「完璧主義」ですね。
「まだ自分の設計は対象システムの世界を完璧に捉えられてはいない。まだコードを書ける段階ではない」や 「まだ自分には見えていないことがあって、突き詰めなければならない、極めなければならない設計がある」のような、無用なこだわりです。
完璧主義に陥り、分析と設計にとても時間をかけてしまう現象は、 プロジェクトマネジメントの世界では一種のアンチパターンとして知られていました。
考えに考え抜いたつもりだったけど、細部に関してあまり考えられていなかった。具体的にどこがどうなるべきかまでは考えられていなかった。設計の焦点が合っていなかったことに気づかされます。
かと思えば「考えに考え抜いて設計してようやくそれをコードに写し始めたのだけど、コードを書き始めてみたら "ここまでやる必要はなかったな" と気づいてしまう」ことも多々あります。
「こういうこともあろうかと」という、エンジニアの価値観を体現した言葉があります。しかし「こういうこともあろうかと」というのは、その予想が当たらなければただのコストになってしまいます。
2019年においても、ソフトウェア開発においてたくさんのフィードバックが得られるタイミングは、実際にコードを書き、それを動かすときです。 実際にコードを書き始めることによって、はじめてコードの書きやすさや読みやすさがわかり、現実的に動作することもわかり、それだけでなく、自分は何が欲しかったのかが本当にわかりはじめます。 実際に書いて動かしてみればわかる。書いて動かしてみないとわからない。 2019年の現在においても、ソフトウェア開発においては、たくさんの現場がそういった現実に向かい合っています。
これは2019年においてもソフトウェア開発は工学になりきれていないことのひとつの証左だと考えています。 どういうことかというと、簡単に言えば予測可能性と再現性が低いんですね。高くはない。（中略）
率直な表現をするなら「書いて動かしてみるまでわからないことがまだまだ多すぎる」というのが現実です。
こういう前置きがあって、「じゃあTDDでやってみようよ」なのだよね。
seichi23.hatenablog.com
先日また社内で TDD の紹介をしたのだけど、やり方そのものに重点を置きすぎて、
なんで TDD やるの？、やろうと思ったの？ みたいなところをうまく伝えられなかったな、と反省してる。
ガッツリ議論すると思ってなくて、準備不足だったな。
もっといままでのこういう自分の学びや気持ちを映した話ができればよかったな、と思う。
けど、t-wada さんのこのブログ読んで、また TDD のこと考えてみて、
自分のこの体験は間違っていないな、ってあらためて思った。
だから、TDD のやり方の話を伝えるのは、間違いじゃない。
基板まるごとの、uiTron/T-Kernel の低レイヤが中心の仕事が多く、
なかなかTDDを試せないと思っているけど、
Linux 上にどこまでだったら持っていけて、マイコン部分がどこまでごまかせるか、とか、
それで開発環境として十分なのか、とか、、、
いやいや、そんなに真面目じゃなくてよくって、
もっとカジュアルに「プログラミングするための TDD」を実践する環境づくりという視点でもって、
ちゃーんと考えてみてもいい時期なのかな、とちょっと思っているところ。
あー、もっと時間がほしい！ どうやってこの目先の仕事たちをやっつければいいの、くそっ！
