読者です 読者をやめる 読者になる 読者になる

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

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

コード

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

最初のコード


最後のコード


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

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

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

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

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

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

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

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

プロトタイピング

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

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

例えば今回の例だと

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

とかね。

TDD的な

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

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

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

詳細設計書

最初のコードみたいなのを、どうして書いてしまうんだろう?って思ったのだけど。詳細設計書があるからなんだろうなーと思った。僕は、ドキュメントとしては概要設計書があればよくて、コードが詳細設計書、ということでいいかな。この辺も話しだすと長くなるね。

DDD

今回はトランザクションスクリプト(手続き型の処理)を前提にしてコードを読みやすくしてきたけど。個人的にはドメインモデルが気になっていて、勉強中。気になって5年くらいたってるけど・・・。

試行錯誤

今回やってみたのは、一歩ずつ伝えてみる、というところでした。いきなり最後のコードみたいなのがでてくるわけじゃなくて、ちょっとずつ進んだり戻ったり試行錯誤しながら、最終的にこういうコードになりましたよ。というところ。なんとなく、Java始めて2,3年目くらいの人を想像しながら。

ブログもインクリメンタルに

全部綺麗に書き終わってからドーン!と出すより、ちょっとずつインクリメンタルに出してく方が楽かなと思って、ちょっとずつ出来る範囲でブログ書いてみました。

最後にまとめ

すごいー。僕より全然丁寧!こちらを読みましょう!ありがとうございますw
僕もまたゆっくり読ませていただきますー。

プログラミング/作法/Hello.java - 武内@筑波大