定制應(yīng)用程序開發(fā)是一項(xiàng)艱巨的任務(wù) - 即使對(duì)于非常簡(jiǎn)單的解決方案也是如此。這也是您的公司可能進(jìn)行的最大投資之一。在為您的團(tuán)隊(duì)創(chuàng)建定制解決方案時(shí)，把事情做好是值得的。

今天，我們將介紹您需要了解的有關(guān)構(gòu)建可真正提高投資回報(bào)的自定義應(yīng)用程序的所有信息。

具體來(lái)說(shuō)，我們正在深入探討您選擇走定制路線的情況、您將享受到的好處以及您將遇到的挑戰(zhàn)。

我們還將介紹如何實(shí)現(xiàn)這一目標(biāo)的實(shí)際方面 - 整合工具堆棧、建立團(tuán)隊(duì)、資源開發(fā)以及如何構(gòu)建成功的開發(fā)流程。

什么是定制應(yīng)用程序開發(fā)？

這似乎是不言自明的，但實(shí)際上需要解開的內(nèi)容比您想象的要多得多。從非常高的層面來(lái)看，定制應(yīng)用程序開發(fā)是構(gòu)建定制軟件來(lái)解決您獨(dú)特的業(yè)務(wù)問(wèn)題的過(guò)程。

當(dāng)然，還有更多的事情要做。

首先，定制構(gòu)建不只有一種。實(shí)際上，這可以采取相當(dāng)廣泛的形式——從完全新穎的研發(fā)項(xiàng)目到仍然需要一點(diǎn)個(gè)性化的相對(duì)簡(jiǎn)單的解決方案。

除此之外，我們還會(huì)遇到一些與如何開發(fā)自定義應(yīng)用程序相關(guān)的灰色區(qū)域，稍后我們會(huì)看到。在定制業(yè)務(wù)應(yīng)用程序方面，找到一種適合所有定義的方法有點(diǎn)困難。

例如，如果您的開發(fā)人員從頭開始編寫新的解決方案，那么沒(méi)有人會(huì)質(zhì)疑這是自定義構(gòu)建。如果他們?cè)诂F(xiàn)有應(yīng)用程序模板的邊緣進(jìn)行擺弄或更改某些開源解決方案，那么您將陷入更黑暗的境地。

如果他們將您的徽標(biāo)貼在現(xiàn)成的 CRM 上，我們可能不會(huì)將其稱為自定義應(yīng)用程序。

那么這里的界線在哪里呢？

讓我們退后一步，更詳細(xì)地考慮一下自定義應(yīng)用程序。

什么是自定義應(yīng)用程序？

同樣，從表面上看，這似乎是一個(gè)有點(diǎn)奇怪的問(wèn)題，但請(qǐng)耐心等待。因此，我們知道定制軟件應(yīng)用程序是為您的業(yè)務(wù)流程構(gòu)建的。通常 - 由于您必須定制 - 它們是從頭開始構(gòu)建的。

無(wú)論我們使用什么技術(shù)來(lái)構(gòu)建應(yīng)用程序，這都是事實(shí) - 盡管這仍然是一個(gè)重大決定，正如我們將看到的。這可能涉及 JavaScript 和 Python 等常見語(yǔ)言或 NodeJS、Rails 或 Angular 等框架。

我們甚至可以使用應(yīng)用程序開發(fā)平臺(tái)來(lái)創(chuàng)建應(yīng)用程序并在應(yīng)用程序商店（例如 iOS 和 Android）上發(fā)布它。

同樣，我們會(huì)及時(shí)回到這個(gè)話題。

現(xiàn)在，我們想考慮一下自定義應(yīng)用程序通常做什么。也就是說(shuō)，我們可能需要為哪些類型的用例開發(fā)定制解決方案？

這里一個(gè)明顯的問(wèn)題是，如果我們走定制應(yīng)用程序構(gòu)建的道路，通常是因?yàn)槲覀冇惺袌?chǎng)無(wú)法滿足的非常具體的要求。

但一般來(lái)說(shuō)，自定義應(yīng)用程序是圍繞復(fù)制業(yè)務(wù)中某些特定流程、規(guī)則集或邏輯的目標(biāo)構(gòu)建的 - 通常是為了比我們手動(dòng)更有效地實(shí)現(xiàn)這一目標(biāo)。

就其本質(zhì)而言，這將是我們業(yè)務(wù)所獨(dú)有的邏輯。

因此，我們可能會(huì)構(gòu)建一個(gè)應(yīng)用程序，對(duì)提交、審查和批準(zhǔn)某些特定資源的請(qǐng)求的流程進(jìn)行編碼——要么是因?yàn)楝F(xiàn)有的解決方案在商業(yè)上不可用，要么在商業(yè)上不可行。

定制或定制

我們已經(jīng)提到過(guò)這樣一個(gè)事實(shí)：定制業(yè)務(wù)應(yīng)用程序開發(fā)在構(gòu)建特定解決方案所需的實(shí)際開發(fā)工作范圍方面可能存在很大差異。

因此，舉一個(gè)簡(jiǎn)單的例子，想想構(gòu)建一個(gè)簡(jiǎn)單的進(jìn)氣表單和一個(gè)將火箭降落在火星上的腳本之間的區(qū)別。顯然，兩者都是軟件，但它們幾乎不屬于同一聯(lián)盟。

思考這個(gè)問(wèn)題的一種方法是區(qū)分定制和定制。事實(shí)上，它們之間仍然沒(méi)有清晰的概念界限，但它仍然是一個(gè)有用的框架。

那么我們?cè)谶@里的意思是什么？

一方面，我們擁有從頭開始構(gòu)建的解決方案——真正的定制工具。另一方面，我們擁有基本上現(xiàn)成的解決方案，但我們添加了一些配置、個(gè)性化或擴(kuò)展功能。

這就是我們說(shuō)有一個(gè)頻譜在起作用時(shí)的意思。

這每一端都傾向于不同的好處、挑戰(zhàn)、缺點(diǎn)和用例。因此，我們需要的解決方案越量身定制，我們預(yù)計(jì)需要承擔(dān)的工作量、費(fèi)用和等待時(shí)間就越多。

同樣，如果我們選擇定制某些現(xiàn)有解決方案，我們就會(huì)在功能、能力、個(gè)性化甚至我們可能實(shí)現(xiàn)的性能方面受到一定程度的限制。

而且，正如您可以想象的那樣，這兩個(gè)節(jié)點(diǎn)之間有一大堆空間。當(dāng)我們開始考慮企業(yè)用來(lái)開發(fā)自定義應(yīng)用程序的一些特定工具和策略時(shí)，這一點(diǎn)將變得更加明顯。

（言鼎科技）

定制與商用

我們可以得出的另一個(gè)重大區(qū)別是定制和商業(yè)現(xiàn)成的。事實(shí)上，這些實(shí)際上是對(duì)立的。COTS 工具是您可以購(gòu)買并向用戶推出的應(yīng)用程序。

當(dāng)這是一種選擇時(shí)，它通常是一個(gè)非常有吸引力的選擇 - 至少，假設(shè)市場(chǎng)上的產(chǎn)品無(wú)論如何都具有一定的質(zhì)量。因此，如果我們談?wù)摰氖侵T如文字處理器之類的東西，那么 COTS 選項(xiàng)自然更有意義。

