 |
||||||||||||
|
3. 修正の途中で別の問題を見つける（修正する） 保守開発の現場で今動いているプログラムを書き換えるのは善か悪か。特にSIの現場においては、難しい問題となります。 筆者はSIerにとって保守開発とは、医者の仕事に近いと思っています。ある箇所を修正しようとして、開腹してみると別の病巣を発見することはよく聞く話です。このとき医者は、インフォームドコンセントとして、患者もしくはその身内に状況を伝え、合意の下で対策を打ちます。 よってSIerにおいても見つけた問題に対してフタをしたい気持ちに打ち勝ち、しかるべき意思決定者に正しく伝え、相談し対応を決めるべきです。また、問題の軽重にもよりますが、できれば早期治療を行いたいところです。それが結果として将来のトラブルを防止することが実際によくあります。  既存のソースコードのマズイ臭いを嗅ぎとり、プログラムとしての挙動を変えずに体内洗浄を行うことをリファクタリングと呼びます。これはテストコードがあることがその前提です。したがって、保守開発の中でリファクタリングを行う場合、あまり手を広げるとテストが追いつかずバグを作りこんでしまうことになりかねません。本当にマズイところに絞って実施するサジ加減が肝要です。 おそらく「再利用のためにモジュール分割する」という見方が世間では多いと思います。同じように「テストをするためにモジュール分割する」という観点で考えてください。既に作られたアプリケーションに対して、これを適用していくのは骨が折れる作業ですが、必ず効果はあらわれてきます。 Webアプリケーションの場合、通常はMVCモデルに従って設計されていることが多いと思います。中にはビジネスロジックとビューが分離されていないものもあるでしょう。こうした一体型のアプリケーションでは、テストコードが書きづらくWebブラウザからのテストのみが基本となってしまいがちです。そのようなときに、たとえ共通の処理でなくても、ビジネスロジックをサブルーチンとして切り出せば、テストコードを書けるようになります。 Perlにおけるテスト文化は歴史が長く、古いバージョンのPerlでも標準でテスト用のパッケージが含まれています。古くはTestというそのものの名前が使われていましたが、最近のバージョンでは「Test::More」を使うのが一般的です。これを利用すれば、テストをサクサク書き進めることができます。 最後に 言語選択の分かれ道というよりも、選択後の分かれ道という内容で書かせていただきました。私自身Perl以外の複数の言語でもWebアプリケーションの開発・保守を行ってきましたが、最近では特に開発言語による違いはほとんど無くなってきたと感じています。ライブラリの充実、使いやすいフレームワークの存在、コミュニティの勢い、どれをとっても遜色ありません。 そうなると構築実績や開発要員が現時点で確保しやすいかだけで選択しがちですが、それは短絡的であると思います。Webアプリケーションは使われていく中で成長し、継続して使われることによってビジネス価値を生み出すものです。したがって、どう速く作るかよりも、どうシンプルさを保っていけそうかに重きをおいて、これからの開発言語やフレームワーク選定とアーキテクチャ設計を考えていくことがより強く求められるようになるでしょう。 次回は 「言語選択の分かれ道」の最終回では、ポータルサイトのサービス開発でPHPを選択したワケを紹介する。また、連載の締めくくりとして言語選択のもう1つのポイントを解説しよう。 |
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
