私たちは前でこう言った。
大枠(Module)を掴め
その中を具体的な領域(Class)に分けろ
その中で実際の行動(Method)を定義せよ
この方法は明らかに効果的である。
しかし読者はこう感じるかもしれない。
"でも…それでも難しくて負担に感じます。"
"まだ全体をどう実装すればいいのかよくわかりません。"
"細かい機能をどう分ければいいのかわかりません。"
正常である。
なぜならModule–Class–Methodは
"構造を作る考え方"であり、
今必要なのは
その構造の中で
"実際の実装を始める考え方"だからである。
ここで登場する2つの概念がある。
psuedo code(疑似コード)
TDD(Test Driven Development)
これら2つは
開発をする際に負担を極端に減らしてくれる。
1) Psuedo Code — コーディングせずにまず頭の中を文章に出せ
psuedo codeはそのまま
"本物のコードではないが、コードのような文章"である。
私たちは実際に動作するコードをすぐに書くのではなく、
まずこれを書く。
例えば "ログイン機能を作ろう"とすると:
ユーザーがメールアドレスとパスワードを入力する
DBから該当メールアドレスを持つユーザーを探す
パスワードが合っているか比較する
合っていればログイン成功状態を作る
間違っていればエラーメッセージを表示する
これはRubyでもPythonでもない。
ただの"考えの流れ"である。
しかし、この1行1行が
すぐにMethodになり、
Classになり、
Module構造の中に入っていく。
大枠を考えずに小さな動作を順番に書くだけで、すでに解決の半分が終わったことになる。
これがpsuedo codeが持つ力である。
psuedo codeが与える最大の利点
コードを知らなくても機能を設計できる
複雑な機能を単純な文に分割できる
"どこから始めればいいか"の不安が消える
後で実際のコードを書く際にミスが減る
プログラミングをうまくする人は
コードをうまく書く人ではなく、
コードを書く前に問題を明確に説明できる人である。
2) TDD(Test Driven Development) — まずテストを書き、後でコードを埋める
TDDはこう始まる。
"望む動作をまず文章で定義して、
それを満たすコードを後で作る。"
順番を逆転させるのだ。
例えば "2つの数字を足す機能"を作りたい場合、
まずテストをこう書く。
expect(add(2, 3)).to eq(5)
この1文はこう言う。
"addという機能があるはずであり"
"2と3を入れると"
"結果は5でなければならない"
このテストは当然最初は失敗する。
なぜならadd関数がないから。
それではこの失敗を解決するために
最低限のコードを追加する。
def add(a, b)
a + b
end
そしてテストが緑色(成功)になる。
このプロセスは"機能を小さな単位に分割して開発する方法"を
脳に自然に刻み込む効果がある。
TDDの強力な効果
一度に巨大な機能を作らなくてもよい
小さな機能単位(Methodレベル)で考えればよい
考えの流れが明確になり、ミスが劇的に減る
まるで自動運転支援装置のように"自分がうまくやっているか"をチェックしてくれる
機能が複雑になればなるほど大きな価値が出る
つまり、TDDは
大きな問題を小さなブロックに組み立てる最も効果的な方法である。
Psuedo Code + TDD = レゴブロックを組み立てるように開発する考え方
これら2つを一緒に使えば
問題は幾何級数的に簡単になる。
1. psuedo codeで全体の流れを書く
→ レゴの説明書を作ると考えればよい。
2. TDDで一つずつ成功させながら実装する
→ レゴブロックを一つずつはめ合わせると考えればよい。
この方法は
Module → Class → Methodの構造を
最も安定して実装するワークフローである。
コーディングが怖くない。
なぜならすべての問題は
小さな断片に分かれていて
その断片を一つずつ成功させれば
全体が自然に作られるからである。
読者はここで気づきを得る
"あ…一度に完成させようとして難しく感じていたのね。"
"psuedo codeでまず説明しておいてTDDで一つずつ成功させれば
複雑な機能も結局完成するんだ。""レゴのように組み立てる方式なら…
私も大きなプロジェクトを作れるはずだ！"
この気づきが生まれると
読者はもはや恐怖の中で開発を始めない。
代わりに"分割して構成するマインドセット"を持つようになる。