💪

「単体テストしたら個人開発でもモチベ保てた」っていう随筆

2022/12/05に公開約1,700字

結論

単体テストができるようになっていると、モチベの観点では・・・

  • 「この機能は作り終えた!」と自信を持って宣言できる
  • 「動いた!」をちょくちょく体験できるから、モチベが保てる

コードの質の観点では・・・

  • モジュール化・カプセル化が自然とできる
    • 単体テストができない or 組みにくいときは、カプセル化失敗の可能性大
  • テストケースをじっくり考えられて、うっかりや予想外の不具合を発見できる
    • 「本番だとダメになった」を減らせる

体験談

  1. よーし、こういうプログラム作るぞー
  2. 何から手付けるかな?あれ作ろ、これ作ろ
  3. 疲れた
  4. (後日) やる気ちょっと出たし、続けるか
  5. 何してたっけ?どっから続けよう?
  6. やる気無くした
  7. 放置

僕は、これを何度かやりました。初めは、自分がやる気の無い情弱なだけだ考えていました。

これがお金をもらう仕事で、納期があるとなれば、どんなにモチベが無かろうと進めていたでしょう。しかし、趣味の一つなので「作らなくても別に困らない」となってしまうわけです。

ただ、「作り始めるだけで未完で放置」を脱却しなくては、と思う自分も居ました。

リーダブルコードとの出会い

ご存知の方も多いのではないでしょうか、「リーダブルコード」。僕の友人もかなり勧めていたため、普段本を積極的に買わない僕も、買って読んでみました。

僕にとっては、その中から特に「無関係の下位問題を抽出する」の章が非常にためになりました。章の内容をザックリ要約すると・・・

ある機能を実装しようとしたとき、プロジェクトには直接関係しないコード (本にある例として、球面三角法の第二余弦定理など) は、別の関数に切り離して、汎用コードを作ろう。

本に示されている恩恵を列挙すると・・・

  • プロジェクトのコードが簡潔になる
  • 他で再利用することができる
  • 改善が楽になる
    • 小さく、また独立しているから

「なるほど、これは意識した方が良いし、すぐ初めれそうだ!」実際、自分には思い当たる節が結構あります。山のようなコード量の main 関数を、これまで何度作り上げただろうか・・・。大きな問題を小さくして 1つずつ解決していくという、プログラミングの基本的な姿勢を再認識した次第です。

また、この章の少し後に、「テストと読みやすさ」という章があります。ここで僕は、さらにテストコードを作ることを覚えました。これまで、単体テストという言葉を何度も聞いてはきたものの、面倒臭がって結局サボっていた自分がいました。これを読んだのをきっかけに、テストコードを書き、またそれを残すこともはじめました。

予想外の作用に気付く

汎用コード作りと、その単体テストを実際にやってみると、さらなる恩恵に僕は気付きました。

  • 汎用コードは比較的すぐ作れる
    • 作るものが小さく、スタートとゴールが分かりやすいから
  • 汎用コードなら、単体テストは割と簡単に組める
    • 同上
  • 「作る -> 動いた」が早く回るから、モチベーションにつながる
    • 詳細は後述

プログラムを作っていて一番嬉しいときというのは、やはり書いたプログラムが意図した通りに動いたときです。

これまで僕は、最後までとりあえず書ききって動かす、なんていう方法をしていました。そして、最後まで書ききる前に気力とやる気切れ、というオチ。

それが、汎用コードを作るようになって、単体テストもやるようになったおかげで、「書く・動かす」をずっと短い周期で行うようになったのです。着実に進んでいる実感を持てて、モチベ維持になる。こうして、以前よりもダントツでモチベが長続きするようになりました。

まとめ

何かをする、特にそれが趣味であるとき、根底にあるのはモチベーションです。そして、そのモチベーションの源となるのは、やはり成功体験でしょう。

モチベーションを維持するというのは、かなり大事で必要なことなのですが、「自分の忍耐不足」の一言に片付けてしまっていた自分にも気付いたのでした。

それにしても、急がば回れとはよく言ったものです。

Discussion

ログインするとコメントできます