2003Toolがほしい。処理を書きながらクラスに行ったり戻ってきたりするやり方でとりあえず書けたが、できあがって嬉しいってだけでかなり効率は悪かった。今度はクラスをもっと楽に作れないかな、と考えたわけです。死ぬのでこれまた困りもの。設定なんか分かんねーし。本は一応持ってはいるんだが。これ読んでる余裕は今ないしなぁ。自分の考えていることをインスピや文書で整理するノウハウは身についていると思っているが、開発系の設計能力はかなり貧弱ですなぁ。追記]あとから検索で飛んできた人と昔の自分のためにツッコミ。「設計」能力だけ抜き出して磨くのはたぶん無理だと思う。少なくとも上で書いているような「クラス」は実装レベルのクラスであり、これは実装してみないと分からない部分がまず間違いなく残る。設計上はこっちの方がきれいなように見える1が、実装上は言語の機能やパフォーマンスなど様々な制約でこっちの方がよい、という事態はよく起きる。2図を書く練習で図の扱いはうまくなると思うが、実際の設計は結局のところ動くものをどれだけ書くか、うまくできているコードやドキュメントをどれだけ読むかという泥臭い方法で学ぶのがいちばん確実だと思う。先輩などに教えてもらったりすることは可能だが、文章も絵も自分でかいてみることなしにうまくなることがないように、プログラムもシステム設計も自分でやってみて失敗することなしには恐らく上達しない。どれだけ共通語としてコミュニケーションを促進しますよと言われても、それだけで出来上がるものがよくなることはないので、安心してダメクラスを作って怒られたり反省したりすればいい。自分でコード「も」書く人間にとっては、恐らく設計のノウハウよりも変更に強いコードの書き方のノウハウの方が大切である。3だからまずコードを変更するテクニックを学ぶべきである。書いてインターフェイスを変更する、あるいはインターフェイスを変えずにリファクタリングする、長いブロックを短くする、分かりにくい変数名を付け替える、これらの地道な積み重ねはのちに効いてくるはずである。小さいコード、オブジェクト指向、テストの自動化とリファクタリングについて学び、絶対にこれらを実践すべきだ4。ダメなコードは勇気を持って捨てることも大切。↩もちろん設計通りにならなかったことがコーディングの力不足によるものでないことは前提としておく。逆に言うと、設計と実装のズレはまず間違いなく生じるが、それは仕方ない場合もあるがコーディングの力不足によるものもある。