はじめに: AI ローコード開発は、プロセス指向やオブジェクト指向に続く新しい抽象概念であるだけでなく、ウォーターフォール開発やアジャイル開発に続く新しい開発手法でもあります。
50年前のソフトウェア危機
コンピュータ技術の初期段階であり、オペレーティングシステム、データベース、インターネット基盤プロトコルなどのソフトウェアのインフラが確立されつつあり、ソフトウェアは単純なものから複雑なものへと変化しつつあります。ソフトウェア開発が制御不能になると、それはタールの穴に落ちるようなものであることに人々は気づきますが、どれだけの人的資源と物的リソースを投資しても、それを変えるのは難しく、人や月は関係ありません。ソフトウェア開発のコストと時間は無限に増大し、品質を保証することは困難です。
1970 年にウィンストン ロイスが有名な「ウォーターフォール モデル」を提案しました。その中心的な考え方は、プロセスに従って問題を単純化し、機能の実現を設計から分離し、分業と協力を促進することです。物理的な実装は分離されています。 。ソフトウェアのライフサイクルを、計画、要件分析、ソフトウェア設計、プログラミング、ソフトウェアテスト、運用保守の6つの基本的な活動に分割し、上から下への一定の順序を規定し、滝のように相互につながり、段階的に行き着く。
ウォーターフォール モデルは、明確な段階と所定のドキュメントを通じてソフトウェア開発をより予測可能かつ秩序立ったものにすることを目的としており、要件が頻繁に変更されない大規模で高度に統合されたソフトウェア開発プロジェクトに非常に適しています。1980 年代初頭までは、これが広く採用されていたソフトウェア開発モデルでした。
20年前のソフトウェア危機
インターネットの台頭により、ソフトウェアは生活のあらゆる側面に影響を及ぼし始めています。ソフトウェアはすべてを定義しています。情報化に対する人々の需要が爆発的に増え始めています。プログラマーとさまざまなユーザー シナリオとの間の最初の衝突が始まりました。要件の曖昧さと不変の要件この変更により、従来のウォーターフォール開発モデルはソフトウェア開発の進行を著しく制限し、ソフトウェア開発コストに影響を及ぼします。
2001 年 2 月、Martin Fowler 氏、Jim Highsmith 氏、その他 17 人の著名なソフトウェア開発専門家が米国ユタ州のスノーバード スキー リゾートに集まり、アジャイル手法の発案者と実践者の集まりを開催しました。この会合でアジャイル（機敏な開発）の概念を正式に提案し、「アジャイル宣言」に共同署名した。
エクストリーム プログラミング (XP) とスクラムは、アジャイル開発プラクティスの 2 つの異なる流派を表します。スクラムは、一連のプラクティスと、プロジェクト リーダー、製品所有者、スプリントを通じて各タスクを完了する開発チームなどの事前定義された役割を含むプロセス スケルトンです。1 回のイテレーション、各増分が生成され、各目標が達成されました。エクストリーム プログラミングは、オンサイトの顧客、コード規律、週 40 時間労働、ゲームの計画、システム メタファー、シンプルな設計、テスト駆動開発、リファクタリング、コードの集団所有権、継続的インテグレーション、小規模リリース、ペアなど、特定のエンジニアリングの実践に重点を置いています。プログラミングを待っています。
アジャイル開発の具体的な実践では、さまざまなジャンル間の厳密な区別はなく、さまざまな程度の統合が行われることがよくあります。アジャイル開発はウォーターフォール開発を放棄するのではなく、それに基づいてプロセスを最適化するものであり、ウォーターフォールモデルはより短い時間次元で反映されます。したがって、今日に至るまで、アジャイル開発は依然としてソフトウェア開発の主流モデルです。
今日のソフトウェア危機
ソフトウェアは生活のあらゆる側面に組み込まれており、ほとんどのシーンが情報化され、ソフトウェアが世界を再構築していると言えますが、特にモバイルインターネット、インターネットなど、新しい技術の開発は依然として盛んです。データ、クラウドネイティブ、人工知能などのテクノロジーの発展に伴い、情報システムに対する人々の需要は依然として爆発的に増加していますが、IT 分野の最大の矛盾は、依然としてソフトウェア開発が人々の増大するデジタルニーズに応えられないことです。その過程で危機も常に蓄積していく。
まず、アジャイル開発はますます多くの問題を引き起こします。
アジャイル開発は大きな成果を上げており、多くのソフトウェア チームがアジャイルのアイデアに従ってアジャイルを実践していますが、アジャイル開発は万能薬ではなく、アジャイル開発がもたらす問題はますます明らかになってきています。例えば、必要なドキュメントを正確に定義してプロダクト全体の整合性を把握するのが難しい、プロジェクトの終点を判断し効果的に見積もるのが難しい、専門のプログラマーに頼りすぎる、などです。
第二に、技術の更新がますます速くなっています。
モバイル インターネットの人気は、テクノロジーの発展を促進する上で大きな役割を果たしてきました。際限のないフロントエンド テクノロジー、Android および IOS アプリ開発、Web フロントエンド フレームワーク React、Vue など、データ量の急速な増加により、バックエンド サービスは単一のアーキテクチャからマイクロサービス フレームワークに変化し、さまざまなサポート ディストリビューションや同時実行性の高いデータベース システムやミドルウェアがあり、モノのインターネットや人工知能のアプリケーションが人気であり、Python や Go などの複数言語のアプリケーションがますます広範囲になっています。したがって、プログラマーの要件は、適切なテクノロジー スタックを迅速に学習できることだけでなく、テクノロジーの最前線での変化を追跡できることでもあります。
第三に、顧客のソフトウェアに対する要求はますます高まっています。
ソフトウェアユーザーの継続的な増加に伴い、従来の情報管理システムはますますインターネットベースになり、ユーザーが増えただけでなく、ビジネスプロセスもより複雑になりました。人々はスマートフォンを通じて生活のニーズを満たすだけでなく、政府、医療、教育、出勤、オフィスなどのほとんどの取引業務を完了することができます。いくつかの効率的で強力な ToC ソフトウェア アプリケーションによるユーザーの教育により、ユーザーはインタラクティブなエクスペリエンスの点で ToB ソフトウェアに対する要求が高くなります。
第四に、研究開発チームはますます制御不能になってきています。
現在、ソフトウェア開発の組織部門は、フロントエンド、バックエンド、UIデザイン、プロダクトマネージャー、プロジェクトマネージャーなど、ますます細分化されています。このモデルは、ビジネスロジックが比較的単純なインターネットソフトウェアの開発には有効ですが、ビジネスが複雑化するにつれてドメイン知識を必要とする情報管理ソフトウェアでは問題が発生し始めます。フロントエンドとバックエンドの分離により莫大なコミュニケーションコストが発生し、プロフェッショナリズムと開発の両方を理解するプロダクトマネージャーはほとんど存在しません。フルスタックエンジニアの不足によりソフトウェアアーキテクチャはますます弱体化し、人材の流動性により、コードの保守がより困難になります。したがって、ソフトウェア開発では、ますます制御不能になっている状況を解決するための新しい組織的手法が緊急に必要とされています。
5 番目に、プログラマはますます混乱しています。
IT テクノロジーの急速な発展により、多くの若者がソフトウェア業界に参入するようになりました。ソフトウェア開発は知識集約的な仕事であり、プログラマーの能力には大きなばらつきがあります。多くのプログラマーはソフトウェア開発の境界という概念を持っていませんが、インターネットソフトウェア開発、情報管理システム開発、プロフェッショナルソフトウェアでは技術スタックや開発手法が異なります。多くのプログラマーはインターネット開発技術を多く学んでいますが、情報管理システムの開発にしか携わることができず、多くの混乱を引き起こしています。よく知られている35歳現象もあります。効果的なキャリア計画の欠如は、ますます多くのプログラマーが直面する問題となっています。
革新的な新技術
2014 年には IT コンサルティング会社 Forrester が最初にローコードの概念を提案しましたが、2019 年までに別の有名な IT コンサルティング会社である Gartner がローコード開発のより詳細な定義を作成し、広く注目を集めました。
LCAP (ロー コード開発プラットフォーム) は、迅速なアプリケーション開発をサポートし、アプリケーション宣言型および高レベル プログラミング抽象化 (モデル駆動型およびメタデータ ベースのプログラミング言語など) のワンストップの展開、実行、管理を使用するアプリケーション プラットフォームです。従来のアプリケーション プラットフォームとは異なり、ユーザー インターフェイス、ビジネス ロジック、データ サービスの開発をサポートしますが、クロスプラットフォームの移植性とアプリケーションのオープン性を犠牲にして効率を向上させます。
この定義から、ローコードの核となる価値は、ビジネス アプリケーションの迅速な配信を実現し、より抽象度の高いプラットフォーム ツールを使用することでソフトウェア開発を高速化することであることがわかります。Gartner はローコードの具体的な実装を指定していませんが、構成戦略を使用したコード入力の削減と視覚的なドラッグ アンド ドロップは実装の 1 つにすぎません。
ローコードがソフトウェア開発の改革への道を示すのであれば、AIGC はより強力な手段を提供します。2022 年 11 月、OpenAI は人工知能技術による自然言語処理ツール ChatGPT をリリースしました。これは、人間の言語を理解して学習することで会話を行い、チャットのコンテキストに応じて対話することができ、真に人間のコミュニケーションのようにチャットし、さらには完全なコミュニケーションを実現します。電子メールの作成、ビデオの脚本、マーケティングのコピーライティング、翻訳、論文などのタスク。プログラミングの面でも、その優れたコード生成能力はプログラマーを驚かせます。すでに 2021 年 6 月には、Microsoft と OpenAI が AI プログラミング ツールである GitHub Copilot を共同で立ち上げました。そのコア モデルは、ドキュメント、コメント、関数名、テスト コードなど、GPT の生成機能を利用してより広範囲のコンテキストを理解できます。コード自体であっても、マッチングのためのコンテキストに応じて新しいコードを合成することができ、その効率的な補助プログラミング機能により、ペアプログラミングの仮想版と呼ばれます。最新の Github Copilot X は、開発者が入力したコードの内容を認識し、エラー メッセージを表示するだけでなく、コード ブロックの目的を分析して説明し、単体テストを生成し、デバッグの提案を提供し、音声でプログラマーと対話することもできます。
CSDN の創設者である Jiang Tao 氏は最近の講演で、AI プログラミングは無人運転にヒントを得た 5 つのレベル C1、C2、C3、C4、C5 に分かれていると述べました。ここで C4 と C5 を少し修正します。プログラムの開発は、どの程度の参加が関与するかに関係なく、人の役割を離れることはまだ難しいはずです。
C1 レベルでは、入力メソッドと同様に、行を入力するとプロンプトが自動的に完成します。
C2 レベルは、プログラマがコード行の入力を終了した後に次のコードを予測します。
C3 レベル。完全な関数コードを生成でき、コードの一部に基づいてコードを生成できます。
C4 レベル。プログラマーの要件に従って完全なモジュールを生成し、異なるプログラミング言語の相互翻訳を完了できます。
レベル C5 は、プログラマーからの限られたヒントを使用して完全なプロジェクトを生成します。
テストによると、ChatGPT は少なくとも C3 レベルに達しており、最新の GPT-4 は C4 レベルの作業の一部を完了することもできます。C1 から C5 まで、これは実際にはコード補完機能の継続的な強化であることがわかります。プログラマーにとって、コードはそれを実装するための最も効率的かつ柔軟な方法です。コード補完は、コード記述の柔軟な制御です。
実際のソフトウェア開発では、同じビジネスシナリオに対して無数の実装方法が存在することが多く、どれが最適であるかを判断することは困難ですが、必要なのは明確で読みやすく、検証可能な実装方法です。 C5レベルでは、AIが自由に生成したコードだけに頼るだけでは不十分で、オープン性を犠牲にして確実性を高めるローコードの概念、すなわちローコードの制限機能が必要となります。さらに、AI コード生成はプロンプト ワードの能力にも依存しており、適切に表現されたプロンプト ワードには専門分野の知識が必要であり、これはローコードにおける高レベルの抽象化に相当します。
ソフトウェア開発はコードを書くだけではなく、ソフトウェア開発サイクルには要件分析、プロセスモデリング、アーキテクチャ設計、詳細設計、テストなどの複数のプロセスが含まれます。ChatGPT があらゆるプロセス リンクを支援できるようになることが予見可能であり、新しいテクノロジーによってもたらされる変化には疑いの余地がありません。プログラマーのキャリアはAIGCによって3年以内に打ち切られるだろうと示唆する人もいた。少し極端ですが、プログラマーは辞められないと思いますが、時代に乗れずAIプログラミングツールを使うプログラマーは辞められると思います。
AI ローコード開発マニフェスト
技術開発のこの特異点において、私たちはアジャイルマニフェストと比較して、新しいソフトウェアエンジニアリングのアイデアであるローコード開発マニフェストを提案し、ソフトウェアプログラミングの分野における次の開発を導き、分析しようとします。右の項目にも価値がありますが、私たちは左の項目の価値にもっと注目します。
1. コンポーネントとモデルは個人よりも上位にあり、インタラクションはプロセスやツールよりも上位にあります
ウォーターフォール開発では、開発計画の効果的な実装を保証するために、厳密なプロセスと設計ツールを通じてソフトウェア開発プロセスが定義されます。アジャイル開発では、個人と相互作用が人々の役割を強調し、さまざまな参加者間のスキルとコミュニケーションを使用して開発要件の変化に対応します。
長年にわたるソフトウェア開発の蓄積により、多くのビジネス シナリオにはすでに成熟したドメイン モデルと運用手順があり、さまざまな粒度のコンポーネントを通じて新しいビジネスを迅速に構築できます。もう少し大きなソフトウェア会社も、独自の開発モデルやフレームワークシステムを形成するようになるため、一度ローコードの概念が提案されると、ローコードまたはノーコードのプラットフォームが際限なく登場します。
AI ビッグ言語モデルを通じて、シーンをより適切に分解し、ドメイン モデルの確立とコンポーネントの構築をガイドできます。ソフトウェア開発の基本要素としてコンポーネントとモデルが存在し、さまざまな開発フレームワークやコンポーネントシステムは、シナリオや設計パターンの違いにより独自の特徴を持っています。コンポーネントやフレームワークを蓄積することで開発効率は向上しますが、AIの大型モデルと効果的に連携するにはどのようなコンポーネントやモデルを構築できるかが問題の鍵となります。
2. 詳細なドキュメントよりも、動作するソフトウェアよりも読みやすいコード
ドキュメントは、ウォーターフォール開発における重要なマイルストーン成果です。アジャイル開発では、要件の変化により、ソフトウェア開発プロセスを継続的に反復し、ユーザーと継続的にコミュニケーションする必要があります。これには、ソフトウェア コードを迅速かつ効果的に継続的に変更できることが必要であり、各反復で実行可能なソフトウェアが生成されます。
ただし、このプロセスではドキュメントは常に弱体化され、最終的にはドキュメントがコードから完全に切り離されてしまいます。ドキュメントに関するもう 1 つの興味深いコンセンサスは、プログラマはドキュメントを書くことを最も嫌っており、他の人がドキュメントを書かないことも嫌いだということです。また、頻繁に変更されるコードの場合、コードの保守性も低下の一途をたどっており、プログラマーにとって最も理解しやすいコードは、作成したばかりのコードであり、最も難しいコードは、1 年前に作成したコードです。 . メンバーは定数ループで常にクラッシュします。
したがって、コードの可読性を向上させることは、ソフトウェア開発の継続的な反復を解決する最善の方法であり、バグを減らす効果的な方法でもあります。コードの可読性の向上は 3 つの側面から開始できます。1 つ目は名前付けであり、明確で正確な名前付けによりコードの可読性が大幅に向上します。2 つ目は、コードのコメントだけでなくコードのドキュメント化により、一貫性のある完全なドキュメント化が可能になり、プログラマーがコードをより迅速に理解できるようになります。最後は優れた設計です。優れた設計ではコードが簡素化され、コードでセルフコメント機能を生成できるようになります。これらの問題にも AI ラージ モデルを使用できます。AI ラージ モデルは、コードの品質をチェックしてより良い設計方法を提供できる一方で、コード フラグメントを自動的に生成することもできます。品質要件を満たします。プログラマーは疑似コードを直接使用してプログラミングすることもできるため、コードの可読性が大幅に向上します。
3. 顧客の成功は、契約交渉よりも顧客の協力よりも高い
ウォーターフォール開発では、ソフトウェアの機能範囲を決定する必要があるため、最初に契約交渉が行われ、一度契約を締結するとソフトウェアの要件は変更されません。アジャイル開発では、ユーザーが開発前に欲しいソフトウェアを正確に記述することができないため、最終的に望ましい効果を達成するために、開発プロセス中に顧客と協力し、継続的に反復する必要があります。
現在、ソフトウェア開発は、業界のベスト プラクティスを設計するために多くのシナリオで十分な経験を蓄積しているため、SaaS が成熟したモデルとして広く採用されています。ユーザーは開発に全面的に参加する必要がないため、ソフトウェアの配信が重要なタスクになっています。カスタマーサクセスは 3 つのレベルに分類できます。1 つ目は、顧客がソフトウェアを適切に使用すること、2 つ目は、ソフトウェアが顧客にとって真の価値を生み出すことができること、3 つ目は、顧客の継続的な発展をフォローし、顧客の満足度を保証する能力です。競争上の優位性。
ただし、SaaS モデルは、ユーザー向けのカスタム開発が行われないことを意味するものではありません。実際、管理ソフトウェアは経営思考を体現したものであり、管理思考の違いが企業を区別します。顧客に合わせてカスタマイズする方法は、SaaS ソフトウェアにとっての課題であり、AI ローコード開発の機会でもあります。AI ローコードによるカスタマイズ開発が十分に簡単である場合、SaaS の標準化が依然として有効かどうかという明らかな疑問があります。ローコード開発では、テクノロジーの実装の詳細に焦点を当てるのではなく、合理的なコンポーネントとモデルを使用して、AI の指導の下でソフトウェアを迅速に実装するプログラマー、ビジネス プログラマーの新しい部門が存在する可能性があります。顧客アプリケーションにおけるソフトウェア システムの継続的な成功を保証します。
4. 変化を予測することは、変化に対応することよりも高く、計画に従うことよりも高い
ウォーターフォール開発では、契約が締結されると、計画に従って段階的に開発が進められます。アジャイル開発では、ユーザーと継続的に対話するため、要件の変化に継続的に対応する必要がありますが、ユーザーの変更の妥当性は次の対話まで判断できず、不合理であれば頻繁に手戻りが発生します。
したがって、ユーザーのニーズを深く理解し、変化を予測することが非常に重要です。プログラマにとって、ユーザーの長年の実務経験を理解するのに数か月かかることはよくありますが、多くの概念は表面的には一貫しているだけで、深いビジネス ロジックを理解するのが難しく、システムがユーザーの要求と一致しないことがよくあります。要件を深く理解するには、より専門的なドメインの専門家の参加が必要ですが、AI ローコード開発では、大規模言語モデルのスーパーパワーがドメインの専門家として機能し、プログラマーのユーザー ニーズの理解を強化できます。
ユーザーの変化に対応するもう 1 つの機能は、システムに AI を組み込んで、ソフトウェアを本質的に予測できるようにすることです。AI を通じて、ユーザーはプログラム インターフェイスの限られた対話や表示に制限されるのではなく、ソフトウェアをより柔軟に使用できるようになります。同時に、大規模モデルの膨大な知識と推論能力を利用して顧客のビジネスを分析および予測することは、既存のソフトウェア システムにとって革命的な変化となります。
AI ローコード開発原則
ローコード開発の原則は、アジャイル開発の原則にも対応しており、プロジェクトの実施、コミュニケーションと協力、プロジェクトの実施、継続的改善の 4 つの側面から説明されています。AI ローコード開発では、開発者はツールを使用し、ユーザーにサービスを提供するだけでなく、ビジネス シナリオを深く掘り下げてユーザーの立場に立って考えるため、それに応じて戦略や考え方も変化してきました。
配信プロジェクト
① アジャイル開発：私たちの最も重要な目標は、価値のあるソフトウェアを早期に継続的に提供することで顧客に満足していただくことです。
① AI ローコード開発:私たちの最も重要な目標は、価値のあるソフトウェアを迅速に提供し、顧客を満足させるために迅速に継続的に改善できるようにすることです。
② アジャイル開発：開発の後半段階でも要件の変化に喜んで対応します。変化をコントロールし、顧客が競争上の優位性を獲得できるよう支援するのが得意です。
② AI ローコード開発：ソフトウェア開発と使用のどの段階でも、要件の変化に積極的に直面し、ソフトウェア システムの予測能力を高めて、顧客が競争上の優位性を獲得できるように支援します。
③ アジャイル開発:動作するソフトウェアを数週間または 1 ～ 2 か月の間隔で頻繁に提供し、サイクルが短くなる傾向があります。
③ AI ローコード開発：ローコード開発ツールを使用することで、動作するソフトウェアを迅速に提供し、コードと設計の可読性を確保します。
コミュニケーションと協力
④ アジャイル開発：ビジネスパーソンと開発者は、プロジェクトの毎日においても例外ではなく、互いに協力しなければなりません。
④ AI ローコード開発:ビジネスプログラマーは AI を使用してビジネスを理解したり、ビジネス担当者と協力したりできます。
⑤ アジャイル開発：個人の闘争心を刺激し、個人を核としてプロジェクトを構築する。信頼に裏付けられた目標達成に必要な環境とサポートを提供します。
⑤ AI ローコード開発： AI ローコード開発ツールを核としてプロジェクトを構築し、個人の闘争心を刺激し、一貫した環境とサポートを提供し、信頼を補って目標を達成します。
⑥アジャイル 開発：チームの内外を問わず、情報を伝達するための最良かつ最も効率的な方法は、対面での会話です。
⑥ AI ローコード開発:統一された設計開発プラットフォームを使用して、ドメイン知識の理解の一貫性を確保し、概念理解に相違がある場合は、可能な限り対面でコミュニケーションします。
プロジェクトの実施とプロジェクトの推進
⑦ アジャイル開発:ソフトウェアが動作することが進歩の主な尺度です。
⑦ AI ローコード開発:動作するソフトウェアと明確で読みやすいコードが進歩の主な指標です。
⑧ アジャイル開発:アジャイルプロセスは持続可能な開発を提唱します。オーナー、開発者、ユーザーは協力してペースを保つ必要があります。
⑧ AI ローコード開発:ローコード プロセスは、持続可能な迅速な開発を提唱します。オーナー、ビジネス プログラマー、ユーザーは、ペースを一定に保つために協力できる必要があります。
⑨ アジャイル開発：優れた技術と優れた設計を粘り強く追求することで、アジャイル性が高まります。
⑨ AI ローコード開発：優れた技術、優れたデザイン、読みやすいコードを粘り強く追求し、ローコード開発能力を強化します。
プロジェクトとチームの継続的な改善
⑩アジャイル 開発:シンプルさをベースに不必要な作業負荷を削減する技術。
⑩ AI ローコード開発： AI ラージモデルの機能を最大限に活用し、不要な作業負荷を軽減するように努めます。
⑪ アジャイル開発:最高のアーキテクチャ、要件、設計は、自己組織化されたチームから生まれます。
⑪ AI ローコード開発:最適なアーキテクチャ、要件、設計は、自己組織化されたチームだけでなく、優れた開発プラットフォームと AI モデルからもたらされます。
⑫アジャイル 開発:チームは効率を向上させる方法を定期的に振り返り、それに応じて行動を調整します。
⑫ AI ローコード開発:チームはパフォーマンスを向上させ、AI 機能を強化する方法を定期的に検討し、それに応じて自身の動作を調整します。
新しいソフトウェアエンジニアリング革命
AIローコードの出現は、プログラミング分野における継続的な蓄積の結果であり、量的変化から質的変化への必然の流れです。AIローコードは、製造業におけるソフトウェア開発の自動生産ラインに相当し、もはや個人に依存せず、標準的な持続可能な迅速な開発システムとなります。これは単なる技術的なフレームワークではなく、新しいソフトウェア エンジニアリングのアイデア、プログラマ自身のプログラミング方法の反映、そして生産性をさらに解放するための新しい技術的なフレームワークでもあり、ソフトウェア システムの開発と実践を大きく変えることになります。
AIローコード開発は、プロセス指向とオブジェクト指向の次の新しい抽象化であり、成熟した効率的なコンポーネントとモデルを使用して、技術レベルとビジネス レベルの両方でソフトウェア システムの構築と実装を迅速に完了します。
AIローコード開発は、ウォーターフォール開発、アジャイル開発に次ぐ新しい開発手法であり、可読性の高いコードと深いビジネス理解により、機能の迅速な反復を実現し、顧客の継続的な成功を実現します。
追記
IT業界に最も欠かせないものはコンセプトですが、そのコンセプトの中には短命なものもあれば、時代を代表するものもあります。AIGC とローコードは間違いなくホットなコンセプトです。ソフトウェア開発の分野ではローコードという言葉は長年使われてきたと個人的には思っていますが、ローというのは単に小さいだけではなく、マイクロがただ小さいだけではないのと同じで、非常に状態のことを指します。ビジネスロジックに基づいて実装されており、階層化と分業の具現化でもあると理解できます。ローコードはノーコードとは根本的に異なるため、比較することはできません。1 つはプロのプログラマー向けで、新しいソフトウェア エンジニアリングのアイデアと開発モデルであり、もう 1 つはユーザー向けで、視覚的な構成方法は成熟したソフトウェアの拡張です。さらに、AI は今日最も輝かしいテクノロジーとして、ローコード開発の分野でより多くの異なるジャンルを必然的に生み出すでしょう。そのため、王波の「滕王亭の序文」を引用します。
あえて軽蔑し、敬意を表し、引用を少なくし、すべての言葉は同等であり、四韻は完全です。陸と海にそれぞれそそぐ潘江川にまいてください。
著者記事リンク:
AI ローコード開発マニフェストのプロセス: ソフトウェア エンジニアリング
最も強力なプログラマでもこれら 3 つの問題点を抱えていますが、そうではありません。
コード、ノーコード、ローコード、AIプロンプトコード、AIローコードの5つの次元で比較
AI は人間のためにコードを書くのでしょうか、それとも自分自身のためにコードを書くのでしょうか?
原文 | 著者 | Xue Dan、国立国防技術大学博士、シニアプログラマー。すべての著作権は留保されており、再版する場合は、許可を得るため連絡し、出典を示す必要があります。