ローコードは開発者にとっても有益です: 次のプログラミング革命が到来します

最新のツールやサービスにより開発者の生産性は向上していますが、依然として「アプリのギャップ」が存在します。 それは、構築するリソースがあるコードと、関係者が望むコードとの間のギャップです。 開発チームは過負荷になっているため、コア ビジネス システムとその連携に必要なツールに重点を置いて、作業に優先順位を付ける必要があります。

したがって、ローコード ツールが普及するのは驚くべきことではありません。 これらは、使い慣れた概念に基づいて構築されており、必要なアプリケーションの構築と共有に役立つツールセットをエンド ユーザーに提供します。 Excel と Access の論理的な後継者であるこれらは、データへのアクセスを開放し、次のような機能を提供する遊び場です。 共通の構築からシンプルなユーザーエクスペリエンスを構築しながら、アプリケーションとサービスをリンクする方法 ブロック。 これらは、業務からワークフローを抽出し、取得したアクションをコードに変換できる、最新のプロセス自動化ツールと考えることができます。

ローコードツールなど ザピエル そしてマイクロソフトの パワープラットフォーム 多くの場合、開発需要を軽減し、ユーザーが必要なときに必要なアプリを構築できるようにする方法とみなされます。 アプリのギャップを減らす方法があるのは良いことですが、ローコード ツールを単独で見ることを不可能にする重大な制限があります。

APIの管理 

ローコードへの取り組みを急ぐと忘れられがちなことは、ローコードは本質的にワークフローと統合テクノロジであり、それはエンドポイントの構築と管理を意味するということです。 ここでは、既存の開発チームが既存のアプリケーションやサービスにマネージド API を提供する任務を負う必要があるため、不可欠になります。 ほとんどのローコード ツールで使用される REST ベースの API モデルは実装とサポートが比較的簡単ですが、 このプロセスでは、誰がこれらの API にアクセスできるのか、また API 経由でどの程度アクセスできるのかという新たな問題が生じます。 彼ら？

既存の ID プラットフォームに結び付けられた何らかの形式の API 管理がなければ、ローコード ソリューションを実装することはできません。 データのセキュリティと整合性を確保するには、ロールベースのアクセス制御と管理されたスロットルが必要になります。 保護されたデータには、それを必要とするユーザーのみがアクセスできるようにし、ユーザーが多すぎても基幹業務システムの運用に影響を及ぼさないようにする必要があります。 API 管理をローコード スイートの一部にすることで、API へのアクセスが必要なユーザーをシンプルなセルフサービス プロセスを使用してプロビジョニングでき、未使用のアカウントを清掃してデータ損失を回避できます。

チームで働く 

次に、ローコードが単独で開発されるという問題があります。 アセットが複数回作成されることが多く、コードの再利用と移植性の利点が失われます。 問題の一部は、多くのローコードが独自の環境で開発されており、ソース管理システムやソーシャル コーディング環境と統合されていないことです。 GitHub. 元のローコード環境である Excel でさえ、独自のモデルから離れつつあり、新しい ラムダ この機能を使用すると、異なるプロジェクト間でコード ブロックを共有できます。

明らかなことは、たとえ視覚的なドラッグ アンド ドロップ キャンバスで生成されたとしても、ロー コードはコードであるということです。 主流のエンタープライズ開発でコードを扱うのと同じ方法でコードを扱い、コードの安全性と安全性を確保する必要があります。 信頼性が高く、可能であれば、それらのアプリケーションの構築に使用された知識が失われることなく、他のユーザーと共有できること。 チーム。

初期のローコード ツールでは、これに不可欠なものの多くが省略されていました。 はい、開発者レビューやその他のマイルストーンを使用して、それを中心にプロセスを構築することはできますが、そのアプローチは明らかな問題の邪魔になります。 ローコードの利点により、計画寿命が数か月しかないアプリの迅速な開発に障害が生じます。

大規模な開発ツールにローコードを導入すると、組織のさまざまな部門のスキルを活用し始め、いわゆる「開発ツール」として知られるものを構築できるようになります。 「フュージョンチーム」 さまざまなグループが協力して、特定の問題を解決するアプリやサービスを構築します。 フュージョン チームの各メンバーは異なる責任を負います。1 人はエンド ユーザー、1 人はローコード開発者、1 人はサービス API の管理になります。 このようなチームに固定された構造はありません。 特定のタスクに必要な人材で構成されています。 実際に会う必要さえありません。プロジェクトの Slack または Teams チャネルで、ほとんどの一般的なやり取りには十分でしょう。

コードとしてのローコード 

新しいツールがこの状況を変え始め、新しい管理概念とコード共有の新しい方法が導入されました。 重要な開発の 1 つは、純粋なグラフィカル ツールからの移行であり、できることの多くをカプセル化する新しい言語の開発です。 グラフィカル ツールを使用して実行できるため、ローコード開発を CI/CD パイプラインや GitHub などのソーシャル コーディング ツールに組み込むことができます。

これらの新しい言語は、SQL クエリや Excel 数式などの概念に基づいて構築されており、ローコード環境により適しています。 宣言型プログラミングと関数型プログラミングの両方の概念を組み合わせて使用​​するため、すぐに理解できます。 ユーザーは使い慣れたグラフィカル開発環境を使用して作業し、結果のコードを Git リポジトリに自動的に保存できます。 一方、開発者は、IDE またはコード エディターでそのコードをすぐに確認できます。 コンテキストを切り替える必要はなく、誰もが必要な作業を行うために必要なツールを利用できます。 開発者は CI/CD パイプラインを使用して、リリース前にコードを迅速にテストし、重大なバグやその他の重大なバグを探すことができます。

見る： Web 開発者または CTO、給与が最も急成長している技術職はどれですか?

ローコードをコードにすると、新世代の機械学習ベースのコーディング アシスタントを利用できるようになります。 OpenAI のようなテクノロジー コーデックス モデルは、コード内の一般的なパターンを特定し、他のアプリケーションが同様の問題を解決する方法に基づいて提案を行うことができます。 たとえば、ローコード アプリで ERP システムに接続されたグリッド コントロールが必要な場合、適切な接続文字列の構築方法やクエリの最適なフォーマット方法を提案できます。

これはまだ初期段階にあるアプローチですが、将来性を示しています。 AI にコードを書いてもらうというよりも、AI ベースのペア プログラマーがコードを改善する方法について提案してくれるのです。 ローコード アプリケーションの構築方法を学ぶにつれて、それはゆっくりと外せる一連の補助輪となり、AI と開発者のリソースの両方への依存を軽減します。

コア システム開発者が API を構築し、AI がその使用方法を改良し、 そしてユーザーは、彼らの提案にすぐに従って、うまく機能し、他の機能を中断しない高品質のアプリを構築します。 ユーザー。

私たちはアプリの構築方法と使用方法における大きな変化の初期段階にあり、ローコードがこの新しい革命の主要な推進力となるでしょう。 ローコードと主流のアプリケーション開発の間には緊密な関係が必要です。 ただし、ローコードは開発リソースの不足に対応する方法と見なされているため、この関係は慎重に管理する必要があります。 したがって、効果的な API 管理やコード共有を改善するツールの使用の重要性を組織が認識しているのは良いことです。 組織の境界を越えた新しいチーム構造を構築し、最後に機械学習を使用してリスクを軽減し、リスクを軽減します。 生産性。