也就是說(shuō)，當(dāng) Word 和 Google Docs 就在那里時(shí)，構(gòu)建自己的自定義文字處理器幾乎沒(méi)有意義。

就像以前一樣，這里涉及很多權(quán)衡。

當(dāng)市場(chǎng)上出現(xiàn)商用解決方案時(shí)，有趣的問(wèn)題才真正開始出現(xiàn)?；蛘摺辽佼?dāng)有潛在的選擇時(shí)。

在這種情況下，我們需要審查可用的產(chǎn)品，以確定它們?nèi)绾斡行У貪M足我們的要求。我們還需要就財(cái)務(wù)上最明智的前進(jìn)道路做出判斷。

定制應(yīng)用程序開發(fā)的好處是否超過(guò)成本。換句話說(shuō)…

我們什么時(shí)候會(huì)選擇定制構(gòu)建？

這個(gè)問(wèn)題讓 IT 領(lǐng)導(dǎo)者夜不能寐。我們真正需要知道的是，定制構(gòu)建的業(yè)務(wù)案例何時(shí)比購(gòu)買現(xiàn)成產(chǎn)品更有利。我們知道，一種情況是 COTS 工具不可用。

但還有什么時(shí)候呢？

為了回答這個(gè)問(wèn)題，讓我們思考一下自定義應(yīng)用程序開發(fā)的一些最重要的優(yōu)點(diǎn)和缺點(diǎn)。

我們將從專業(yè)人士開始。

定制開發(fā)的好處

正如潛在的用例一樣，企業(yè)將定制構(gòu)建確定為最具吸引力的選擇的具體原因可能存在很大差異。

為了更好地理解這一點(diǎn)，讓我們考慮一下您可能想要實(shí)現(xiàn)的一些具體好處。

所有權(quán)

所有權(quán)對(duì)于大型組織來(lái)說(shuō)尤其重要。也就是說(shuō)，真正擁有他們使用的工具。由此產(chǎn)生了一些重要的、切實(shí)的好處。

一方面，所有權(quán)與控制權(quán)直接相關(guān)。當(dāng)我們擁有自己的解決方案時(shí)，我們就可以決定如何使用它們。這滿足了從我們?nèi)绾螛?gòu)建技術(shù)能力到維護(hù)工具的實(shí)際方面的一切。

同樣，在某些情況下，我們可能希望保留對(duì)解決方案的所有權(quán)，因?yàn)樗鼈兪顷P(guān)鍵任務(wù)甚至是絕密的，因此我們會(huì)通過(guò)使用我們不擁有和控制的工具來(lái)創(chuàng)造不必要的風(fēng)險(xiǎn)。

（邁克菲 ）

功能性

其他時(shí)候，選擇定制構(gòu)建將是實(shí)現(xiàn)我們所需功能的唯一方法 - 或者至少是最具成本效益的方法。顯然，這可能是一些完全邊緣的用例，沒(méi)有人提供解決方案。

但更常見的是，我們處理的是看起來(lái)相對(duì)較小的需求，排除了現(xiàn)成的解決方案。典型的例子是對(duì)遺留工具或數(shù)據(jù)源的支持。

例如，您的團(tuán)隊(duì)可能需要一個(gè)解決方案來(lái)實(shí)時(shí)管理和報(bào)告庫(kù)存損失/破損。但您的庫(kù)存管理系統(tǒng)有點(diǎn)過(guò)時(shí)，因此市場(chǎng)上的解決方案都不支持它。

最終，您想要更新整個(gè)庫(kù)存管理堆棧。與此同時(shí)，定制解決方案可能是滿足您當(dāng)前更緊迫需求的最具成本效益的方式。

生命周期管理

這與控制權(quán)和所有權(quán)的概念有關(guān)。這里的基本結(jié)果是，定制應(yīng)用程序開發(fā)使我們?cè)谏芷诠芾矸矫嫣幱谥鲗?dǎo)地位。我們決定何時(shí)啟動(dòng)、更新、擴(kuò)展和棄用我們的工具。

我們可以指出一些特別重要的場(chǎng)景。一是產(chǎn)品的實(shí)際壽命。工具的任務(wù)越關(guān)鍵，我們就越希望避免供應(yīng)商終止支持、取消某個(gè)功能或完全停用某個(gè)工具。

另一方面，對(duì)于 COTS 解決方案，我們需要考慮供應(yīng)商的路線圖如何與我們的預(yù)期需求保持一致。例如，如果我們知道我們將在某個(gè)給定點(diǎn)需要某個(gè)特定功能，那么供應(yīng)商是否有計(jì)劃實(shí)現(xiàn)這一點(diǎn)？

這里的要點(diǎn)是，自定義應(yīng)用程序開發(fā)本質(zhì)上消除了此類問(wèn)題，為我們提供了更多的輸入和對(duì)解決方案生命周期的控制。

成本

成本是一個(gè)非常棘手的問(wèn)題。事實(shí)上，這里并沒(méi)有一個(gè)簡(jiǎn)單的規(guī)則。正如 - 定制應(yīng)用程序開發(fā)不一定比替代方案更便宜或更昂貴。

不過(guò)也有可能。

您看，影響成本/收益計(jì)算的因素有無(wú)數(shù)，包括您的內(nèi)部 IT 資源、COTS 解決方案的成本、您對(duì)特定工具的期望價(jià)值、支持安排等等。

因此，我們可能已經(jīng)擁有一支內(nèi)部開發(fā)人員團(tuán)隊(duì)?；蛘?，我們可能根本沒(méi)有 IT 部門。我們需要找出從長(zhǎng)遠(yuǎn)來(lái)看最具成本效益的采購(gòu)解決方案是什么。

稍后我們將考慮自定義應(yīng)用程序開發(fā)項(xiàng)目的一些對(duì)其成本產(chǎn)生巨大影響的方面。

（言鼎科技）

可擴(kuò)展性

與生命周期管理一樣，自定義應(yīng)用程序開發(fā)提供了可擴(kuò)展性方面的優(yōu)勢(shì)，因?yàn)槲覀儽?COTS 解決方案擁有更大的靈活性和影響力。

與以往一樣，我們可以指出兩種不同的可擴(kuò)展性類別：水平和垂直。例如，我們添加新功能的容易程度與添加新用戶或容量的容易程度之間的關(guān)系。

其中每一個(gè)都可能受到多種方式的影響，包括技術(shù)和許可方面的考慮。

問(wèn)題的關(guān)鍵在于，如果您將來(lái)想要修改或構(gòu)建您的解決方案，您需要自己完成此操作。當(dāng)然，另一方面是我們不需要等待供應(yīng)商也這樣做。

安全

最后，我們有安全保障。對(duì)于大型組織來(lái)說(shuō)，這通常是進(jìn)行定制開發(fā)的真正動(dòng)力。無(wú)法回避的事實(shí)是——至少有時(shí)——滿足我們安全需求的最佳方式是使用完全定制的解決方案。

