JAVA系の開発は全体としてのスタートライン歴史が浅いので分離開発が普及していると感じます。
クラサバ系はDOS時代の「べた書き開発」文化が根強いので普及していないと感じます。
分離型開発は,MVC型, 3階層,n階層分離など多々な切り口がありますが, コードビハインドも一つの切り口で、ロジックとUIとの分離と言えると考えています。Asp.Net では定着しつつあるようですが、フォームアプリではとうなるのかなと思っていたら、XAMLという形で登場してきました。時代の流れは、デザイン部とロジック部の独立の方向に向かっている気配が感じられます。前回も書いたのですが、現実の業務アプリの現場では当分 FrameWork3.0の世界には移行できない考えています。とはいうものの、流れを見据えた開発はしたいものです。Framework1.x,2,0の世界での開発で、UI部分のみのクラスとロジックのみのクラスを用いた、我流分離型で設計開発したりしています。
自己完結するシステムの場合は自分のPM責任の範疇なので自由です。が、集団開発となると、PMの技量に依存する部分が大きく、制約が課せられます。PMの技量がシステムの生命線を握っているともいえます。
業界平均のPMの技量は知る由もないのですが、周囲のPMを見ていると、お寒い現実を感じます。
規定の設計標準は金科玉条で神聖にして侵すべからず
設計標準に無い手法は却下
設計書の記述基準になじまない、処理は却下
設計書は納品物なので見栄えのする分厚いほど良い
勘違いしている気がするのです。
設計書の目的は、システムの堅牢性の維持はもちろん,開発の潤滑油でもあると考えてます。無駄な開発、車輪の再発見の防止、システム改修箇所の洗い出しの基礎資料だと考えています。
設計書を納品物とした時点で、設計書作成が目的になってしまい、設計書作成工数に無駄./無意味な工数が散見されます。
記述箇所が多いとバグが増えるのは プログラムのソースと同じ。 業務ロジックの表現や,DBアクセスの部分など同じ記述の塊をコピペで貼り付けて、一部分修正して済ませているのを見かけます。 仕様書作成の世界も、リファクタリンクラ指向的な要素をとりいれ、「二度同じ記述をしない」を実践するだけでも、コストダウンできますし、記述バグもへります。しかし成果物としての枚数が減るので嫌われたりします。......orz
PMの技量との乖離も広がりそうな気配です。
開発に没頭すると知識の取得が疎かになり浦島太郎になるのは解かるのですが、業界の構造的な問題なんですかね。