這個問題也是困擾我的一個問題，我入職沒多久，也開始在思考這個問題了。

我目前想的是找到自己的核心競爭力，目前自己找到的定位是多學習一些底層的東西，另外，提高自己解決故障的能力，這樣我們會更加具備競爭力

作為一名科技領域的從業者，我來回答一下這個問題。

在產業網際網路時代，由於產品迭代的速度不斷加快，所以傳統的開發方式必然需要升級，而此時“平臺化”和“低程式碼化”就成為了一個重要的發展趨勢。

低程式碼化時代，程式設計師在發展過程中應該注重以下幾個方面：

第一：應用級程式設計師要注重平臺知識的積累。對於廣大應用級程式設計師來說，對於平臺知識的掌握能力將在一定程度上決定自身的開發能力，而且隨著雲計算平臺、大資料平臺、人工智慧平臺的不斷髮展，程式設計師是否掌握這些平臺知識，會在很大程度上決定自身的職業生命週期。

第二：研發級程式設計師要注重基礎性創新。相對於應用級程式設計師來說，研發級程式設計師要注重基礎性創新，簡單的說就是“搭平臺”。從近些年來計算機專業研究生的就業情況來看，大量的研究生選擇了大型科技公司（網際網路），重點的工作內容之一就是進行各種平臺的研發。

第三：注重行業知識的積累。在產業網際網路時代，程式設計師對於行業知識的積累程度，對於自身的職業生命週期將起到重要的影響，因此不論是研發級程式設計師還是應用級程式設計師，都應該注重行業知識的累積。整體上來看，在平臺化開發時代，程式設計師的職業生命週期將會有所延長，其中一個重要的原因就是程式設計師在低程式碼時代，會有更多的時間來不斷深入學習行業知識。

低程式碼開發或者無程式碼開發是軟體開發的發展趨勢，隨著技術的不斷積累，業務模型的日趨成熟，這種趨勢將會越來越明顯。

面對這種趨勢，開發人員可能會發生如下分化：

1、繼續目前的編碼工作，但是會沉下去，進行元件或介面的編碼。低程式碼或者無程式碼並非表示不需要程式碼，只是程式碼沉到元件層，所有的業務模型都是由元件或者介面組成，而元件或者介面仍然需要開發人員去實現。另外，由於業務的逐漸雲化、服務化，也將使程式碼開發從企業遷移到“程式碼工廠”，這種程式碼工廠實際上是大型的軟體企業，他們專門提供軟體元件和介面開發，對外提供用於組裝業務模型的元件或者服務介面。

2、轉向業務分析。業務分析將在未來的一段時間內一直存在，業務分析人才仍然會被大企業大量聘用，但是，這些業務分析人員需要精通行業應用和業務模型，所以對經驗和知識積累要求非常高。

3、很多開發人員會轉向測試和實施。儘管自動化測試和自動化部署已經出現，但是測試人員和實施人員仍然需要，但是會淘汰其中低層次的人員，留下一些對業務和技術都比較精通的複合型人才。實施人員可能需要做大量的配置開發和軟體產品的部署。

4、一部分開發人員會轉向管理和售前。無論是低程式碼還是無程式碼開發，本質上仍然是專案或產品，因此，專案管理、產品經理、售前拓展仍然是必要的。一些精通業務和技術的開發工程師會轉向這些型別的崗位。

使用低程式碼開發平臺類似於使用IDE，因為它包含了一套可以供開發人員直接使用的功能，和一套供開發人員使用的工具。然而，它實際上能提供的遠遠超過一個傳統的IDE。簡單來說，低程式碼開發就是將已有程式碼的視覺化模組拖放到工作流中以建立應用程式的過程。由於它可以完全取代傳統的手工編碼應用程式的開發方法，技術嫻熟的開發人員可以更智慧、更高效地工作，而不會被重複的編碼束縛住。相反，他們可以將精力集中於建立應用程式的10%部分，並使其具有與眾不同的功能。

使用低程式碼開發平臺，減少了很多繁瑣重複的程式碼工作，程式設計師不用編寫數萬行的程式碼，只需要編寫部分關鍵的程式碼透過視覺化操作介面以及封裝好的功能模組即可快速構建BPM系統、KM文庫、OA協同、公文督辦、專案管理、等一些列職能類和業務類管理系統。低程式碼平臺支援多個行業領域及需求場景，可以高效提供需求建模、系統設計、開發部署、模擬測試、執行維護和版本更新的等軟體開發生命週期支援。

同時低程式碼配置即開發、所見即所得的特性降低了應用軟體的開發難度，程式設計師可以從繁瑣的功程式碼當中抽身，把精力用到關鍵的底層邏輯上，能節省80%以上開發工作量。

像一些低程式碼開發平臺可以提供全部原始碼，保障使用者在不同的應用階段、不同層次和不同規模的服務需求都能得到滿足，確保沒有任何後顧之憂。平臺採用業內領先的SpringBoot微服務架構、支援SpringCloud模式，完善了平臺的擴增基礎，滿足了系統快速開發、靈活拓展、無縫整合和高效能應用等綜合能力。

同時支援多種不同的部署方案，可以根據不同的使用者線上數量及併發數量選擇具體的部署方式，通常系統各操作響應時間在0.5-3S以內。平臺不限部署數，使用者數、併發數。一次採購可重複使用，大大節省軟體採購成本。