這可能是因?yàn)槟枰獙?shí)現(xiàn)特定的工具來(lái)保護(hù)您的應(yīng)用程序 - 或者涉及第三方本身可能會(huì)造成安全漏洞。

其他時(shí)候，關(guān)鍵的是托管和部署。例如，您可能會(huì)受到內(nèi)部規(guī)則的限制，這些規(guī)則規(guī)定某些類型的解決方案必須自托管，甚至托管在特定類型的硬件上。

自定義應(yīng)用程序還提供了使用我們自己的身份驗(yàn)證工具或 SSO 的可能性。

定制開發(fā)挑戰(zhàn)

當(dāng)然，定制應(yīng)用程序開發(fā)帶來(lái)了一系列我們無(wú)法用 COTS 工具應(yīng)對(duì)的挑戰(zhàn)。其中一些是非常明顯的。其他可能不是你首先想到的事情。

其他的實(shí)際上只是我們剛才經(jīng)歷過(guò)的好處的另一面。

因此，值得探索我們可能遇到的一些實(shí)際問(wèn)題。

讓我們直接開始吧。

為內(nèi)部開發(fā)項(xiàng)目提供資源

大多數(shù)企業(yè)在定制開發(fā)時(shí)最擔(dān)心的無(wú)疑是成本。這主要包括勞動(dòng)時(shí)間。就像 - 你需要向開發(fā)人員支付工資。

當(dāng)然，這是假設(shè)您目前雇用內(nèi)部開發(fā)人員 - 但您很可能沒(méi)有雇用內(nèi)部開發(fā)人員。這似乎是一個(gè)顯而易見的觀點(diǎn)，但它具有巨大的影響，因此值得詳細(xì)說(shuō)明。

您擁有的現(xiàn)有開發(fā)能力越多，您就越能夠吸收新項(xiàng)目 - 包括在分配資源時(shí)。

例如，如果您必須從頭開始構(gòu)建團(tuán)隊(duì)，則自定義項(xiàng)目的前期成本將會(huì)高得多。即便如此，當(dāng)今的企業(yè)仍面臨全球合格開發(fā)人員的短缺，這使得尋找人才變得異常困難。

不幸的是，這可能意味著定制開發(fā)僅對(duì)某些類型的企業(yè)開放 - 至少使用傳統(tǒng)的開發(fā)工具。

（言鼎科技 ）

稍后將詳細(xì)討論后一點(diǎn)。

管理定制開發(fā)項(xiàng)目

無(wú)論我們是內(nèi)部還是外包定制開發(fā)，我們都將面臨管理項(xiàng)目的挑戰(zhàn)。你看，構(gòu)建軟件時(shí)可能會(huì)出現(xiàn)很多問(wèn)題。在很多情況下，這又回到了金錢的問(wèn)題上。

盡管這看起來(lái)很瘋狂，但定制開發(fā)項(xiàng)目超出預(yù)算幾乎是常態(tài)——要么是因?yàn)榉秶印⑿坌牟臅r(shí)間估計(jì)、不可預(yù)見的依賴關(guān)系，要么是其他一些問(wèn)題。

首先，我們需要以與任何其他類型的人才完全相同的方式來(lái)考慮項(xiàng)目管理時(shí)間。

這里重要的是，有效的項(xiàng)目管理技能可以幫助我們避免許多我們可能認(rèn)為是定制開發(fā)的現(xiàn)實(shí)問(wèn)題的大問(wèn)題——比如錯(cuò)過(guò)最后期限、預(yù)算膨脹和溝通不暢。

不幸的是，找到合適的項(xiàng)目管理人才本身就是一個(gè)挑戰(zhàn)。

連續(xù)性問(wèn)題和保留知識(shí)

我們?cè)诙ㄖ崎_發(fā)中要處理的一個(gè)問(wèn)題是知識(shí)保留和連續(xù)性，這不是 COTS 解決方案的一個(gè)因素。

我們?cè)谶@里是什么意思？

理解知識(shí)保留的一個(gè)簡(jiǎn)單方法是從這樣一個(gè)前提開始：沒(méi)有人比構(gòu)建解決方案的人更了解解決方案。因此，他們可以更輕松地維護(hù)、支持或擴(kuò)展相關(guān)工具。

但是，我們需要平衡這一點(diǎn)與現(xiàn)實(shí)，即開發(fā)人員在職業(yè)生涯中傾向于從一家公司跳到另一家公司。因此，我們的挑戰(zhàn)是通過(guò)確保在定制項(xiàng)目期間記錄隱性知識(shí)來(lái)減輕這種影響。

這可能意味著實(shí)施正式的知識(shí)庫(kù)工具或定義關(guān)于代碼庫(kù)中的注釋的明確規(guī)則和期望。

實(shí)際上，內(nèi)部構(gòu)建比外包構(gòu)建要容易一些——因?yàn)槲覀冇懈叱潭鹊谋O(jiān)督和控制。

吸收風(fēng)險(xiǎn)和責(zé)任

最后，當(dāng)我們選擇定制軟件開發(fā)時(shí)，我們需要承擔(dān)額外的風(fēng)險(xiǎn)。這里的基本原則是——尤其是內(nèi)部構(gòu)建——如果出現(xiàn)問(wèn)題，沒(méi)有人可以責(zé)怪外部人員。

根據(jù)我們合同的具體情況，外包構(gòu)建的情況可能會(huì)略有不同 - 盡管我們?nèi)匀槐仁褂?COTS 工具承擔(dān)更多的風(fēng)險(xiǎn)。

那么我們談?wù)摰氖悄男╊愋偷娘L(fēng)險(xiǎn)呢？

最大的一個(gè)是項(xiàng)目失敗- 這意味著您的解決方案要么從未交付，要么無(wú)法解決其針對(duì)的問(wèn)題。由于相關(guān)的沉沒(méi)成本，這種情況發(fā)生得越深入，效果就越差。

其他重大風(fēng)險(xiǎn)包括錯(cuò)過(guò)最后期限或解決方案不滿足其初始要求的更多次要情況。

（言鼎科技 ）

我們還需要考慮定制軟件開發(fā)所承擔(dān)的額外責(zé)任。

這些是我們承擔(dān)的責(zé)任，而其他采購(gòu)策略可能不需要我們承擔(dān)這些責(zé)任。因此，如果我們購(gòu)買現(xiàn)成的工具，我們通常不需要擔(dān)心維護(hù)代碼庫(kù)，但對(duì)于自定義構(gòu)建，我們可能需要擔(dān)心。

同樣，我們最終將承擔(dān)額外的責(zé)任，例如托管、支持、入職和其他相關(guān)成本，如果我們選擇 COTS 解決方案，則可能不會(huì)有這些成本。

這些并不是無(wú)法克服的挑戰(zhàn)，但它們確實(shí)表明在確定自定義應(yīng)用程序是否確實(shí)是最可行的選擇時(shí)需要非常仔細(xì)的考慮。

定制應(yīng)用程序開發(fā)流程只需 9 個(gè)步驟

當(dāng)然，仔細(xì)考慮是一回事。更好的是，我們有一個(gè)清晰的、可重復(fù)的框架來(lái)確定在我們的特定情況下什么是最佳選擇。

