![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>開発ツール]] * 目次 [#vdb51828] #contents *概要 [#c2d64c21] 開発支援ツールには色々なものがあり、分類は[[参考>#md49fd9e]]にまとめた。 *トレンド [#qedb1c0c] 開発支援ツールには、昨今、以下のようなトレンドがある。 **世界的には、 [#q4573886] ITビッグ 5（ Microsoft, Apple, Amazon, Oracle, etc. ）など~ がリリースする開発ツールの殆どは以下の特性を持っている。 -[[IDE>開発支援ツールの種類#b818d91a]]であり、柔軟性と汎用性が非常に高い。 -[[設計情報（デザイナ操作、スキーマ定義）型の自動生成方式>開発支援ツールの自動生成方式#fe4a7148]]が採用されている。 [[IDE>開発支援ツールの種類#b818d91a]]周辺の動向を見ると、自社のプラットフォームを利用させるための~ [[IDE>開発支援ツールの種類#b818d91a]]を中心とした言語・ライブラリ・開発ツールのエコシステムに、~ 非常に大きな投資を行い、大きな投資対効果を期待していることが解る。 **日式SIer的には、 [#n91ce970] ***[[EUC、RADツール>開発支援ツールの種類#fb3f61c9]] [#p5cb4d9f] -EUC向けの差別化を行っているため、SI事業に適合しない。 -故に、商材として担いでいるケースはあるが、自事業で利用することは殆ど無い。 ***[[統合CASEツール>開発支援ツールの種類#xb5fa00b]] [#abb347ae] -その一方、日本のSI事業者では、~ 「業務システム開発」の作業を単純作業化する志向が強い。 -そのため、「業務システム開発」に特化した、 --[[統合CASEツール>開発支援ツールの種類#xb5fa00b]] --その他、以下を行うためのツール ---標準化 ---共通化 ---自動生成~ [[リポジトリから自動生成>開発支援ツールの自動生成方式#ed279100]]~ [[（Excelなど）設計書型から自動生成>開発支援ツールの自動生成方式#fe4a7148]] >が多数開発されてきた。 -しかし、多様化の時代に、これらのツールは衰退の一途を辿っている。 --これらのツールは柔軟性と汎用性が低く、~ 多様化するアーキテクチャに追随できない。 --多様化の時代、エンジニアの価値は右肩上がりだが、~ 自身の価値を高めないツールをエンジニアが積極的に習得しない。 --ベンダ目線でできている。 ---従って、エンド・ユーザ目線でできていない。~ （ベンダ内でも案件向けサポートが必要なケースが多い） ---このため、導入の際に、~ 「過去にｘ社のツールに辛酸なめさせられた。」~ 的なエンド・ユーザの経験を聞くことがある。 ***テンプレートと最小限のフレームワーク & ライブラリ [#o75389df] -上記を鑑みると、~ ドメイン（ここでは≒業務システム開発）に特化した開発効率の向上施策は、~ [[IDE>#q4573886]]ベースのテンプレートと最小限のフレームワーク & ライブラリが最善と解る。 -テンプレートには以下の役割がある。 --プロジェクト構成や、下位スタックを決定する。 --AOPやOOPの技術を使用して、共通化とその呼出を行う。 -ただし、独自開発のフレームワーク & ライブラリ部分は、以下に影響を受ける。 --独自開発部分は、対象規模が大きくなると、SI事業の商習慣上、逆に薄くなる傾向がある。~ （ビッグ・アカウントの場合、力関係でフル・スクラッチを強要されるケースがあるため） --また、下位スタックの安定性に影響を受ける。~ （[[Windows Forms]]や[[ASP.NET Web Forms]]の安定性は非常に高いが、~ 昨今のJSのMV*など、安定が非常に低いフレームワークの上では維持できない。） -事例 --[[Open棟梁>http://opentouryo.osscons.jp/]]は、初期からこの設計思想で開発されている。~ また、[[IDE>#q4573886]]と同様に、[[設計情報（デザイナ操作、スキーマ定義）型の自動生成方式>開発支援ツールの自動生成方式#fe4a7148]]を採用している。 --TERASORUNAは、v5.0からこの方式に変わっているもよう。~ ※ TERASORUNAでは、テンプレートをブランク・プロジェクト呼んでいる。 -参考 --Javaエンジニアに知ってほしい、Springの教科書「TERASOLUNA」 #jjug_ccc #ccc_f3~ https://www.slideshare.net/jjug/javaspringterasoluna-jjugccc-cccf3 *その他 [#h9d29cde] **UIサブシステム [#ae5ae778] -UIサブシステムは、基本的に、 --プラットフォームに組み込まれており、 --また、[[IDE>#q4573886]]とフレームワークが提供されているため、 >「[[Windows Forms]]」や「[[WPF]]」など、その開発が容易にできるようになっている。 -しかし、そのクロスプラットフォーム性が注目され、昨今、~ UIサブシステムと認識されつつある「[[HTML/CSS/JavaScript>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?HTML%2FCSS%2FJavaScript]]」は、~ 下位スタックの進化が著しく、不安定で、フレームワークのライフサイクルが短いことが多い。~ （これは、「[[HTML/CSS/JavaScript>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?HTML%2FCSS%2FJavaScript]]」が、テキスト修飾・閲覧のためのUIから~ アプリケーション開発のためのUIに変化している最中と言えるのかも知れない） -参考 --短命なJavaScriptフレームワーク~ https://www.infoq.com/jp/news/2018/02/javascript-lifespan-limited#.WobeHSDzdlo.twitter **Dry (Don't repeat yourself) [#gbdb10f2] -観測範囲で、Webやフリーランス界隈では、Dryが尊ばれている様に見えるが、~ 下記の「Dryで書いたものが負債になっていく。」という発言もあり、~ https://twitter.com/mizchi/status/959297746908856320 -小規模なスクラップ・アンド・ビルド案件が、 --大規模化して維持・保守が必要になった場合に、 --密結合なDryの状態で開発されていたら、 ---≒ デファクトなフレームワークの生のAPIを触りたい為、レイヤ分割を避けている。 ---≒ モジュール強度が強く、結合度が弱くなる境界で分割されていない。 >標準化・共通化などによるコントロールが必要になった時点で、対応できなくなる。 -例えば、[[Open棟梁>http://opentouryo.osscons.jp/]]導入案件でも、案件毎に、更に追加のレイヤが追加される。 **オレオレ・フレームワーク [#v8ef209c] -明確な定義は無いが、 --案件レベルで作成した、 --質の低い独自実装 >全般を指すモノと思われる。 -しかし、（[[上記>#gbdb10f2]]の様な）Dryを脱却した後に、~ 案件レベルで追加するレイヤは、きっとオレオレ・フレームワークになる。~ （従って、殆どの開発者はオレオレ・フレームワークを開発していることになる） -フリーランスなどからしてみると --習得したい知識では無いし、 --足枷のように見えるようだが、~ >チーム開発には必要なレイヤになる。 -従って、以下は、二者択一になる。 --恐れて何もしないか？ --大規模化した時に、維持・保守できないものにするか？ *STPのSTぐらいは考えよう。 [#obb9fb87] 開発技術、開発支援ツール選定をする上で、[[STPマーケティング>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?STP%E3%83%9E%E3%83%BC%E3%82%B1%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0]]の -セグメンテーション（segmentation、セグメント化） -ターゲティング（targeting、ターゲット選定） -ポジショニング（positioning、ポジションの明確化） ST（セグメンテーション・ターゲティング）ぐらいは考えたほうが良い。~ ※ STPマーケティングはマーケティング用語 **例 [#ge8ac874] -例えば、[[前述の「HTML/CSS/JavaScript」は>#ae5ae778]]、~ HTMLを修飾したり、Googleの広告系の処理を埋め込んだりと、~ そのような用途に最適化されているプログラム言語なので、~ UI、業務処理開発と汎用的に適合するか？と言えばそうではない。 --https://twitter.com/mizchi/status/957851145531043840 --そもそも、汎用的であれば「[[AltJS>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?JavaScript#d11cd6c3]]」は登場していないものと思われる。 -特にエンタープライズ分野では、このような問題が解決され、~ 成熟したタイミングで、やっと利用できるようになることが多い。 *参考 [#md49fd9e] **[[開発支援ツールの種類]] [#x05f3b2a] **[[開発支援ツールの自動生成方式]] [#f2cb790e] **[[VS系コンテンツ]] [#o277ca15] **[[開発基盤のKPIとKGI>https://opentouryo.osscons.jp/index.php?%E9%96%8B%E7%99%BA%E5%9F%BA%E7%9B%A4%E3%81%AEKPI%E3%81%A8KGI]]（Open 棟梁 Wiki） [#n213c992] **その他 [#w76b0ec4] ***開発支援ツールとは？ [#xba64325] そもそも、開発支援ツールとは？ -開発支援ツールとは？ その種類と特徴を、まめてみした。 - OSSコンソーシアム~ https://www.osscons.jp/jowaxn8yr-537/#_537 ***開発基盤の必要性 [#n8ffdb60] スクラッチが良い場合と悪い場合があり、 -超高速な開発ができるわけ | Yakst~ https://yakst.com/ja/posts/4668 実験的プロトタイプ、本番アプリケーションを区別することが重要である模様。~ ※ 冒頭にあるように「開発者の話ではなく、状況（前提条件）が大きなカギ」らしい。 ***導入時の考慮点 [#r9c3e3ec] -Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita~ https://qiita.com/tmknom/items/08b69594e32a92bccee5 ---- Tags: [[:.NET開発]], [[:ツール類]]
