微笑琳----
相對而言吧，如果你在一家開發編譯語言及編譯器的公司，什麼是業務？如果你在一家開發操作系統的公司，什麼是業務？如果你在一家開發數據庫的公司，什麼是業務？如果你在一家開發中間件的公司，什麼是業務？如果你在一家開發界面組件的公司，什麼是業務？如果你在一家提供erp基礎服務的公司，什麼是業務？如果你在一家對erp進行二次定製開發的公司，什麼是業務？可能是因為我們太淺顯了，所以回答這些問題時總把自己當搬運工而不是創造者，才造就了寫業務代碼很low的感覺。
無盡的代碼
作為一個程序員，我也是寫代碼的，我不覺得寫業務代碼很low。
1.首先大家所認為的業務代碼就是一些和業務相關的增刪改查，涉及到的技術點相對來說是固定的，寫熟了之後，就是複製，粘貼，不存在什麼技術阻礙，很多人就覺得非常的簡單，沒有技術含量，做這些工作的人也顯得非常的low，如果你也是這樣認為的，那你就錯了，因為寫業務代碼的基本都是初級，中級的程序員，工作經驗有限，不具備寫一些公共方法和接口的能力，但是並不代表以後能力不會提升，如果持續努力，也會成長為高級程序員或是架構師，誰天生就是高級程序員呢，不都是一點點積累起來的嗎？而且就算是寫業務代碼也不能就是low呀，有些業務場景是非常複雜的，邏輯必須十分嚴謹，稍有差錯可能就會出現bug，對公司造成巨大的損失，不是寫業務代碼就是很容易的。
2.除了業務代碼就是非業務代碼了，比如開發數據庫，開發框架，或是寫一些公共的方法或是接口，供初級開發者調用。寫非業務代碼的人技術也不一定就非常的厲害，因為就算是開發框架或是數據庫之類的項目，也不一定都是高級開發，也會有一些水平較低的開發，因為寫業務代碼還是非業務代碼和項目也有關係，如果你們團隊開發的是開發框架或是數據庫這種的項目，那麼你們團隊沒有人寫業務代碼，也不能說明你們團隊每個人技術都很厲害，只是項目性質不一樣罷了。
3.業務代碼這個詞看你的理解吧，我認為其實所有的代碼都可以成為是業務代碼，無論開發什麼產品，都是有業務需求的，有了需求才有開發的動力，對於開發數據庫來說，數據庫的需求就是業務，對於開發框架來說，框架的功能就是業務，所以我認為廣義上來講都是業務代碼，沒有非業務代碼這一說，所以具體看你認為業務的定義是什麼了。不過無論如何也不應該去嘲笑或是去貶低別人吧，嘲笑或是貶低一類人就更不應該了。
JAVA異世界
非著名程序員：換個角度看世界，另闢蹊徑，提供新思路，優質的回答。
我發現很多程序員對於處理業務邏輯都是「嗤之以鼻」。感覺自己天天寫業務邏輯代碼，改 Bug 都沒有時間學習，沒有時間實現個人成長？
但是，作為程序員來講，如果不是做底層基礎技術研發的話，大部分的工作不就是做這些擰螺絲的工作嗎？其實擰螺絲有那麼容易嗎？可能擰螺絲很容易，但是擰好螺絲就不那麼簡單了。
別小瞧業務邏輯代碼，如果真正寫好，要把邏輯寫得清晰簡單易用，功能健壯穩定，性能同時達到要求的話，其實是挺難的。
最近和一個剛接觸編程的程序員聊天，問他喜歡編程嗎？他說非常喜歡，所以就幹了這行。由於是初學者，前期興奮，喜歡正常，幹了兩個月後，再問他喜歡嗎？他說最近有些浮躁，好像並不是那麼喜歡了，感覺編程就那樣，整天寫寫界面，處理一下業務邏輯，改改 Bug ，真沒什麼。
其實很多程序員都跟他一樣，都在痛苦的編程，一方面對自己有更高的要求，一方面又嫌棄現在寫的代碼沒有技術含量。又有更高的要去和希望，又嫌棄現在的工作，就是不思考出現的原因，不去付諸行動。還不停的抱怨：感覺自己天天寫業務邏輯代碼，改 Bug 都沒有時間學習，沒有時間實現個人成長？
到這裡，我們不禁一問：那我們該如何擺脫這種現狀呢？其實很簡單，我們應該擺正自己的態度和觀點，正確看待寫業務邏輯這些代碼就行了。
堅持不懈的寫好業務邏輯代碼
就像我在上面說的：別小瞧業務邏輯代碼，如果真正寫好，要把邏輯寫得清晰簡單易用，功能健壯穩定，性能同時達到要求的話，其實是挺難的。
所以，我們要正確看待寫業務邏輯的代碼，應該擺正心態，堅持不懈的去寫，所謂量變引起質變，就是這個道理。寫業務代碼，積累代碼量，一力降十會，在積累了巨量的代碼量之後，幾乎任何所謂的有技術含量的東西都構不成挑戰性。當然，要想真正的通過自己寫業務代碼，寫好業務代碼還應該有接下來的這個思考。
業務邏輯代碼同樣可以玩出很多花樣
其實業務邏輯代碼一樣可以玩出很多花樣，而這才是能夠提升你能力的本質。比如：你寫了一個處理單任務的業務邏輯，雖然滿足了用戶的需求，但是你這時能不能對自己有一個更高的要求呢？單任務雖然是功能實現了，但是效率可能不行，處理慢，那搞個多任務處理的邏輯怎麼樣？任務池、線程池、內存池、併發、同步等等這些技術點都來了。如果你對自己有這樣的要求，而你自己有追求的話，就會進一步思考如何去做到這些，你做到了，你能力就提升了。
同樣，很多人感覺處理業務邏輯，就是一些各種循環，條件判斷，只要邏輯稍微嚴謹點，功能就都沒問題，就都實現了，確實是這樣的。這就是你對於業務邏輯沒有興趣的根點所在。
那你為什麼不想想：如何使用循環和條件判斷可以提升效率呢？滿足了功能的那些需求，是不是有些地方可以優化一下呢？是不是可以提升一下性能呢？
其實，這個技術的進步和積累，就在於自己內心對自己有沒有更高的要求和追求。這是大實話，也是大白話。很多人就感覺只要實現了功能需求就夠了，滿足了用戶就行了。然後，這個項目完事了，下個項目遇到差不多的邏輯，還是這麼處理，又完事了，每個項目，每個功能都是這樣重複的處理，從來不思考最優的實現方式，你感覺能夠進步嗎？你能不煩氣嗎？十年如一日的工作，10 年也就積累了一年的工作經驗，在重複使用。
業務邏輯的最優方式，就是思考如何大道至簡
通過一個業務邏輯實現一個功能，基本上只要是程序員，腦子不笨，都能做出來，做出來是一回事，但是做好是另外一回事。大道至簡，我們要做就得想辦法做到最好。這裡的好有很多層意思。
比如：你寫的業務邏輯代碼 是否能夠做到準確，穩定，高效，易讀，易擴展，易維護，兼容性強呢？問自己一句，如果你能做到這些，那確實是好。如果做不到，你還是處理初級水平，當然不行，這就是你在工作中提升能力的機會。別說沒時間，都是藉口。
精益求精是對代碼大道至簡的永恆的追求，也是我們在處理業務邏輯代碼中不斷提高自己能力的過程。
明明自己水平初級，就容易驕傲自滿，感覺可以了，我想學更高的技術，那麼更高的技術是自己在處理業務邏輯中一步一步積累出來的，不是幹了初級的活，不用積累，直接學高級的技術，就能高級了。
我特別喜歡網上有個網友寫的一段話：
有的人在一個行業寫 10 年業務邏輯代碼，那他就是這個行業的大牛，
有的人在各行各業寫 10 年不同項目代碼，那他就是互聯網界的大牛，
有的人喜歡精於鑽研某一項技術，那他就是這個領域的專家，
有的人善於整體把握系統的架構，那他就是軟件行業的專家，
只要你喜歡你的工作，你就會去主動的學習，成長。
其實很多技術大牛和技術專家，都是從業務邏輯做起，慢慢積累思考起來的。比如：在處理業務邏輯之前，會思考如何設計這個架構，可以讓代碼更好的擴展和維護。在處理業務邏輯的時候，思考如何的處理才能提高性能和效率？一步一步的實驗和總結，積累，才成就了今天的成績。
所以，不要對處理業務邏輯嗤之以鼻，不要以為能夠滿足需求就夠了。你重複不思考的粘貼和複製肯定是不行的，必然會對編程失去興趣，自然無法更好的成長和進步。應該在編程的過程中追求更高的要求，尋找更高的興趣，這樣才能讓你持續進步，從而進階。
非著名程序員
首先，我認為寫業務代碼不“low”，但是大部分不假思索拷貝粘貼的業務代碼比較“low”，換句話說就是所謂的五年工作經驗就是把第一年的工作重複了五遍。
技術人員成長一般有兩條線，一條是成為技術專家，一條是成為領域專家。所謂的轉管理我理解也就是領域專家，畢竟不懂得領域知識是無法做好管理的，比如說你是互聯網金融某個業務部門的leader，那麼你肯定要懂金融。領域知識就是在不斷的寫業務代碼和思考中積累起來。
還有一個問題就是如何定義業務，比如說“實現一個修改訂單功能”，這是一個業務需求，看起來很low，但是如果業務需求改成“實現一個修改訂單功能，要求在有限資源的情況下併發10k，響應時間不高於10ms”，那這個需求就有挑戰。說這個問題想說明白一件事情，如果做業務不要停留的在業務表面，僅僅滿足於實現功能，要主動思考。
最後總結一下，沒有最好的技術，只有最適合業務的技術。技術是內功，業務是招式，內功不足，後續成長乏力，沒有招式，內功也不能發揮威力。這是也很多互聯網創業公司做大了之後要技術轉型的原因。
攻城獅Bilbo
業務開發的難點不在於代碼，而在於數據模型建立，以及代碼組織結構。在研發初期，可能有非常多的概念要去理解，然後逐漸建立概念、邏輯、物理數據模型。在研發中期，要充分利用設計模式進行代碼結構規劃，以便業務的更改，常見的比如有通過修改配置改變業務模式，通過配置動態組合業務流程等。在交付軟件後，難點就在於如何用最小的代價去直線客戶千奇百怪的需求調整以及新需求，避免大改、推翻重寫。儘量能通過流程替換、流程複用、配置修改等方式，一句最小的代價去實現。所以我個人認為，業務開發的難點在於對行業的數據模型、業務模型的理解，以及對面對客戶突然來的需求的巧妙處理。
潘燁
林子大了什麼鳥都有，不知道你說的有人是指多少比例的人。我的理解代碼可以分為兩類：1:工具欄或者框架類2:業務類。寫工具類偏重於健壯可拓展可複用；寫業務類偏重於邏輯嚴謹沒有漏洞，化繁為簡。畢竟有些時候需求或者業務都不甚清楚他們想要的邏輯。有時候複雜的業務流程你捋都不順，更別說代碼寫的好了。當然，工具類到高深，工具好用，框架優秀確實需要的技術功底深厚，比業務類要考慮的東西也多，但不代表寫業務類代碼很low。當然，不管寫什麼代碼，完全複製黏貼而不去考慮與實際場景結合，不去想為什麼？有沒有更好的處理方案是比較low的
半仙絆神兒
寫業務代碼，看寫什麼樣的業務代碼了！所有的技術都是為業務部門服務的，當前許多公司都成立中臺部主要解決公司一些公用的技術模塊，避免重複造輪子；中臺雖然有一定的技術要求，但是大部分績效都還是靠業務部門去掙，像騰訊大部門人都知道微信或者QQ，但極少有人知道TEG；如果在一些發展比較好的業務部門，那部門的績效槓槓的，年終獎金也是很有保證的！
南境之南
業務代碼就是技術難度不大，多是業務邏輯的代碼。
有些人認為寫業務代碼很low，應該是出於技術挑戰角度來說的，如果沒有什麼技術難題，技術成長就比較慢。
但是無所謂low不low的，業務寫好了依然可以成為一方大牛，技術就是為業務服務的不是嗎？
服務器二三事
有人覺得low
1.可能是覺得沒有什麼技術含量吧，用的都是一些成熟的技術框架，就是一些增刪改查而已，但是這並不意味著寫業務代碼就很簡單，因為這裡麵包含著業務邏輯，業務邏輯有簡單的也有複雜的，如果對業務邏輯業務背景不理解或理解不透就很難實施下去，其實現在很多專家級別的程序員並不是技術有多牛，而是對某個行業領域有比較深刻的理解。
2.還有可能就是內心裡對業務就很輕視，這個更是不應該的，因為技術是為業務服務的，是業務讓技術變的有價值。
小小青年ovo
業務代碼不low，low的是天天crud。業務有複雜也有簡單，複雜的業務對抽象能力，全局思考，細節處理要求很高。這麼說吧，阿波羅登月也是業務，銀行系統也是業務，erp也是業務，細化一下，office也是業務。