這正是我們將在自定義應(yīng)用程序開發(fā)過(guò)程的九步指南中提供的內(nèi)容。更具體地說(shuō)，我們將詳細(xì)介紹您將解決方案從構(gòu)思到推出時(shí)需要做出的核心決策。

讓我們深入了解一下。

1. 問(wèn)題設(shè)置

首先，我們必須選擇一個(gè)我們認(rèn)為可以通過(guò)自定義應(yīng)用程序改進(jìn)的用例。當(dāng)然，在很多情況下，我們不會(huì)像突然出現(xiàn)的那樣去尋找用例。

即便如此，我們?nèi)匀恍枰宄亓私馕覀兿胍褂米远x解決方案解決的確切問(wèn)題，然后才能進(jìn)一步進(jìn)行。

這意味著回答一些具體問(wèn)題。一個(gè)明顯的起點(diǎn)是我們需要我們的未來(lái)解決方案做什么。我們也可以更深入地探究原因。因此，我們需要嘗試并了解相關(guān)流程在實(shí)現(xiàn)更廣泛的業(yè)務(wù)目標(biāo)中的作用。

如果我們改進(jìn)該流程的性能，它將如何影響我們的利潤(rùn)？

我們還需要考慮誰(shuí)將使用您的解決方案，以及誰(shuí)將從中受益（因?yàn)檫@些人可能不是同一個(gè)人）。

2. 需求收集和用戶研究

明確定義我們的核心問(wèn)題后，我們可以開始將其轉(zhuǎn)化為更具體的技術(shù)要求。

假設(shè)我們想要構(gòu)建一個(gè)工具來(lái)管理我們的員工如何與客戶來(lái)回發(fā)送合同。要為此創(chuàng)建功能要求列表，我們可以首先列出每種類型的用戶應(yīng)該能夠執(zhí)行的每個(gè)操作- 以及不需要用戶的操作。

幾分鐘后將詳細(xì)介紹第二部分。

我們還需要考慮所謂的非功能性需求。我們可能對(duì)某個(gè)特定解決方案有某些需求，但這些需求與其本身的用途無(wú)關(guān)。例如，對(duì)特定托管平臺(tái)或 SSO 工具的支持。

最后，我們希望進(jìn)行徹底的用戶研究。具體來(lái)說(shuō)，我們需要了解核心用戶的需求 - 包括他們的數(shù)字素養(yǎng)水平、用戶體驗(yàn)偏好、典型設(shè)備使用情況以及可能影響我們選擇構(gòu)建的解決方案的任何其他因素。

3. 數(shù)據(jù)建模

接下來(lái)，我們可以開始考慮應(yīng)用程序的數(shù)據(jù)層。我們需要做的第一件事是創(chuàng)建一個(gè)理論圖景，稱為數(shù)據(jù)模型。本質(zhì)上，這是我們的應(yīng)用程序執(zhí)行我們想要的操作所需的所有數(shù)據(jù)的概述。

首先，它需要的每個(gè)數(shù)據(jù)實(shí)體。例如，在我們前面的示例中，這可能是客戶、員工、合同和請(qǐng)求。然后，我們可以針對(duì)這些實(shí)體存儲(chǔ)的每個(gè)屬性 - 客戶端可能有名稱、地址和電話號(hào)碼。

接下來(lái)，我們要定義每個(gè)實(shí)體之間的關(guān)系。一個(gè)客戶可以有很多合同。每份合同必須有一名客戶和一名員工。ETC。

最后，我們需要定義數(shù)據(jù)的來(lái)源和存儲(chǔ)位置 - 無(wú)論這意味著創(chuàng)建一個(gè)全新的數(shù)據(jù)庫(kù)還是依賴于現(xiàn)有源的連接。

查看我們有關(guān)如何構(gòu)建數(shù)據(jù)模型的指南 以了解更多信息。

4. 定義流程

數(shù)據(jù)模型就位后，我們接下來(lái)需要做的就是將可能的應(yīng)用內(nèi)操作列表轉(zhuǎn)換為可應(yīng)用于我們剛剛定義的實(shí)體的流程 - 以及如何執(zhí)行這些操作。

讓我們考慮幾個(gè)例子來(lái)說(shuō)明我們?cè)谶@里的意思。

在我們的合同管理示例中，我們需要員工能夠使用其狀態(tài)屬性來(lái)跟蹤客戶是否已閱讀其合同。我們需要合約遵循的定義的事件序列，在每個(gè)事件之后更新其狀態(tài)屬性。

例如，一旦客戶端打開文件，狀態(tài)屬性就會(huì)更新為read。

我們?cè)谶@里所做的本質(zhì)上是為我們每個(gè)可能的操作定義if this, then this規(guī)則。

此時(shí)，我們還將考慮哪些操作應(yīng)該自動(dòng)化。例如，通知客戶已在其名下創(chuàng)建了一份新合同，或通知員工其合同之一的狀態(tài)屬性已更改。

5、界面設(shè)計(jì)

定義了流程后，就可以開始設(shè)計(jì)界面了。

根據(jù)您使用的自定義應(yīng)用程序開發(fā)工具，這在實(shí)踐中可能看起來(lái)相當(dāng)不同。因此，我們不要陷入特定工具和方法的泥潭，而應(yīng)該思考我們想要實(shí)現(xiàn)的目標(biāo)的原則。

對(duì)于大多數(shù)自定義應(yīng)用程序開發(fā)項(xiàng)目，我們并不完全擔(dān)心如何娛樂(lè)我們的用戶。相反，我們的目標(biāo)是找到最有效的方法來(lái)指導(dǎo)用戶執(zhí)行定義的操作，而不影響準(zhǔn)確性。

為了實(shí)現(xiàn)這一目標(biāo)，我們可能會(huì)選擇使用專門的設(shè)計(jì)人員，然后他們將他們的線框圖傳遞給開發(fā)人員來(lái)創(chuàng)建工作應(yīng)用程序?；蛘呶覀兛赡軙?huì)使用更現(xiàn)代的應(yīng)用程序構(gòu)建實(shí)踐，例如低代碼開發(fā)。

稍后我們會(huì)更多地考慮這個(gè)問(wèn)題。

6. 發(fā)展

數(shù)據(jù)模型、流程層和 UI 設(shè)計(jì)就位后，我們就可以開始將它們整合在一起。至少，這就是傳統(tǒng)應(yīng)用程序開發(fā)項(xiàng)目中的工作方式，其中每個(gè)元素基本上都是單獨(dú)硬編碼的。

然后，它們?nèi)拷M合成一個(gè)工作應(yīng)用程序。

當(dāng)然，現(xiàn)在這不是唯一的選擇?？矗瑥募夹g(shù)角度來(lái)看，大多數(shù)內(nèi)部業(yè)務(wù)構(gòu)建并不那么復(fù)雜，因此從頭開始對(duì)所有內(nèi)容進(jìn)行硬編碼不一定是最具成本效益的選擇。

（言鼎科技 ）

相反，越來(lái)越多的自定義應(yīng)用程序開發(fā)利用現(xiàn)代工具來(lái)幫助加快這一過(guò)程。

稍后我們將看到 Budibase 如何在這方面發(fā)揮帶頭作用。

