プログラミングの基本とは何か。僕が思うに、それは「確実に動くもの」を積み上げることだと考えています。
確実に動くもの
「確実に動くもの」とは何か。それはありきたりですが動作を確認できているものです。プログラムを実行して、動作を確認できているものです。
Ruby界隈じゃない人、ごめんなさい。例えばRailsにRakeタスクを追加したい思っているとします。はじめてRakeタスクを作ろうと思っています。こういうときにどうするか？
まず、はじめて書くものは、物凄く基本的なところから動作を確認するようにするのが良いと思います。この場合、空のRakeタスクを書いて、それがrake -Tとしたときにタスク一覧の中に並ぶことを確認して、rake mytaskとしたときに確実に実行されることを確認するのです。それから、はじめてRakeタスクの中身を書き始めます。
アンチパターン：動くか分からないものを組み合わせるということ
Rakeタスクの例では、まず空のRakeタスクを作って、それがきちんと動作するかを確認することで、確実に動くものを積み上げるアプローチを取りました。
では、もしそうしなかったら、どうなっていたのでしょう？
例えばサンプルコードを見て、一息にRakeタスクを書き上げたとします。だけど、上手く動かない。なんでだろう？ すぐには原因は分からないはずです。そもそもRakeタスクとしての宣言の仕方が悪かったのか、中身の実装の話なのか、何なのか？ 仮に動けばラッキーですが、そのやり方ではいつかどこかでハマって、大量の時間を浪費することになります。
確実に動くものを組み合わせるということ
確実に動くものを積み上げていれば、仮に上手く動かなかったとしても、一番最近に積み上げたものが原因であることがすぐに分かります。
Rubyのような動的言語の良いところは、REPLツール（irbなど）で、すぐに動作確認ができることです。逆説的ですが、REPLツールで動作確認できるように、プログラムを設計して書いていくのも、このアプローチでは重要です。REPLツールで動作確認できないということは、つまり動作が確認できないので、確実に動くものを積み上げられないということになってしまいます。
でも、いちいちREPLツールで動作を確認しながら開発を進めていくのも、規模が大きくなるに連れて限界が近づきます。何せ、新しい変更が古いコードに影響を与えていないとは限らないからです。
そんな問題を解決する仕組みがテストコードです。RSpecといったライブラリでテストコードを書いておけば、毎回昔のコードもあわせて動作確認できるので、より安心して確実に動くものを積み上げることができます。
先ほどREPLツールで動作確認できるようにプログラムを書いた方が良いと言いましたが、テストコードで動作確認できるように、いっそテストコードを書いてから実装コードを書くことをテスト駆動開発（Test Driven Development）と言いますね。動作確認しやすいようにプログラムを設計していくというのは、本当に重要なことなのです。
テストコードだとか、そういう仕組みもいろいろありますが、まず基本の第一歩は手元で動作確認をしながら、確実に動くものを積み上げること。そう僕は思います。
