まとめ：僕の好きなコードの書き方

々々と続いてきたけど。やっと終わり。まとめるー！

道のり

僕の好きなコードの書き方 - Mitsuyuki.Shiiba
続：僕の好きなコードの書き方 - Mitsuyuki.Shiiba
続々：僕の好きなコードの書き方 - Mitsuyuki.Shiiba
続々々：僕の好きなコードの書き方 - Mitsuyuki.Shiiba
続々々々：僕の好きなコードの書き方 - Mitsuyuki.Shiiba
続々々々々：僕の好きなコードの書き方 - Mitsuyuki.Shiiba
続々々々々々：僕の好きなコードの書き方 - Mitsuyuki.Shiiba

コード

最初のコードよりも、最後のコードの方が、何をやろうとしてるかが伝わってくるよね。
何かを買って、そのお釣りと商品を返そうとしてるんだろうなーって。

最初のコード

最後のコード

Gist

My Favorite Code · GitHub

履歴

Revisions · My Favorite Code · GitHub

僕の好きなコードの書き方

初回に書いたけど、僕は「パッと見て何をしてるかが伝わってくるコード」が好きです。コードを書いた人の意図が伝わってくるコード。そのために、どんな感じで作業してきたかというと：

近くに置く
ネストを浅くする
終わっていいならreturnする
必要になる場所でインスタンス化する
メソッドを切り出して概念に名前をつける
変数に適切な名前を付ける
ちょっとでも直感的に読めるようにする
実際に書いてみて遠くから細目で見てみる

まとめると
「構造をシンプルに」「名前を適切に」という二点に気をつけて読みやすいコードを考えて、
その考えた書き方が本当に読みやすいかどうかを「実際に書いて見てみる」。という流れなのかな。

ってことみたいですね。普段あんまり考えずにやってるので、ちょうど今回の一連の流れで整理できたや。

リファクタリングではない

と、ここまで意識して「リファクタリング」という言葉を使わなかったんだけど。・・・たぶん、使ってないはず。
今回の一連の改善はリファクタリングじゃないです。テストもないし、元々のコードの動きを変えてるもんね。

じゃあ何なのよ？ってことだけど、僕が想像してたシチュエーションは「プロトタイピング」。

プロトタイピング

1. プロダクトオーナーに「こんな機能が欲しい」って言われる
2. ざっくりした要望を元に、プロトタイプを書く <- ココ！
3. 意図を伝えるコードを書こうとすると、色んなことに気づく

最初のコードみたいなのを書くより、最後のコードみたいなのを書くほうが色んなことに気づける。

例えば今回の例だと

入力値が不正な場合はエラーで処理してていいのか？どの入力値がどんな風に不正なのかを返してあげなくていいか？
商品は10円未満の端数を持たないのか？もし持っていた場合は例外を投げた方がいいのではないか？

とかね。

TDD的な

今回テストも書かずにやったんだけど、プロトタイプだからバグっててもいいやと思って。で、プロトタイプが終わったら、

2-1. 気づいたことを元にプロダクトオーナーとチームと話合って仕様をブラッシュアップ
2-2. 最初のプロトタイプは捨てて、TDDでコーディング進める

こんな感じかな。プロトタイプの後の仕様のブラッシュアップで、結構変わってしまうことが多いから、この段階ではあんまりテスト書かない。仕様がかたまったら、TDDでちょっとずつ進める感じ。TDDは部分が自分の意図通りに動いているかを一歩ずつ確認しながら進むためね。そしたら、getChangeCoinsが意図通りに動いてないことに早い段階で気づけるし、他にもバグがないって安心して眠れるし。気にするのが仕様のバグだけになる。そうそう、だから、TDDとは別に仕様のテストを・・・あ、いやこれ言い出すと長くなる。今回関係ないし、やめとこ。