ローコードとノーコードについて開発者が好まない 8 つのこと

ローコードおよびノーコード (LC/NC) ツールのメーカーは、人々、特にプロの開発者に自社のツールやプラットフォームを使用する、または試してみるよう説得するという困難な戦いに直面しています。いくつかのプラットフォームがこの市場に進出していますが、ソフトウェア開発の大部分は、間違いなくコードを書く専門家によって行われています.

ツール メーカーの観点からは、関心の欠如は困惑しているように見えます。開発の高速化、コストの削減、バグの減少、展開の容易化、管理された環境など、ユートピア的なビジョン ツール メーカーの提示を拒む人がいるでしょうか?多くの人が難しい言語、複雑なバグ追跡、あいまいな環境設定との戦いを続けているのはなぜですか?

私は開発者と話したり、記事を読んだり、ディスカッション フォーラムを探し回ったりして、これらの質問に対する回答を得て、提起された理由のいくつかを照合してきました。

彼らのキャリアには役立たない

ローコード ツールを学習するには、多大な時間と労力を費やす必要がありますが、特定の LC/NC ツールを学習することに専門的な価値はほとんどありません。ソフトウェア開発会社が LC/NC ツールを使用するというまれなケースでも、従業員の開発者がそのツールを学習して習得したスキルが、次の雇用主に必要とされることはほとんどありません。

ほとんどの開発ジョブは、広く使用されている言語とフレームワークに関する深い知識と経験を必要とし、React、Angular、Python、Java、または C# ほど広く使用されているローコード ツールはありません。

LC/NC ツールの知識が必要な開発ジョブはほとんどなく、開発者が LC/NC ツールを知っていれば、より良い仕事を見つけたり、より多くのお金を稼いだりする可能性は非常に低くなります。したがって、開発者は、求人市場で需要の高い無数のスキル、フレームワーク、および言語の 1 つを学び、完成させるために時間を費やしたほうがよいでしょう。

開発者は何年もかけてコードの書き方を学びました

に回答した開発者のほぼ 70% 2021 年スタック オーバーフロー デベロッパー アンケートコンピュータ サイエンスまたは関連科目の学士号以上を取得していると宣言した。これは、大多数の開発者が、プログラミングの学習、さまざまな言語、システム アーキテクチャの学習、および一般的にコードを書く技術の練習と完成に何年も投資したことを意味します。 LC/NC ツールを使用することは、多くの場合、苦労して得た経験と投資が表す利点を放棄することを意味します。そのため、ほとんどの開発者が苦労して獲得した貴重なスキルを利用することを好むのは当然のことです。

LC/NC ツールが約束どおりの機能を実際に提供する場合、アプリケーションを作成するためのコードを記述する必要はなくなるでしょう。プログラミングはより高いレベルの抽象化に移行し、アプリケーションはコーディングではなく既存のコンポーネントから組み立てられます。したがって、プログラマーは本質的に、LC/NC ツールの使用の増加を使用およびサポートすることで、苦労して獲得したスキルを無駄にすることを脅かしています。したがって、LC/NC ツールが成功しないことは、実際には彼らの利益になります。

開発者は速度を気にしません

開発者がソフトウェア ハウスで働く場合、特定の特性を持つコードを提供することで報酬が支払われます。これらには、読みやすい、テスト可能、適切に構造化されている、信頼性が高い、効率的である、標準に従っている、などが含まれます。適度に複雑なアプリケーションを維持している開発者は、コードをできるだけ単純で理解しやすいものにすることがいかに重要であるかを理解するでしょう。これらの品質は、コードを保守可能にするために不可欠です。

コードは通常、これらの品質にも関心を持ち、それらを強調する上級プログラマーによってレビューされます。彼らは、開発者よりも速く物事を成し遂げることに関心があるかもしれませんが、バグが多く、非効率的で、暗号化されており、拡張しにくいコードは保守が難しいことを知っています。

この悪いコードは多くの問題を引き起こし、将来的に非常に高価になる可能性があります。コードが配信される速度は関係がありますが、通常は、コードが配信される速度よりも、コードの構成方法と記述方法が優先されます。

そのため、LC/NC ツールの開発速度を開発者に宣伝しても、実際には期待したほどの効果は得られない可能性があります。

開発者はコーディングを楽しむ

人は曖昧で感情的です。彼らは相反する優先順位を持ち、しばしば確信が持てず、不正確で、嘘をつきます。多くの場合、彼らは自分が何をしているのか、なぜそれをしているのかさえわかっていません。人々は非常に混乱することがあります。コンピュータははるかに単純です。コンピューターはプログラマーから与えられた指示に従うだけで、その指示が正しくない場合、プログラムは失敗します。一連のタスクを定義し、それらがすぐに正確に実行されるのを見る正確さは、多くの人々に安心感と喜びを与えます。

