我覺得首先大家要理解什麼是“業務程式碼”，業務程式碼是一個相對的概念。

2.對於一個做純上層應用的公司來說，業務程式碼就是基於一個作業系統為客戶量身定製對應的app,並實現對應的應用邏輯。

3.對於一個微型控制器設計廠商，業務程式碼就是底層架構裸機的具體實現和各個外設驅動的框架設計。

4.對於一個設計作業系統的開發人員來說，業務程式碼就是架構設計、記憶體管理、排程機制優化、優先順序管理、程序間通訊機制優化、執行緒管理和核心完善等等。

所謂”業務程式碼”都是相對的，沒有參考系怎麼談。像作業系統，站在作業系統核心提供方的角度看，上層所有的應用框架，程序服務，都是業務程式碼，我是為他們服務的。技術只是工具，業務實現才是目的，站在不同供應商的角度，只要涉及程式碼的地方都可以稱之為業務程式碼。所以站在這個維度，如果要說業務程式碼“LOW”,那就沒有程式碼是不"LOW"的了。

1.判斷一個程式設計師的優秀程度已經不單單看你寫了多少應用型的程式碼，設計了多少應用框架，而是你懂不懂底層驅動邏輯，懂不懂作業系統核心，懂不懂核心裁減等等。所以這種情況會經常出現在面試過程中，面試官會因為你不懂底層驅動、不懂核心而給你比較低的薪水。

2.懂得寫業務程式碼的人，他的程式設計師基礎並不一定就牢固。因為上層應用可能對業務比較看重，但是對於一些特定的語言的程式設計並沒有那麼嚴謹。能用就可以，所以會自然而然的認為這樣的程式設計師“LOW”。而一個會寫底層驅動的人，他考慮更多的是基礎程式碼的安全、嚴謹性和容量問題等等，他們的語言基礎相對來說要牢固很多。

3.技術負責人一般都是全能型的人。會寫底層驅動或者更懂作業系統核心的人更容易成為技術的領頭人。而那些只會“業務程式碼”的人，放在大部分公司,一般都不會有太多的上升空間。

比如對於領導來說，那就不一樣了。你將“業務程式碼”的需求迭代了，完善了，提前任務完成了，客戶很滿意。那領導不會認為你是一個很“LOW”的程式設計師。你很高階，領導很欣賞，“後果”很舒服。但是對於一個面試官來說，你就會點上層應用的呼叫和設計。我為什麼要給你這麼多薪水？雖然會被想成很"LOW"，但是也是現實。

業務程式開發相對於底層基礎架構層的程式開發有所不同：

業務開發的時間比較緊，變化快。

這個特點導致程式設計師沒有時間重構程式碼，或者不願意重構程式碼，而是用最簡單粗暴的複製黏貼的方式快速實現業務邏輯。其實所有的複製黏貼都意味著需要重構。

底層系統的開發，一般是架構師和高階程式設計師來設計和控制專案時間。相對來說，開發週期長，變化緩慢。會更加註重架構的合理性和穩定性，而且會不斷重構和改進。

業務開發一旦完成，只要平穩執行就不會有人再回來補技術債務，不會把它寫得更好。除非這個業務爆發了，不得不從新架構以支援更高的併發。如果上線之後表現不佳，很可能下線不再維護。所以公司也不太願意花太多精力在一個還沒有被市場認可的產品專案上。

而底層架構框架的專案會在不同的產品專案中不斷應用。不斷地進化。就像Spring之類的開源框架一樣，不斷的升級和完善。

相對來說，業務開發程式設計師會花大量的時間學習和理解業務知識；而底層框架程式設計師更多的時間在學習技術架構。如果業務知識在行業內通用，比如財務，金融行業知識。那麼長期的積累對業務開發也是很有幫助的。如果業務是很小眾的，甚至，這幾個月做這個業務，下半年又做另一個業務，做的時候也一知半解，就像很多外包一樣，那就沒有什麼業務沉澱了。

我個人覺得能理解業務需求比較重要。

剩下的就是寫程式碼了。

底層，cuid無所謂，都是為業務服務的。

正確理解業務，表達出來，甚至拉到業務才是核心。

其實是不low 但是如果不深入業務做業務專家，僅僅是crud的話，還真的挺low的。其實程式碼可以分為底層純平臺程式碼和業務程式碼，但是底層並不需要太多人。做底層並不一定高階，做業務層能接觸到更多業務，更容易進步

業務程式碼就是技術難度不大，多是業務邏輯的程式碼。

有些人認為寫業務程式碼很low，應該是出於技術挑戰角度來說的，如果沒有什麼技術難題，技術成長就比較慢。

但是無所謂low不low的，業務寫好了依然可以成為一方大牛，技術就是為業務服務的不是嗎？

