「単体テストしたら個人開発でもモチベ保てた」っていう随筆
結論
単体テストができるようになっていると、モチベの観点では･･･
- 「この機能は作り終えた！」と自信を持って宣言できる
- 「動いた！」をちょくちょく体験できるから、モチベが保てる
コードの質の観点では･･･
- モジュール化・カプセル化が自然とできる
- 単体テストができない or 組みにくいときは、カプセル化失敗の可能性大
- テストケースをじっくり考えられて、うっかりや予想外の不具合を発見できる
- 「本番だとダメになった」を減らせる
体験談
- よーし、こういうプログラム作るぞー
- 何から手付けるかな？あれ作ろ、これ作ろ
- 疲れた
- (後日) やる気ちょっと出たし、続けるか
- 何してたっけ？どっから続けよう？
- やる気無くした
- 放置
僕は、これを何度かやりました。初めは、自分がやる気の無い情弱なだけだ考えていました。
これがお金をもらう仕事で、納期があるとなれば、どんなにモチベが無かろうと進めていたでしょう。しかし、趣味の一つなので「作らなくても別に困らない」となってしまうわけです。
ただ、「作り始めるだけで未完で放置」を脱却しなくては、と思う自分も居ました。
リーダブルコードとの出会い
ご存知の方も多いのではないでしょうか、「リーダブルコード」。僕の友人もかなり勧めていたため、普段本を積極的に買わない僕も、買って読んでみました。
僕にとっては、その中から特に「無関係の下位問題を抽出する」の章が非常にためになりました。章の内容をザックリ要約すると･･･
ある機能を実装しようとしたとき、プロジェクトには直接関係しないコード (本にある例として、球面三角法の第二余弦定理など) は、別の関数に切り離して、汎用コードを作ろう。
本に示されている恩恵を列挙すると･･･
- プロジェクトのコードが簡潔になる
- 他で再利用することができる
- 改善が楽になる
- 小さく、また独立しているから
「なるほど、これは意識した方が良いし、すぐ初めれそうだ！」実際、自分には思い当たる節が結構あります。山のようなコード量の main 関数を、これまで何度作り上げただろうか･･･。大きな問題を小さくして 1つずつ解決していくという、プログラミングの基本的な姿勢を再認識した次第です。
また、この章の少し後に、「テストと読みやすさ」という章があります。ここで僕は、さらにテストコードを作ることを覚えました。これまで、単体テストという言葉を何度も聞いてはきたものの、面倒臭がって結局サボっていた自分がいました。これを読んだのをきっかけに、テストコードを書き、またそれを残すこともはじめました。
予想外の作用に気付く
汎用コード作りと、その単体テストを実際にやってみると、さらなる恩恵に僕は気付きました。
- 汎用コードは比較的すぐ作れる
- 作るものが小さく、スタートとゴールが分かりやすいから
- 汎用コードなら、単体テストは割と簡単に組める
- 同上
- 「作る -> 動いた」が早く回るから、モチベーションにつながる
- 詳細は後述
プログラムを作っていて一番嬉しいときというのは、やはり書いたプログラムが意図した通りに動いたときです。
これまで僕は、最後までとりあえず書ききって動かす、なんていう方法をしていました。そして、最後まで書ききる前に気力とやる気切れ、というオチ。
それが、汎用コードを作るようになって、単体テストもやるようになったおかげで、「書く・動かす」をずっと短い周期で行うようになったのです。着実に進んでいる実感を持てて、モチベ維持になる。こうして、以前よりもダントツでモチベが長続きするようになりました。
まとめ
何かをする、特にそれが趣味であるとき、根底にあるのはモチベーションです。そして、そのモチベーションの源となるのは、やはり成功体験でしょう。
モチベーションを維持するというのは、かなり大事で必要なことなのですが、「自分の忍耐不足」の一言に片付けてしまっていた自分にも気付いたのでした。
それにしても、急がば回れとはよく言ったものです。
Discussion