7. 測(cè)試

有了可用的應(yīng)用程序，我們就可以進(jìn)入開發(fā)項(xiàng)目的測(cè)試階段。

然而，測(cè)試并不是一個(gè)單一的事情。

相反，我們需要測(cè)試應(yīng)用程序的各個(gè)不同方面。您首先想到的可能是功能測(cè)試。換句話說(shuō)，檢查以確保我們的應(yīng)用程序執(zhí)行我們期望的操作。

還有用戶測(cè)試。一旦我們知道我們的應(yīng)用程序?qū)嶋H上可以正常工作，我們就需要弄清楚我們的用戶界面的有效性。那么，用戶是否直觀地知道如何執(zhí)行不同的操作？

他們能如此快速準(zhǔn)確地做到這一點(diǎn)嗎？他們需要額外的培訓(xùn)嗎？

這是一個(gè)很容易被低估的領(lǐng)域，但我們可能會(huì)對(duì)項(xiàng)目的投資回報(bào)率產(chǎn)生巨大的影響 - 特別是如果我們預(yù)計(jì)會(huì)有更大的用戶量。

最后，我們可以考慮一些更宏觀的東西，這些東西至少與測(cè)試松散地聯(lián)系在一起。具體來(lái)說(shuō)，是與我們的核心用例相關(guān)的問(wèn)題。請(qǐng)記住，我們最終試圖通過(guò)定制開發(fā)解決一些特定的業(yè)務(wù)問(wèn)題。

我們需要部署工具來(lái)幫助我們衡量進(jìn)展情況 - 無(wú)論是自動(dòng)報(bào)告、自定義儀表板還是其他策略。

8. 推出

當(dāng)我們確信我們的解決方案能夠有效地發(fā)揮作用時(shí)，就該推出了。這是我們定制開發(fā)項(xiàng)目的另一個(gè)階段，可以決定投資回報(bào)率的成敗。

考慮這里的挑戰(zhàn)規(guī)模的一種方法是從操作角度概念化您的應(yīng)用程序推出，就像它是一項(xiàng)技術(shù)練習(xí)一樣。因此，一方面，我們面臨著表面上的技術(shù)挑戰(zhàn)，比如實(shí)際部署我們的解決方案。

另一方面，我們面臨著同樣重要的軟挑戰(zhàn)，例如安排、記錄和提供培訓(xùn)。

同樣，推出新解決方案與您如何淘汰要替換的任何工具密切相關(guān) - 無(wú)論這是另一個(gè)應(yīng)用程序還是管理相關(guān)工作流程的其他策略。

例如，如果我們的用例類似于訂單處理，我們不能有任何服務(wù)中斷，那么我們需要圍繞這一事實(shí)制定策略。這可能需要精心設(shè)計(jì)的轉(zhuǎn)換活動(dòng)或更漸進(jìn)的推出。

無(wú)論如何，到此階段結(jié)束時(shí)，您的現(xiàn)實(shí)世界用戶應(yīng)該可以啟動(dòng)并運(yùn)行您的自定義應(yīng)用程序。

9、維護(hù)與優(yōu)化

最后，我們將在解決方案上線后繼續(xù)對(duì)其進(jìn)行管理。從一些相互關(guān)聯(lián)但仍然獨(dú)立的線索來(lái)思考這個(gè)問(wèn)題是很有用的。第一個(gè)是典型的維護(hù)和支持活動(dòng)。

換句話說(shuō)，確保您的應(yīng)用程序繼續(xù)按您的預(yù)期工作，包括查找錯(cuò)誤并推出補(bǔ)丁和修復(fù)。

下一步更關(guān)注更新我們的解決方案。這和維護(hù)之間的界限很模糊——但區(qū)別在于我們所做的任何改變的新穎程度。因此，錯(cuò)誤修復(fù)和全新功能之間的區(qū)別。

最后，我們進(jìn)行了優(yōu)化。也就是說(shuō)，努力讓我們的工具更加有效。實(shí)踐中的情況很大程度上取決于我們的基本目標(biāo)。例如，我們同樣可以依賴性能改進(jìn)、用戶體驗(yàn)優(yōu)化或流程更改。

在這三個(gè)方面，重要的是要記住，我們的需求幾乎不可避免地會(huì)隨著時(shí)間的推移而發(fā)生變化——跨越許多不同的層面。因此，我們可能需要應(yīng)對(duì)全新的挑戰(zhàn)，或者我們可能只是需要隨著時(shí)間的推移增加容量或用戶。

這里需要認(rèn)識(shí)到的重要一點(diǎn)是，定制應(yīng)用程序開發(fā)的本質(zhì)意味著這是我們的問(wèn)題。我們沒(méi)有足夠的供應(yīng)商來(lái)為我們擔(dān)心這個(gè)問(wèn)題。

因此，我們無(wú)法回避的另一個(gè)因素是需要選擇為我們提供很大程度的靈活性和敏捷性的開發(fā)工具和方法。

在接下來(lái)的幾個(gè)部分中，我們將深入探討這些主題。

讓我們首先檢查一下自定義應(yīng)用程序開發(fā)方法。

應(yīng)用程序開發(fā)方法

在我們深入研究可用的具體選項(xiàng)之前，值得停下來(lái)思考一下我們所說(shuō)的方法論到底是什么意思?；旧?，這是我們應(yīng)用于項(xiàng)目的系統(tǒng)或開發(fā)方法。

這決定了我們項(xiàng)目的結(jié)構(gòu)，以及我們使用的工具、相關(guān)人員的角色、相對(duì)的資源占用，以及我們?nèi)绾螛?gòu)建工具的一系列其他元素。

說(shuō)明這一點(diǎn)的最好方法就是直接介入。因此，以下是我們可以使用的主要應(yīng)用程序開發(fā)方法。

傳統(tǒng)方法和瀑布方法

首先，我們有基于瀑布的方法。這些確實(shí)是鎮(zhèn)上幾十年來(lái)唯一的演出，但現(xiàn)在它們不再那么流行了。這個(gè)名字是關(guān)于它們?nèi)绾喂ぷ鞯囊粋€(gè)很好的線索。

基本上，在瀑布框架內(nèi)，自定義應(yīng)用程序開發(fā)項(xiàng)目遵循高度不靈活的固定順序。我們收集我們的需求，然后制定我們將如何預(yù)先實(shí)現(xiàn)這一目標(biāo)的路線圖。

在前一個(gè)階段完成之前，我們無(wú)法進(jìn)入項(xiàng)目的下一階段。一旦我們繼續(xù)前進(jìn)，就沒(méi)有回頭路了。

如果我們從一開始就確切地知道我們想要構(gòu)建什么，并且我們知道我們絕對(duì)不想偏離這一點(diǎn)，那么這很好。然而，在我們需要更多靈活性的情況下，它并不理想。

不幸的是，這是大多數(shù)軟件項(xiàng)目。

（商業(yè)2社區(qū) ）

看，需求發(fā)生了變化。基于瀑布的方法的問(wèn)題在于它們未能考慮到這一事實(shí)。這通常會(huì)給我們留下符合我們要求的解決方案，但并不能真正解決他們要解決的問(wèn)題。