コーディングには、多くの開発者が本当に楽しんでいる創造的な要素があります。プログラミングは非常に複雑なパズルであり、頭の体操に満ちており、数十のモジュール、複数のレイヤー、数千行のコードにまたがっています。 1 つの Web アプリケーションに、5 つ以上の異なる言語 (HTML、JS、CSS、C#、SQL など) を簡単に連携させることができます。連動する可動部品の複雑なオブジェクトを作成し、それらが組み込まれたロジックの結果を実行する際に微妙なサイクルで動作するのを見るのは魅力的であり、強い達成感をもたらします.

ソフトウェアが存在する理由は生活を楽にすることであり、私たちは基本的に人々が物事をより良く行うのを助けるためにソフトウェアを構築しています。どんな言語でもコードの書き方がわかれば、想像できるものなら何でも構築できます。何かを想像し、何もないところからそれを生み出すことに喜びがあります。

開発者は技術スタックを選ばない

開発者がプロジェクトに長くとどまるほど、アプリケーションの拡張が上手になり、問題の発見と修正がより効率的になります。開発者は仕事を辞める際、アプリケーションの複雑な詳細に関する詳細な知識を持ち出すことがよくあります。この知識を取り戻すのは非常に困難であり、そのような従業員が交代すると、彼らがサポートするアプリケーションはしばしば不安定な段階に入り、時には混乱に陥ることさえあります。そのため、ソフトウェア ハウスは安定性に関心がありますが、ソフトウェア開発者は 1 つの雇用主に数年間しか滞在しないことがよくあります。

ソフトウェア会社が知識の損失を軽減するために採用している戦略の 1 つは、開発者コミュニティで広く使用され、よく知られているテクノロジを使用することです。よく知られているスタックを使用すると、採用するスキルのある人材を簡単に見つけることができます。また、それらの人々が自分で構築したアプリケーションの詳細を学ぶのにも役立ちます。開発者は、プロジェクトに使用するテクノロジの決定に影響を与える可能性がありますが、通常、これらの基準を使用してスタックを決定するのはシニア エンジニアまたは管理者です。したがって、LC/NC ツールを開発者に売り込むことは、的を射ていない可能性があります。

ツールに賭けるのは危険です

クライアントは、将来どこでアプリケーションを取得する可能性があるかを特定するのが難しい傾向があります.未来を予測するのは非常に難しいため、これは理解できます。そのため、アプリケーションの所有者は、アプリケーションの商業的成功を確保するために、変化するニーズに適応する必要があります。これは多くの場合、ビジネス モデルを修正し、そのようなモデルを可能にするテクノロジーを変更することを意味します。経験豊富な開発者はこれを知っており、将来の変化するニーズに適応できるオープン システムを構築することを好みます。このような適応可能なシステムを作成する最善の方法は、十分にサポートされている言語とフレームワークを使用してコーディングすることです。

多くの LC/NC ツールは新しく、未熟で、重大な技術的制限があります。これらの制限は、通常は公表されておらず、ほとんど文書化されていないこともよくあります。ソフトウェア会社が実際にこれらの制限を見つける唯一の方法は、ツールを試して実際のアプリケーションを構築することです。ほとんどの制限は、多大な時間と労力を費やした後で初めて明らかになります。ソフトウェア開発はそのままでは高価でリスクが高く、これらの未知数は、開発者、ソフトウェア ハウス、およびそのクライアントのリスクをさらに増大させます。

ロックインが契約を結びます

多くのプラットフォームでは、そのプラットフォームで構築されたアプリケーションを汎用の編集可能な形式にエクスポートできません。アプリケーションをロックインすることで、開発者をプラットフォームに結び付けるか、アプリケーションを最初から再構築する必要があります。将来の要件が不確実であり、LC/NC ツールの制限がプロジェクトの後半まで隠されていることが多いことを考えると、開発者が閉じ込められることを極度に警戒することは驚くべきことではありません。

LC/NCは過去に何度も失敗しています

ビジュアル開発ツールは新しいものではありません。ビジュアル開発の初期の試みは、50 年前にすでに行われていました。それ以来、多くの良いビジュアル開発環境と悪いビジュアル開発環境とプラットフォームが生まれては消えていきましたが、アプリケーションの作成方法に大きな違いをもたらしたものはありません。

これらのツールのいずれかに賭け、それらを学ぶために時間とエネルギーを投資し、クライアントにそれらのいずれかでプロジェクトを構築するよう説得した人は、その賭けに負けました.この歴史は、今日私たちが目にするツールのどれもが、今から約 10 年後も存続する可能性が低いことを示唆しています。多くの開発者は、これらの事実を慎重に検討し、LC/NC は行き止まりであると判断する可能性があります。

それで？

では、LC/NC は失われた原因であり、深刻なソフトウェア開発の世界に LC/NC の居場所はないのでしょうか? LC/NC ツール メーカーは、どうにかしてこれらの障壁を克服し、より多くの開発者に LC/NC 製品を使用する動機を与えることができるでしょうか?

多くの開発者は、LC/NC ツールとそれらを宣伝するマーケティング コミュニケーションに対する信頼の欠如のために、コードを好みます。あらゆる専門家に LC/NC プラットフォームを使用するよう説得するために、プラットフォーム メーカーは開発者に自社を信頼するよう求めています。この信頼を築くために、ツールメーカーは、開発者やソフトウェア会社が提唱する懸念に耳を傾け、プラットフォーム機能を計画するときやターゲットグループと通信するときにそれらを考慮に入れることをお勧めします.

機能上の制限を正直かつ正直に開示し、制限を克服する方法を公開し、プラットフォームの学習曲線を平坦化し、アプリケーションを編集可能な形式にエクスポートできるようにすることは、すべての開発者を納得させるものではないかもしれませんが、正しい方向への一歩です。