![[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]]にまとめた。 ※ 下記の理屈は、今後のインフラ界隈（IaaC）にも適用できる可能性がある。~ （恐らく、DSL系のツールは、不要なのではないか？と予想している） *トレンド [#qedb1c0c] 開発支援ツールには、昨今、以下のようなトレンドがある。 **世界的には、 [#q4573886] ITビッグ 5（ Microsoft, Apple, Amazon, Oracle, etc. ）など~ がリリースする開発ツールの殆どは以下の特性を持っている。 -[[IDE>開発支援ツールの種類#b818d91a]]であり、柔軟性と汎用性が非常に高い。 -[[設計情報（デザイナ操作、スキーマ定義）型の自動生成方式>開発支援ツールの自動生成方式#fe4a7148]]が採用されている。 [[IDE>開発支援ツールの種類#b818d91a]]周辺の動向を見ると、自社のプラットフォームを利用させるための~ [[IDE>開発支援ツールの種類#b818d91a]]を中心とした言語・ライブラリ・開発ツールのエコシステムに、~ 非常に大きな投資を行い、大きな投資対効果を期待していることが解る。 **日式SIer的には、 [#n91ce970] -その一方、日本のSI事業者では、~ 「業務システム開発」の作業を単純作業化する志向が強い。 -そのため、「業務システム開発」に特化した、 --標準化 --共通化 --自動生成 ---[[リポジトリから自動生成>開発支援ツールの自動生成方式#ed279100]] ---[[（Excelなど）設計書型から自動生成>開発支援ツールの自動生成方式#fe4a7148]] >を行うためのツールが多数開発されてきた。 -しかし、多様化の時代に、これらのツールは衰退の一途を辿っている。 --これらのツールは柔軟性と汎用性が低く、多様化するアーキテクチャに追随できない。 --多様化の時代、エンジニアの価値は右肩上がりだが、~ 自身の価値を高めないツールをエンジニアが積極的に習得しない。 **その他、 [#xc2f3a64] ***[[EUC、RADツール>開発支援ツールの種類#fb3f61c9]] [#p5cb4d9f] -様々なツールの開発が継続されているが、強力な[[IDE>開発支援ツールの種類#b818d91a]]との競争に晒されている。 -どちらも[[IDE>開発支援ツールの種類#b818d91a]]より柔軟性が低いので、要求仕様に応えられないケースがある。~ 従って、UXを重視したり仕様をコントロールできない案件では問題になり易い。 ***テンプレート & 最小限のライブラリ [#o75389df] -上記を鑑みると、ドメインに特化した開発効率の向上施策は、~ [[IDE>開発支援ツールの種類#b818d91a]]ベースのテンプレート & 最小限のライブラリが最善と解る。 -[[Open棟梁>http://opentouryo.osscons.jp/]]は、初期からこの設計思想で開発されている。 -TERASORUNAは、v5.0からこの方式に変わっているもよう。~ ※ TERASORUNAでは、テンプレートをブランク・プロジェクト呼んでいる。 -ただし、これらの独自開発部分は、以下に影響を受ける。 --独自開発部分は、対象規模が大きくなると、SI事業の商習慣上、逆に薄くなる傾向がある。~ （ビッグ・アカウントの場合、力関係でフル・スクラッチを強要されるケースがあるため） --また、下位スタックの安定性に影響を受ける。~ （[[Windows Forms]]や[[ASP.NET Web Forms]]の安定性は非常に高いが、~ 昨今のJSのMV*など、安定が非常に低いフレームワークの上では維持できない。） -参考 --Javaエンジニアに知ってほしい、Springの教科書「TERASOLUNA」 #jjug_ccc #ccc_f3~ https://www.slideshare.net/jjug/javaspringterasoluna-jjugccc-cccf3 *その他 [#h9d29cde] **UIサブシステム [#ae5ae778] -UIサブシステムは、基本的に、 --プラットフォームに組み込まれており、 --また、[[IDE>開発支援ツールの種類#b818d91a]]とフレームワークが提供されているため、 >「[[Windows Forms]]」や「[[WPF]]」など、その開発が容易にできるようになっている。 -しかし、「HTML/CSS/JavaScript」は下位スタックの進化が著しく、~ （これは、「HTML/CSS/JavaScript」が、テキスト修飾・閲覧のための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の状態で開発されていたら、 ---≒ Fx生のAPIを触る為、レイヤ分割を避けている。 ---≒ モジュール強度が強く、結合度が弱くなる境界で分割されていない。 >標準化・共通化などによるコントロールが必要になった時点で、対応できなくなる。 **オレオレ・フレームワーク [#v8ef209c] -明確な定義は無いが、 --案件レベルで作成した、 --質の低い独自実装 >全般を指すモノと思われる。 -しかし、（[[上記>#gbdb10f2]]の）Dryを脱却した後に、~ 案件レベルで追加するレイヤは、きっとオレオレ・フレームワークになる。~ （従って、殆どの開発者はオレオレ・フレームワークを開発していることになる） -従って、以下は、二者択一です。 --恐れて何もしないか？ --大規模化した時に、維持・保守できないものにするか？ *STPのST [#obb9fb87] -開発技術、開発支援ツール選定をする上で、STPマーケティングの --セグメンテーション（segmentation、セグメント化） --ターゲティング（targeting、ターゲット選定） --ポジショニング（positioning、ポジションの明確化） >STぐらいは考えたほうが良い。~ （STPマーケティングはマーケティング用語） -例えば、[[前述の「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] **開発基盤の必要性 [#n8ffdb60] スクラッチが良い場合と悪い場合があり、 -超高速な開発ができるわけ | Yakst~ https://yakst.com/ja/posts/4668 実験的プロトタイプ、本番アプリケーションを区別することが重要である模様。~ ※ 冒頭にあるように「開発者の話ではなく、状況（前提条件）が大きなカギ」らしい。 ---- Tags: [[:.NET開発]], [[:ツール類]]
