| SU | MO | TU | WE | TH | FR | SA |
|---|---|---|---|---|---|---|
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 | 1 | 2 | 3 | 4 | 5 | 6 |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
ソースコードを書いていく手順について、意外と情報がない。
自分が経験則でやってることを改めて検討してみる。
まず最初にやるのは、実行される最小のコードを作ること。
C言語のmain関数のようにエントリーポイントの場合もあるし、
GUIアプリのようなイベントドリブンの場合は、何かしらのフック関数だったり。
やることはprintで充分。
自分の書いたコードが絶対に通る場所を手に入れることが重要。
これから作りたいものを、コードではなくコメントで書いておく。
// 名前を表示する
コメントを見ながら、コードにしていって、新たに必要になるものをコメントしていく。
// TODO: 名前を変更可能にする
console.log("taro")
// TODO: 引数で渡せるようにする
var name = "taro"
console.log(name)
引数や関数呼び出しが登場してくると、if文などの制御構文が登場するはず。
function hello(name) {
// TODO: name が空の時は代わりの文字を出す
console.log(name)
}
function hello(name) {
if (name) {
console.log(name)
} else {
console.log("nanashi")
}
}
いろんな手法で構造をシンプルにする。
関数の入出力にコメントを書く。
どういった入力を期待しているか、どういった出力になるかを明示するため。
契約プログラミングのやり方。
処理の中で、意図が構文に現れないモノをコメントにする。
例えば、if文に対して条件式の説明を書くのではなく、その条件にした狙いを書く。
「何とかを更新」のような構文見たらわかることは書かない。
フォーカスを広い範囲に移して考える。
簡単なレベルだと、重複してる関数を消すなど（DRY原則）。
進んだレベルとして、拡張可能性の検討（SOLID原則）。
処理を高階関数で差し込めるようにしたり、if文のべた書きをポリモフィズムに変更したり。
あくまで自分の進め方です。
TDDだと、「最初の足場組立」と「コメントから書く」のが、「ユニットテスト環境設定」と「ユニットテストを書く」に置き換わる。
そう考えると、悪くない進め方なのではないか。