這在很大程度上解釋了過(guò)去二十年左右替代方法論的流行。

敏捷方法論

到目前為止，其中最普遍的是敏捷。這是對(duì)我們一直在探索的傳統(tǒng)方法的一些缺點(diǎn)的回應(yīng)。具體來(lái)說(shuō)，它尋求比瀑布項(xiàng)目提供更多的變化適應(yīng)性。

這需要我們改變構(gòu)建自定義應(yīng)用程序開發(fā)項(xiàng)目的方式。

其關(guān)鍵特征是構(gòu)建軟件的迭代方法。這意味著我們逐步構(gòu)建軟件，分階段可能只持續(xù)幾周或幾個(gè)月——每個(gè)階段都致力于構(gòu)建的特定方面。

這樣，如果我們遇到不可預(yù)見的問(wèn)題、邊緣案例或我們對(duì)核心問(wèn)題的理解發(fā)生變化，我們就可以更靈活地調(diào)整我們的方法。在每次迭代中，我們從需求收集到交付我們需要的功能子集。

我們通常會(huì)對(duì)每次迭代中的內(nèi)容有一個(gè)路線圖，但是當(dāng)我們發(fā)現(xiàn)新的需求時(shí)，這也可能會(huì)改變。

這樣做的好處是，我們可以更加緊密地關(guān)注我們要解決的具體業(yè)務(wù)問(wèn)題。一個(gè)潛在的缺點(diǎn)是，我們?cè)陧?xiàng)目一開始就無(wú)法準(zhǔn)確掌握要構(gòu)建的內(nèi)容。

這使得敏捷構(gòu)建不適合某些類型的應(yīng)用程序項(xiàng)目 - 特別是如果相關(guān)應(yīng)用程序需要以非常特定的方式與項(xiàng)目的其他方面相適應(yīng) - 就像我們之前關(guān)于計(jì)算著陸模塊軌跡的示例。

精益方法論

精益是作為傳統(tǒng)瀑布式思維的替代方案而出現(xiàn)的另一類方法論。這是基于簡(jiǎn)化流程和持續(xù)改進(jìn)的雙重原則。

具體來(lái)說(shuō)，這意味著圍繞四步循環(huán)構(gòu)建開發(fā)項(xiàng)目——識(shí)別、計(jì)劃、執(zhí)行和審查。

因此，我們解決一個(gè)問(wèn)題，弄清楚我們想要如何解決它，實(shí)施我們的解決方案，然后考慮哪些有效，哪些無(wú)效。

不過(guò)，這種配對(duì)開發(fā)方法只適合某些類型的項(xiàng)目。

也就是說(shuō)，由較小的團(tuán)隊(duì)構(gòu)建的相對(duì)簡(jiǎn)單的解決方案，可以輕松管理構(gòu)思和審查會(huì)議。

RAD、公民開發(fā)和無(wú)/低代碼開發(fā)

到目前為止，我們所看到的方法很大程度上假設(shè)我們正在與傳統(tǒng)的開發(fā)團(tuán)隊(duì)合作。然而，這不一定是企業(yè)進(jìn)行定制應(yīng)用程序開發(fā)的一貫方式。

面對(duì)全球合格開發(fā)人員的短缺，許多公司正在轉(zhuǎn)向替代策略 - 要么充分利用現(xiàn)有的開發(fā)人員，要么授權(quán)其他用戶創(chuàng)建自定義應(yīng)用程序。

最值得注意的是，分別通過(guò)快速應(yīng)用程序開發(fā)和公民發(fā)展。

兩者都有可能大大減少輸出解決方案所需的時(shí)間和金錢 - 但這依賴于用正確的技術(shù)支持我們的努力。

這是過(guò)去幾年無(wú)代碼和低代碼開發(fā)平臺(tái)迅速流行的領(lǐng)域之一。

此類平臺(tái)旨在使用戶能夠更快地執(zhí)行常見的開發(fā)任務(wù)，或者完全消除某些類型的開發(fā)需求。

稍后我們將更詳細(xì)地探討其工作原理。

定制應(yīng)用程序開發(fā)工具

這是一個(gè)巨大的主題 - 坦率地說(shuō)，遠(yuǎn)遠(yuǎn)超出了任何博客文章可以全面涵蓋的范圍。相反，值得做的是運(yùn)行我們需要熟悉的工具類。

在這里值得重申的是，定制開發(fā)可以涵蓋絕對(duì)巨大的用例范圍，其中許多用例需要自己的利基工具 - 而且我們也不可能在這里展示全部可能性。

相反，我們專注于最典型的內(nèi)部構(gòu)建?？紤]到這一點(diǎn)，對(duì)于大多數(shù)業(yè)務(wù)應(yīng)用程序，您可能需要記住以下類型的自定義開發(fā)工具。

傳統(tǒng)開發(fā)、編碼語(yǔ)言和框架

我們將從您可能最熟悉的傳統(tǒng)工具方式開始構(gòu)建軟件。硬編碼解決方案。直到最近，絕大多數(shù)自定義應(yīng)用程序都是通過(guò)坐下來(lái)實(shí)際編寫自定義代碼來(lái)構(gòu)建的。

例如，JavaScript、Python、C#、.Net 或任何其他編程語(yǔ)言。

在其中的每一個(gè)中，我們還將依賴各種框架和庫(kù)來(lái)幫助加速不同類型的開發(fā)任務(wù)。

事實(shí)上，這是一種無(wú)處不在的做事方式，您可能永遠(yuǎn)不會(huì)停下來(lái)思考傳統(tǒng)應(yīng)用程序構(gòu)建工具的優(yōu)缺點(diǎn)。

明顯的賣點(diǎn)是——至少在特定語(yǔ)言可以實(shí)現(xiàn)的范圍內(nèi)——我們實(shí)際上只受到我們擁有的編碼技能所能實(shí)現(xiàn)的限制。

缺點(diǎn)是我們需要很高的技能水平才能做任何事情。開發(fā)人員的工資很高，但從技術(shù)角度來(lái)看，內(nèi)部構(gòu)建通常相對(duì)簡(jiǎn)單，因此這里的成本/收益計(jì)算有很大的優(yōu)化空間。

在本文的其余部分中，我們將看到一些實(shí)現(xiàn)此目的的策略。

數(shù)據(jù)管理工具

數(shù)據(jù)管理工具本身就是另一個(gè)大話題。我們之前看到，準(zhǔn)確、有代表性的數(shù)據(jù)是任何數(shù)字解決方案的基礎(chǔ)。毫無(wú)疑問(wèn)，我們?nèi)绾喂芾磉@些數(shù)據(jù)也至關(guān)重要。

最明顯的挑戰(zhàn)與實(shí)際構(gòu)建自定義應(yīng)用程序的數(shù)據(jù)層有關(guān)。

數(shù)據(jù)庫(kù)管理 (DBMS) 工具自然是其中最重要的元素之一 - 包括 MySQL 或 Postgres 等家喻戶曉的名字，以及 GraphQL 和 NoSQL 平臺(tái)等較新的參與者。

