前回の「クラウドR&D:R&Dはコード」の記事では、ソフトウェアエンジニアリングのコード化された閉ループを紹介しました。同時に、「水:クラウドR&Dアーキテクチャモード」では、このような開発環境の設計に必要なパターンのいくつかを紹介しました。本日は、一連の着陸プラクティスとして、クラウドR&D IDEの設計アイデアとその実装方法を紹介します。もちろん、初期のコードが少しあります:https://github.com/inherd/uncode。
最初のステートメント:これは概念的なIDE設計であり、当面はどの実稼働環境にも適していません。
読み始める前に、すべての人に理解を深めるために、ソフトウェアエンジニアリング業界を確認する必要があります。
DevOpsの概念は、国内のソフトウェア業界でかなりの進歩を遂げ、従来の企業(銀行、製造)を含む企業に広く受け入れられ、広く推進されてきました。
クラウドネイティブテクノロジーは、市場の主流のトレンドになっています。クラウドへの移行とレガシーシステムのクラウドへの移行は、市場でホットなトピックです。
中国と台湾の方法論は、実際にはまだ実際の成功事例を欠いています。
ローコード/ノーコードプラットフォームは、徐々に新しい構築目標になっています。
クラウド開発には、ますます中小規模のアプリケーションケースがあります。
AIコード生成は小規模で検証されています。
業界全体の観点から、人々の焦点は常に技術的生産性を向上させる方法でしたか? 現在、テクノロジーは新しい段階に達しており、要件の変換によって人々の開発速度が大幅に制限されています。そのため、DevOpsとクラウド開発がどれほどうまく実装されていても、需要とテクノロジーの分離のボトルネックに陥ります。これが、クラウドの研究開発理論システムが必要な理由です:)コーディング方法を通じて、需要、設計、そしてコーディングの問題に対するワンストップソリューション。
クラウドの研究開発理論については、理論的基盤、ソフトウェアアーキテクチャ、開発モデルを設計し、ドキュメントコーディング、要件コーディング、コードコーディングなどの一連のことを検証しました。
これらのコンテンツ、パターン、コードを統合するためのコンテナーが必要です。これは、概念的なクラウド開発IDEであるUncodeです。
クラウド開発IDE、Uncode
Uncodeは、クラウドの研究開発の時代のために設計された次世代の概念的なIDEです。特性:
プロセスはドメイン言語に変換されます。コードとして処理する
すべてがDSLです。すべてのコーディング
開発環境はプロセスです。
簡単に言うと、このIDEで実行できます。要件の記述、要件の設計への変換、関連するコードの設計、Zenモードでのプログラミング、開発後のオンライン化です。
対照的に、従来のワンストップDevOpsポータルは、ジャンプして完了することはできますが、相互接続して設計することはできません。これは、アプリケーションシステムの宣言型インフラストラクチャとアプリケーションをGitリポジトリに格納するGitOpsに似ています。しかし、それらは閉ループでも完全でもありません。
クラウドR&D IDEモデル:プロセスはドメインの言語です
ソフトウェア開発に戻ると、私たちのソフトウェア開発のニーズは、大きな機能または壮大なストーリーから始まります。これらのストーリーはfeature
、Cucumberのように1つに変換されます 。
# author: Phodal HUANG
# status: doing
# language: zh-CN
功能: 第一个用户故事
场景打开 Uncode
假如我在 Terminal 工具里
当输入 uncode
那么则能在 Uncode IDE 里打开当前项目
このステップの前に、要件設計者は要件をストーリーに変換し、ストーリーと機能の関係がこれに記録されます feature
。開発者はIDEから要件を確認し、対応するステータスをマークしてから status
、コード設計フェーズに入ります。
設計段階では、我々が最初に設計された design
3種類の: flow
、、 model
、 ui
フローの設計、モデルの設計とUI設計に対応します。Uncodeで実装したい部分は、要件をモデル、フロー、およびUIにバインドすることです。モデルの周りで、関連するインターフェースと設計を自動化するために、統一されたドメイン言語を構築する必要があります。モードに関しては、これはノーコード/ローコード開発に似ています。
唯一の違いは説明です。ドメイン固有言語を使用してコンテンツを記述することによってのみ、システムを合理的に再構築できます。
クラウドR&D IDEモデル:すべてがファイルである
Linux / Unixのコア哲学は、「すべてがファイルである」です。
今日の開発環境では、かんばんボードでカードを選択するか、ローコードエディタでカードを生成します。使用されるストレージメディアはすべてデータベースです。データベースは開発環境には存在しませんが、リモートサーバーに配置されます。これにより、関連付けを単純に元に戻すことができない、要件とコードを分離できないなど、別の問題が発生します。
したがって、クラウド開発IDEの2番目のモードとして、すべてのコンテンツはファイルに保存され、バージョン管理ツール(Gitなど)によって管理されます。要件がコードのような状況でデータベースに保存されている場合、次の機能を実現できます。
「偽造不可能」
「ずっと痕跡を残して」
「追跡可能」
「オープンで透明」
「一括メンテナンス」
はい、これはブロックチェーンシステムです。需要が変化すると、すぐにそれを認識することができます。ただし、コードがモデルに準拠していない場合、コードを送信できないか、モデルが自動的に変更されます:(。
クラウドR&D IDEモデル:開発環境はプロセスです
統合開発環境として、既存 のワンストップDevOpsソフトウェアR&D管理コラボレーションプラットフォーム は、管理と表示の目的でのみ使用する必要があります。デザイン自体に関しては、ダッシュボードとオープンソースツールには独自の分業があります。
コードベースに要件がある場合は、IDEを使用できます。
かんばんの形でローカルで需要を再視覚化します。
デザインフィールドの言語をローカルで視覚化し、コードに関連付けます。
変更が必要なすべてのコードブロックを強調表示します。コントローラ、ビューなど。
モデルの変更を設計に逆相関させて、設計の正確さをリアルタイムで追跡します。
開発者の変更の範囲を制限するなど、それほど正しくないこともできます。
クラウドR&D IDEモード:空欄を埋める/選択的なプログラミング
ソフトウェアアーキテクトにとって、人々はしばしばそのような問題点を抱えています。
経験の浅い開発者に直面して、システムの開発を迅速に促進することは困難です。
開発者はシステムを理解しておらず、間違った場所で間違ったコードを変更しています。
したがって、TypeFlowの観点に戻ると、モデルを設計し、入力と出力を設計したので、中間メソッドとその戻り値を生成し、そのモックオブジェクトを設計できる必要があります。といった:
@RequestMapping("/")
String home() {
return "Hello, World!"
}
このモデルは、ビジネスアプリケーション開発に非常に簡単に実装できます。バインディングプロセスなどでさまざまな機能を生成します。
選択的プログラミング。組織内のすべてのコードにインデックスが付けられると、入力と出力、および対応するメソッド名を識別し、IDEで対応するメソッドを選択できるようになります。
クラウドR&DIDEの基本要素
このように見てください。IDEのことをうまくやる必要があります。ただし、これは当てはまりません。まだやらなければならないことがいくつかあります。
開発は展開です。つまり、ローカルdevは、既存のシステムに直接接続できる開発サーバーです。
すべてがDSLです。ある程度のプログラミング言語設計能力を持っている。
APIAPI。つまり、既存の内部APIと外部APIが抽象化され、高速で使用可能なAPIを提供するように設計されます。
開発はデプロイメントです-クラウド開発環境
開発の観点からは、ローカル環境とオンライン開発環境を何度も無駄にしてきましたが、同時に、対応するテスト実行時間、ビルド時間などがあります。クラウド開発環境にはメカニズムが必要です。
共同デバッグとテストのプロセスをスピードアップします。ローカル環境がクラウド上にある場合、他のシステムとのインターフェースが必要になると、すべての開発とテストの効率が大幅に向上します。たとえば、インターフェースはもう1つのパラメーターを提供する必要があります。従来のモードの後、ローカルで実行してから、パイプラインを介してビルドおよびデプロイする必要があります。これで、このプロセスは不要になり、ゲートウェイを構成するだけで、簡単に開発できます。
環境構築をスピードアップします。開発環境をローカルで構成する必要はなくなりました。ワンクリックするだけで、ローカルIDEで直接デバッグできます。
市場にはすでに必要最低限の概念があります:Nocalhost
抽象抽象化:DSL
要件の抽象化、設計、開発、テストなどは、昨年の私の研究の焦点でした。これには以下が含まれます。
需要の抽象化
抽象としてのデザイン
-
アーキテクチャ記述言語
統一モデリング言語
バージョン管理の抽象化
ビルドツールの抽象化
この一連の手順は、ドメイン固有言語に変換されます。プロセス、ツール、および動作を抽象化することによってのみ、システム全体を最適化できます。
接着剤の設計:API API
ソフトウェア開発は複雑なチーム活動です。システムでは、多数の内部システムと外部システムを関連付ける必要があります。開発者の負担を軽減するために、既存のAPIをカプセル化する新しいAPIを提供する必要があります。
たとえば、既存のモードでは、ログを記録するために、依存関係管理ツールに対応する依存関係を導入してから、対応するコードを追加する必要があります。すべてのAPIが更新されており、このシリーズはIDE自体で完了する必要があります。このモードでは、snippets
この一連の自動化されたプロセス操作を完了するために、対応するものを入力するだけで済みます 。
技術的な詳細
最後に、コードに戻ります:https://github.com/inherd/uncode/
建築デザイン
UncodeIDEのアーキテクチャを示すために設計した新しいアーキテクチャ設計ルーチンを使用することにしました。不確実性が大きいため、既存のシステムは、モノリシックとマイクロアーキテクチャ+モジュール化の間の方法で設計されています。私はそれについて考え、流体モードと呼びました。継続的な進化の過程で建築単位を予期せず分割するモード。
運転モードでは、次の4つのモードで構成されます。
モジュール性。
管理とフィルター。主にドメイン固有言語を設計するため
パートナーモード(サイドカー)。言語分析などの言語をプロセスに分離し、プロセス呼び出しを通じてクロスプラットフォームを実装します
コンテナブリッジ。UIプレゼンテーションをロジックから分離し、IDEのほとんどのコンポーネントがUIとは関係がないようにします。
同時に、システムの物理設計では、ドメイン駆動型のアプローチを採用する予定です。
フレームの選択
これが低レベルの開発+システムプログラミングであることを考えると、次のようになります。
Rustを主要な開発言語として使用する
UI表示で、一時的にTauri(WebViewコンテナー)+ Reactを使用して、要件(ローカルかんばん)と設計(モデリングなど)を表示します。
UI開発言語の一部としてTypeScriptを使用する
複数のDSLとの通信プロトコルとしてRPCを使用する
……
それでも、このプロジェクトは引き続きInherdチームで開発されます~~。
FAQなど
コード:https://github.com/inherd/uncode/
vs IntellijIDEAまたはVSCode / Theia
これは完全に競争的な関係ではなく、コーディングのこの部分の機能はさらに人気があります。Uncodeは、初期段階ではこの領域にホイールを作成しませんが、明示的に統合するか、統合します。
Uncodeは、DevOpsのローカリゼーションに優先順位を付け、それを開発プロセスに統合します。
その他
最後にもう1つ、これは概念的なIDE設計であり、当面は本番環境には適していません。Cloud Research andDevelopmentのWeChatセミナーグループへようこそ。