業務開發的難點不在於程式碼，而在於資料模型建立，以及程式碼組織結構。在研發初期，可能有非常多的概念要去理解，然後逐漸建立概念、邏輯、物理資料模型。在研發中期，要充分利用設計模式進行程式碼結構規劃，以便業務的更改，常見的比如有通過修改配置改變業務模式，通過配置動態組合業務流程等。在交付軟體後，難點就在於如何用最小的代價去直線客戶千奇百怪的需求調整以及新需求，避免大改、推翻重寫。儘量能通過流程替換、流程複用、配置修改等方式，一句最小的代價去實現。所以我個人認為，業務開發的難點在於對行業的資料模型、業務模型的理解，以及對面對客戶突然來的需求的巧妙處理。

相對而言吧，如果你在一家開發編譯語言及編譯器的公司，什麼是業務？如果你在一家開發作業系統的公司，什麼是業務？如果你在一家開發資料庫的公司，什麼是業務？如果你在一家開發中間件的公司，什麼是業務？如果你在一家開發介面元件的公司，什麼是業務？如果你在一家提供erp基礎服務的公司，什麼是業務？如果你在一家對erp進行二次定製開發的公司，什麼是業務？可能是因為我們太淺顯了，所以回答這些問題時總把自己當搬運工而不是創造者，才造就了寫業務程式碼很low的感覺。

我覺得寫業務程式碼是最美麗的，沒有普天下的寫業務程式碼的吃啥？沒有普天下的寫業務程式碼的穿啥？吃穿都沒了你還臭美啥？

林子大了什麼鳥都有，不知道你說的有人是指多少比例的人。我的理解程式碼可以分為兩類：1:工具欄或者框架類2:業務類。寫工具類偏重於健壯可拓展可複用；寫業務類偏重於邏輯嚴謹沒有漏洞，化繁為簡。畢竟有些時候需求或者業務都不甚清楚他們想要的邏輯。有時候複雜的業務流程你捋都不順，更別說程式碼寫的好了。當然，工具類到高深，工具好用，框架優秀確實需要的技術功底深厚，比業務類要考慮的東西也多，但不代表寫業務類程式碼很low。當然，不管寫什麼程式碼，完全複製黏貼而不去考慮與實際場景結合，不去想為什麼？有沒有更好的處理方案是比較low的

業務才是核心，理解業務比理解程式碼顯得更重要！這是驅動你完成整個系統的引擎，同時也能讓你少有彎路設計出更為合理的表結構

寫程式碼分為兩種。

一種叫做研發向，也就是憑空造東西，比如底層核心庫，作業系統這類，就好比蓋樓打地基的人。這種需要涉及到的技術方面就非常專業和深入，也就是我們常常羨慕的技術大牛。

另一種就是題主說的業務向，一般都是應用層面。業務向裡面需要很高技術的就不是程式設計人員了，而是業務架構人員，他們不需要會程式設計，他們需要的是業務流程和業務架構設計，就好比蓋樓設計樓內格局的人。但是業務向的程式設計人員，往往只是相關開發語言的庫使用的熟練，然後根據業務流程和架構圖紙堆砌功能就可以了。就好比蓋樓砌磚的工人或者水泥匠之類，當然也需要程式設計知識，但是他們傾向於如何使用現成的庫來完成功能，而不會深究這些庫的核心功能到底如何實現的，好比他們只需要會使用蓋樓的材料，而不必考慮這些材料是如何造出來的一樣。也不需要考慮這個室內佈局到底是為什麼，也不比考慮更好的方案。

當然在他們熟悉的函式使用方面他們也可稱之為專家，但是並非不可替代。我就是說他離職了不要緊，再找一個熟練工種馬上就可以上手。因為只是照著已有的設計實現功能就好了。

所以才會有很多人認為寫業務程式碼的人比較low,這只是從技術方面的對比，但是社會卻不能缺少這些人，如果只有畫圖紙的人，卻沒有磚瓦匠，那誰來蓋樓呢。只不過畫圖紙的人比較稀缺，磚瓦匠卻很多，而且很容易找到替代者。

只知道照客戶需求寫業務程式碼，不知道提煉抽象當然很low，但能做到將客戶需求抽象為更高層次的需求，做到以不變應萬變，或者隨機應變，這才是體現價值的地方。

業務程式碼就是：

接收使用者的請求——>解析使用者的請求意圖——>根據使用者的請求操作資料庫——>將操作結果返回給使用者。

表面看起來確實很low。

如果實行：多使用者、實時響應、容災處理、資料恢復和備份、業務的頻繁變動、伺服器的壓力分流……還是挺麻煩的。

麻煩的原因並不是業務本身，而是能夠得到一個適用於當前業務的系統工具，No low的程式碼就是在於製造這些工具的程式碼。