然而，對(duì)于許多現(xiàn)代解決方案，我們需要更廣泛地思考數(shù)據(jù)如何在整個(gè)組織中移動(dòng)，而不是應(yīng)用僅考慮某一特定應(yīng)用程序所需的數(shù)據(jù)的孤立思維。

這使得許多 IT 團(tuán)隊(duì)將注意力轉(zhuǎn)向有效的數(shù)據(jù)倉(cāng)庫(kù)和管道解決方案。

請(qǐng)查看我們的數(shù)據(jù)管理工具指南以了解更多信息。

開發(fā)環(huán)境、版本控制和協(xié)作工具

與我們剛才所說(shuō)的硬編碼解決方案不同，還有開發(fā)人員如何以及在何處編寫、部署和協(xié)作代碼的問(wèn)題。

根據(jù)您的團(tuán)隊(duì)規(guī)模和項(xiàng)目的具體情況，您可能在這里有嚴(yán)格的政策，或者您可能為開發(fā)人員提供一定程度的靈活性以使用他們自己喜歡的工具。

像您選擇的 IDE 這樣簡(jiǎn)單的事情可能會(huì)對(duì)項(xiàng)目的成功產(chǎn)生巨大影響 - 不同的平臺(tái)提供各種生產(chǎn)力功能、快捷方式以及對(duì)特定技術(shù)的支持。

版本控制是另一個(gè)重要問(wèn)題，既允許同事在生產(chǎn)中就代碼庫(kù)的不同方面進(jìn)行協(xié)作，又允許他們?cè)诮鉀Q方案上線后維護(hù)和支持解決方案。

托管和部署工具

我們還可以考慮您的開發(fā)團(tuán)隊(duì)將如何部署和托管您的解決方案 - 無(wú)論這意味著使用本地基礎(chǔ)設(shè)施、云平臺(tái)還是混合解決方案 - 每個(gè)解決方案都需要自己的特定工具堆棧來(lái)支持您的工作。

目前，這里的熱門問(wèn)題無(wú)疑是容器化——將運(yùn)行應(yīng)用程序所需的所有資源捆綁到可以在任何環(huán)境中托管或部署的容器中。

我們還需要考慮 DevOps 要求，包括管理容量、基礎(chǔ)設(shè)施監(jiān)控和維護(hù)的平臺(tái)，以及一整套安全性、可訪問(wèn)性和身份驗(yàn)證工具。

稍后我們將了解 Budibase 如何處理自定義應(yīng)用程序的托管和部署。

設(shè)計(jì)工具

以完全不同的方式，我們擁有您的團(tuán)隊(duì)用來(lái)設(shè)計(jì)應(yīng)用程序前端界面的平臺(tái)。

這是我們可能會(huì)看到不同企業(yè)之間差異最大的一個(gè)領(lǐng)域。一方面，我們擁有完全硬編碼的設(shè)計(jì)，依賴于 CSS、HTML、Rails、React、Angular 或其他編碼語(yǔ)言。

另一方面，我們擁有完整的視覺(jué)設(shè)計(jì)工具，例如拖放所見即所得編輯器、應(yīng)用程序構(gòu)建工具和其他平臺(tái)，使我們能夠構(gòu)建界面，而無(wú)需具備太多技術(shù)技能。

然后我們?cè)谶@兩個(gè)極點(diǎn)之間有一個(gè)非常擁擠的空間。

然而，您需要在此處做出的關(guān)鍵決策相對(duì)簡(jiǎn)單。如果您的團(tuán)隊(duì)只構(gòu)建相對(duì)簡(jiǎn)單、重復(fù)的界面，那么每次都從頭開始花費(fèi)精力和費(fèi)用就沒(méi)有多大意義。

例如，Budibase 提供完全自動(dòng)生成的 CRUD 屏幕，使您可以在幾秒鐘內(nèi)輸出工作業(yè)務(wù)應(yīng)用程序。

無(wú)/低代碼開發(fā)工具

最后，我們有低代碼和無(wú)代碼平臺(tái)，我們之前提到過(guò)。簡(jiǎn)而言之，這些旨在加快構(gòu)建自定義應(yīng)用程序的過(guò)程并使之民主化。

但重要的是，我們可以指出這個(gè)市場(chǎng)中的一些不同細(xì)分市場(chǎng)，這些細(xì)分市場(chǎng)有助于我們熟悉。

概念化這一點(diǎn)的一種方法是考慮目標(biāo)用戶。

因此，在市場(chǎng)的一端，我們擁有旨在允許非開發(fā)人員構(gòu)建解決方案的工具。這更像是無(wú)代碼部分，正如您可能期望的那樣，其想法是用戶可以輸出解決方案，而不需要知道如何編碼。

在市場(chǎng)的另一端，我們有針對(duì)專業(yè)開發(fā)人員的工具。這里的核心思想是加速特定類型的構(gòu)建任務(wù)，而不是必然降低進(jìn)入門檻。

正如您可以想象的那樣，兩極都需要權(quán)衡。使用更易于訪問(wèn)的無(wú)代碼工具，您通常會(huì)看到相應(yīng)的較低水平的靈活性或?qū)Ω嗬δ艿闹С帧?/p>

相比之下，更復(fù)雜的工具（尤其是傳統(tǒng)供應(yīng)商提供的工具）通常只有當(dāng)您鎖定在更廣泛的生態(tài)系統(tǒng)中時(shí)才能發(fā)揮最佳性能。

稍后我們將看到 Budibase 如何融入市場(chǎng)。

定制開發(fā)需要多少錢？

這是一個(gè)重要的問(wèn)題，我們今天已經(jīng)多次提到過(guò)。這顯然是一個(gè)重要的考慮因素，但也是一個(gè)很難概括的問(wèn)題。我們可能會(huì)輕率地問(wèn)一根繩子有多長(zhǎng)？

這有點(diǎn)陳詞濫調(diào)，但它指出了一個(gè)重要的原則。

也就是說(shuō)，無(wú)數(shù)因素決定了您開發(fā)自定義應(yīng)用程序的成本 - 尤其是我們之前探討的有關(guān)如何選擇構(gòu)建它的所有問(wèn)題。

我們需要應(yīng)對(duì)的另一個(gè)不幸的現(xiàn)實(shí)是，定制應(yīng)用程序項(xiàng)目因超出預(yù)算而聲名狼藉。

（言鼎科技）

這里的風(fēng)險(xiǎn)特別高——尤其是因?yàn)榕c開發(fā)相關(guān)的高昂勞動(dòng)力成本。

我們有很多可以依賴的策略來(lái)減輕這種風(fēng)險(xiǎn)。我們不能低估首先獲得準(zhǔn)確成本估算的作用。

除此之外，我們還可以通過(guò)利用首先減少開發(fā)項(xiàng)目資源占用的策略來(lái)大大降低預(yù)算超支的風(fēng)險(xiǎn)。

我是否需要內(nèi)部開發(fā)團(tuán)隊(duì)來(lái)構(gòu)建自定義應(yīng)用程序？

還值得停下來(lái)更深入地思考誰(shuí)提供了我們的定制應(yīng)用程序開發(fā)。您的情況的答案可能與您的競(jìng)爭(zhēng)對(duì)手有很大不同，因此了解其外觀的不同排列非常重要。

