ずっと昔に購入しておきながら、きちんと読み干したことのない奴らがいる。仕事が一段落すると、きまって本棚の片隅から手招きしてきやがる。酔いどれ貧乏性に、もったいない感ビームを浴びせて...
技術屋の世界では、すぐに廃れてしまう知識も多い。今となっては、これも古典の部類に入るのかもしれないが、思想哲学がそうやすやすと廃れることはあるまい。おいらは、ソフトウェア工学をある種の哲学だと思っている。数学もそうだけど...
尚、児玉公信、友野晶夫、平澤章、梅澤真史訳版(ピアソン・エデュケーション)を手に取る。
リファクタリング... この呪文は、Smalltalker の間で生まれたという。
Smalltalk といえば、三十年ぐらい前になろうか、オブジェクト指向が巷を騒がせつつある頃、かじりついた記憶が蘇る。おいらは、暗示にかかりやすい。そして、Smalltalk 関係のセミナーをいくつか受講したものの、あまり良い印象を持てなかった。というのも、役立つコードの事例というより、説明しやすいコードの紹介といった感があったから。例えば、金融システムの顧客管理などの事例で。当時、おいらはリアルタイム・システムの世界で生きいきたので、コードはあまり参考にできなかったと記憶している。
おまけに、「Smalltalk = オブジェクト指向」という図式で、万能言語のような印象を与えようとするのにも違和感があった。本書のコード事例にも、これに近い印象をひきずっていないわけではない。
著者マーチン・ファウラーの名はモデリング言語の文献でも見かけたが、ここでは、Java で記述され、よほどの思い入れがあると見える。ただ、C 言語系をかじっていれば、まったく抵抗感はない。そもそも、満足のいくコード事例に出会ったことがほとんどないし、わずかなヒントに出会えれば、それだけで幸せであろう...
プログラミング言語で何を使うにせよ、オブジェクト指向の抽象化哲学には共感できるものが多い。それは、ソフトウェアに限ったことではなく、オブジェクト指向言語を用いなければ実践できないというものでもない。
その特徴といえば、カプセル化、継承、ポリモーフィズムといったところであろうか。カプセル化の概念は、既にこれに近いことをやっていたし、リアルタイム・システムともすこぶる相性がいいので、すんなり受け入れられた。カプセル化を簡単に表現すれば、責任の所在を明確にすること、と解している。
一方、継承やポリモーフィズムの概念は、有難味を実感するのに少々時間を要した。作業効率で誘惑してくる継承... だが、設計思想に適合しなければむしろ弊害となり、バグもしっかりと継承される。なんとも心地よい響きを放つポリモーフィズム... 型の振る舞いを抽象化し、条件記述を効率化できるのは魅力的だが、やはり設計思想を理解した上で実践しないと地雷を踏む。
オブジェクト指向には他にも多くの派生的なご利益があるが、それだけに設計思想という上流工程を疎かにできない。リファクタリングをやるにしても、まず、それに価するコードかどうかの見極めが重要であろう。外部からの振る舞いを保持したままで内部構造を改良していく作業は、慎重にならざるを得ない。コードを読みやすくし、パフォーマンスを向上させようとして、新たな不具合を生み出すのでは何をやっているのやら。リファクタリングだって、万能ではあるまい。実際、スクラッチで書き直した方がいい場合だって少なくない。何はともあれ、「リファクタリング」という用語を宗教化させないことだ。「オブジェクト指向」という用語もそうだけど...
本書は、「リファクタリングには、一定のリズムが重要！」と説く。ちょいと変更して、テスト、ちょいと変更して、テスト... この繰り返しのリズム。コードに対してきちんとしたテスト群を作り上げる習慣もまたリズム。これに、自動化した検証環境を付け加えておこうか。一日の締めくくりに、自動診断プログラムを実行する習慣を。そして、鼻につくコードを嗅ぎ分ける嗅覚を身につけ、単なるコードのクリーニングで済まさず、進化させていきたいものである...
確かに、秩序立った作業は新たなバグを生み出しにくい。だが、秩序ってやつは常識化しやすい側面がある。常識化は、疑う習慣を放棄することにもつながる。科学的な分析は、健全な懐疑心によって支えられているが、この「健全な」ってやつがなかなか手ごわい。自己満足感との兼ね合いもある。
ある大科学者は言った... 常識とは、18歳までに身につけた偏見の寄せ集めである... と。
改善の余地があるかどうかを自問し続ける... この習慣こそがリファクタリング哲学だと解している。
なにごとも整理整頓、そこから思考が正常化される。おいおい... 小学校の訓示か。そんな訓示も、実践できない大人は多い。
開発の現場では、まずスケジュールとの葛藤がある。十分に検討された設計思想は仕事を加速させる。急がば回れだ！そして、プロマネは上層部を敵に回すことに...
ところで、この手の書に触れると、流用コードに対する愚痴が蘇っちまう。おいらはプログラマではない。ハードウェア設計者だ。それでも、ハードウェア記述言語によって回路を実装するし、検証環境では様々なプログラミング言語を組み合わせる。数値演算言語、画像処理ライブラリ、スクリプト言語などなど...
技術的に吟味されたブラックボックスを流用するのは大歓迎だが、政治的に押し付けられたブラックボックスには異臭が漂う。開発期間短縮！という言葉に踊らされるお偉いさんたちは、黒幕に操られているかのように命令する。あるブラックボックスを流用するのに、資料としてバグリストまで添付されるものも見かけたっけ。コードレビューに参加すると、設計者が既に転職し、実体をまともに説明できる者が皆無。バグ報告だけの遺産を、バグを回避しながら流用しろ！という命令だ。そもそも、バグの存在が分かっているのに、なにゆえ修正するよう指示しないのか。いや、誰も手が出せないってことだ。おいらの設計人生で、これほどエンジニアたちの士気を萎えさせるブラックボックスを見たことがない。やはり黒幕が潜んでいるに違いない。ゴミ箱へポイ！
命令通りにやって失敗するなら言い訳も成り立つが、逆らって失敗したら... プロマネが本当に仕事をしようと思えば、クビを賭けなけきゃ、やってられんよ。そして、辞表を机の中に潜ませて仕事をする習慣が根付く。だが、こんな愚かな習慣はやめた方がいい。だって、つい出しちまっから。天の邪鬼な性分は、衝動に勝てんよ...
ちと脱線するが... ずっと脱線してるけど...
本書でチラッと扱われる、コーディングの際のコメントは、善か？悪か？という話題がある。現在でも見かける議論だ。これを一般化することは難しいが、アセンブラ言語の時代はほとんど善であったように思える。もちろんセンスや加減が問われるが。マクロ機能で日本語からコードを自動変換しようとしたこともあったっけ。大袈裟に言えば、日本語プログラミングである。
しかし、スクリプト言語の時代では、コメントは悪に近いかもしれない。修正に二度手間はゴメンだし、コードと辻褄が合わなければ最悪だ。そういえば、コメントはほとんど書かなくなったなぁ... モジュールのタイトルぐらいかなぁ... いや、モジュール名でカバーできる。インターフェース名でも。仕様書も概要を書くぐらいで、あとはコードを見れば、ってな感じ....
0 コメント:
コメントを投稿