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