top / index / prev / next / target / source
日記形式でつづる いがぴょんコラム ウェブページです。
結局のところ、TPOに合わせてオブジェクト指向を適用していく必要がある、という とても当たり前な だけれども非常に重要なことがわかってきました。
結局のところ、TPOに合わせてオブジェクト指向を適用していく必要がある、という とても当たり前な だけれども非常に重要なことがわかってきました。
開発するソフトウェアの種類 業務システムなのか、基盤システム(フレームワーク類)なのか、ミドルウェア層アプリなのか…
開発期間
同時参画人数 いきなし大量に人が投入されるかどうか
設計時に参画する人のスキル
開発時に参画する人のスキル
運用時に参画する人のスキル TCOの観点からは、じつはここのフェーズがとても重要なのです。
TPOに合わせてオブジェクト指向を適用する範囲や濃度を決定しないと、とんでもなく大変ひどいことになります。短期の間に 優秀なオブジェクト指向技術者を集めることは容易なことではありません。かといって、設計・運用までスキルのある人で固めたとしても、運用時にまで優秀なオブジェクト指向技術者を配置できるかどうかは、難しい現場もあることでしょう。そもそも、業務系の開発現場では、オブジェクト指向技術やJava言語技術よりも、むしろSQL関連技術や業務スキルの方が重要である局面もあるでしょうから…。
オブジェクト指向の適用のさじ加減、ひいては、そもそも「美しい」・「醜い」システムまたはソースコードは どういうものを指すのかについても、やはりTPOと深い関わりがあります。カリカリのフレームワーク類やミドルウェア類における「美しい」実装と、どろどろの業務システムにおける「美しい」実装との間にも、大きなかけはなれがあります。私は 運良くか運悪くか定かではありませんが両方の世界に身を置いているので、双方の美意識や価値観をビミョウに知っています。
そういうどろどろの現場における適切なオブジェクト指向の適用に関する記事って、あまり見かけないのが残念です。ちなみに私は 現状の オブジェクト指向言語を用いた業務システム開発において、オブジェクト指向設計はほとんど不要で無用だと考えています。(端的に言うとそういう主張になるというだけで、掘り下げて表現すると、長い長い話になりますけれどもね)あまり世間的にオブジェクト指向設計不要論というのは出てきていませんね。でもどろどろの業務システム開発現場では、オブジェクト指向設計不要論は そこそこ一般的な思想なのです。そこのギャップが、また味わい深いです。
オブジェクト指向のある種のデザインパターンを業務システムに適用すると、そのモデルを適用した人が プロジェクト体制の上でも そのデザインパターンが適用されるのではないかという恐ろしいルールに、ふと気がつきました。通信部分にファサード・デザインパターンを適用すると、通信系でQ&Aが発生した際に、その人に問い合わせが行きます。だって その箇所がファサードであ、調べるためにはそのファサードを作った人に聞かないと解決できなくって、だからその人はファサードになるのです。プロジェクトが24時間体制になった際に、ファサードを作成した人も24時間体制にならないといけない、これが一番恐ろしい現象です。(たとえ話です。人間は睡眠を適切に採らないと活動できませんものね…)他のデザインパターンについても、オブジェクト指向のデザインパターンとプロジェクト体制の上でのデザインパターンとの間の関連については、考察を深める必要がありそうです。
フレームワーク類にデザインパターンを適用する際には、そのデザインパターンが自分の職制・生活・未来にも適用されるという重要な事実を、アーキテクト/方式屋さんは適切に理解しておく必要があります。ああ、なんて恐ろしい…
tidusさんがExcelMessageResourceという Excelブックに格納されたメッセージリソースをJavaから利用可能にするライブラリのファーストリリースを実施されました。
ああ、すばらしい。ExcelブックとJavaプログラムがどんどん親和性を持ち始めています!
とある場面にて、PuTTYをダウンロードしました。