但總的來(lái)說(shuō)，我們有三個(gè)選擇：

1. 內(nèi)部開發(fā)人員。

2. 非開發(fā)人員的內(nèi)部同事。

3. 外部開發(fā)人員。

理論上，您也可以選擇外部非開發(fā)人員，但很難想出為什么這樣做的原因。因此，讓我們堅(jiān)持三個(gè)現(xiàn)實(shí)的選擇。

每個(gè)都有優(yōu)點(diǎn)和缺點(diǎn)。我們已經(jīng)看到了這對(duì)于內(nèi)部開發(fā)人員和外包項(xiàng)目的影響。

但是依靠非開發(fā)人員來(lái)構(gòu)建解決方案又如何呢？您可能會(huì)對(duì)此表示懷疑，這是可以理解的，因?yàn)檫@對(duì)許多企業(yè)來(lái)說(shuō)都是未知的領(lǐng)域。正如我們之前暗示的，這里的關(guān)鍵是為您的團(tuán)隊(duì)提供正確的無(wú)/低代碼工具。

那么有哪些優(yōu)點(diǎn)和缺點(diǎn)呢？

這里的最大賣點(diǎn)是速度和成本。兩者都與我們不需要給開發(fā)人員增加負(fù)擔(dān)這一事實(shí)有關(guān)。因此，我們避免了支付他們可能更高的勞動(dòng)力成本以及始終存在的開發(fā)積壓的需要。

缺點(diǎn)是我們可以期望非專家構(gòu)建任何定制解決方案。畢竟，專業(yè)開發(fā)人員的高薪是有原因的。我們?cè)谶@里受到團(tuán)隊(duì)技能以及我們?yōu)樗麄兲峁┑墓ぞ吖δ艿南拗啤?/p>

由于這種權(quán)衡，許多企業(yè)將依賴非開發(fā)人員，他們可以構(gòu)建有問(wèn)題的解決方案，但仍然求助于專家來(lái)解決更復(fù)雜或關(guān)鍵業(yè)務(wù)的用例。

定制開發(fā)的其他注意事項(xiàng)

在結(jié)束之前，我們還需要了解有關(guān)自定義應(yīng)用程序開發(fā)的其他信息嗎？

當(dāng)然，我們并未涵蓋您可能遇到的所有疑問(wèn)或問(wèn)題。相反，我們的目標(biāo)是覆蓋盡可能廣泛的領(lǐng)域，以便您對(duì)將遇到的廣泛決策有充分的了解。

盡管如此，我們?nèi)匀豢梢杂行У靥剿饕恍┡c我們迄今為止看到的任何類別都不完全相符的關(guān)鍵點(diǎn)。

一種觀點(diǎn)是，定制應(yīng)用程序開發(fā)總是與某種潛在的業(yè)務(wù)問(wèn)題或痛點(diǎn)緊密地交織在一起。因此，構(gòu)建一個(gè)全新的應(yīng)用程序通常并不是我們唯一的選擇。

許多企業(yè)犯的一個(gè)大錯(cuò)誤是，追求可以通過(guò)更好的流程輕松解決的問(wèn)題的技術(shù)解決方案。因此，在我們致力于可能昂貴的定制解決方案之前，探索我們所有的選擇非常重要。

即使我們無(wú)法用非技術(shù)解決方案完全解決我們的用例，尋求這樣做通常會(huì)給我們帶來(lái)更簡(jiǎn)化的流程，因此更容易數(shù)字化。

使用 Budibase 快速構(gòu)建自定義應(yīng)用程序

最后，讓我們考慮一下如何能夠更快、成本更低地構(gòu)建更好的應(yīng)用程序。這確實(shí)是一個(gè)大膽的主張，但我們認(rèn)為您會(huì)同意 Budibase 不僅僅提供這里的服務(wù)。

這就是世界各地?cái)?shù)以萬(wàn)計(jì)的企業(yè)選擇 Budibase 構(gòu)建自定義應(yīng)用程序的原因。

我們的開源、低代碼平臺(tái)

Budibase 為時(shí)間緊迫的開發(fā)人員和非專業(yè)人士提供了令人難以置信的體驗(yàn)。我們的開源低代碼平臺(tái)具有直觀的設(shè)計(jì)工具、自動(dòng)生成的 CRUD 屏幕和廣泛的第三方數(shù)據(jù)支持。

查看我們的功能概述 以了解更多信息。

連接您的數(shù)據(jù)

Budibase 在數(shù)據(jù)連接方面處于領(lǐng)先地位。我們?yōu)?MySQL、MSSQL、Postgres、Airtable、Mongo、Couch、REST、S3、Oracle、Google Sheets 等提供專用連接器。

我們還提供自己的內(nèi)置數(shù)據(jù)庫(kù)，支持 CSV 上傳。為您的自定義應(yīng)用程序構(gòu)建功能齊全的數(shù)據(jù)層從未如此簡(jiǎn)單。

部署和托管

選擇 Budibase 可以完全控制托管工具的方式和位置。我們通過(guò) Kubernetes、Docker、Digital Ocean 等提供自托管?；蛘?，選擇 Budibase Cloud，讓我們處理一切。

請(qǐng)查看我們的定價(jià)頁(yè)面 ，了解有關(guān)這兩個(gè)選項(xiàng)的更多信息。

設(shè)置角色并控制訪問(wèn)

Budibase 提供高度可配置的基于角色的訪問(wèn)控制。授予每個(gè)用戶組滿足其需求的完美訪問(wèn)級(jí)別，最大限度地提高安全性、效率和可用性。

使用簡(jiǎn)單的下拉編輯器和自定義條件規(guī)則在數(shù)據(jù)源、查詢、屏幕或單個(gè)組件級(jí)別實(shí)施 RBAC。

構(gòu)建自動(dòng)化

借助 Budibase，自動(dòng)化業(yè)務(wù)規(guī)則變得輕而易舉。我們提供直觀的、基于流程圖的界面，用于組合、嵌套、配置和循環(huán)整個(gè)內(nèi)置自動(dòng)化操作庫(kù)。

您甚至可以使用 Zapier、REST、WebHooks 等第三方事件作為自動(dòng)化觸發(fā)器和操作。

自定義插件

我們的理念是默認(rèn)的簡(jiǎn)單性，以及需要時(shí)的可擴(kuò)展性。沒(méi)有什么比我們的自定義插件更好地證明了這一點(diǎn)。使用我們專用的 CLI 工具構(gòu)建您自己的組件和數(shù)據(jù)源。

沒(méi)有其他低代碼平臺(tái)可以達(dá)到這種定制級(jí)別。查看我們的插件文檔 以了解更多信息。

50 多個(gè)免費(fèi)應(yīng)用模板

正如您所知，我們對(duì) Budibase 的能力充滿信心。但為什么要相信我們的話呢？為了證明我們的平臺(tái)是由什么組成的，我們構(gòu)建了五十多個(gè)免費(fèi)的、可定制的、隨時(shí)可用的應(yīng)用程序模板 。

要開始以快速、經(jīng)濟(jì)高效的方式開發(fā)自定義應(yīng)用程序，請(qǐng)立即免費(fèi)注冊(cè) 言鼎科技。