業務是一切的基礎，不要只是滿足把這個業務功能實現了。

在技術上，做需求的時候多考慮拓展性，重用，程式碼優雅等等，再者就是效能最佳化相關。

在非技術上，我認為開發不僅僅只是寫程式碼，在做業務需求時候要思考為什麼要做這個需求，做了需求可以給產品帶來哪些提升轉化。而我們又可以哪些資料，埋點才能得出這些結論。

只要產品還在，業務需求是做不完的

此問題要從程式設計師發展必經的幾個階段說起。

首先是入門階段。立下flag要在程式設計領域有一番作為，於是苦讀了程式設計相關書籍，也選擇了一門開發語言，並且能把書本上的示例程式使用編譯器正確的執行出來。假如讓寫一個100以內口算的小程式，十有八九會寫不出來，主要原因還是沒有具備程式設計思維。形象點來說就是你手裡現在有把刀，到底是用來殺豬還是宰羊，還是削水果，自己也沒想好。

可用一句話來形容這個階段，“路漫漫兮其修遠，吾將上下而求索”。

其次是上道階段。基本上就是剛參加工作那陣，每完成一個需求或者解決一個問題，都有很成就感。專案組中能解決各種疑難雜症的大神讓自己崇拜的五體投地。隨著工作年限的增長對業務也越來越熟練，已掌握的技術足以應付絕大部分業務場景，時間久了就會有與題主類似的困惑。

再往後發展就涉及到職業生涯規劃。一是業務專家，跟隨行業發展方向，深耕業務細節，進可跳到甲方，退可做產品經理。二是技術專家，業務在熟悉業務細節的同時提高自己的技術深度和廣度。掌握產品的底層細節原理是必要條件，多接觸不同的程式語言，做到一主多從地步。專案經理、架構師都是可選擇的崗位。三是轉向管理或銷售崗位，充分利用自己的技術背景，也能做出一番成績。

這個階段也可用一句話來概括，“眾裡尋他千百度，驀然回首，那人卻在燈火闌珊處。”

然後是高手階段。到了這個階段，你會發現技術不再是你解決問題的障礙。只要有利於解決問題，短時間內可讓各種程式語言和框架齊上陣。相應地你完成了從具體執行者到整體設計者角色轉變。

“手中無劍，心中有劍”是對此階段最好的形容。

最後再強調一下業務的重要性。現在大家接觸到的各種技術框架，標準庫等都是為解決特定的業務場景而生的。我所在的證券交易更是有“七分業務，三分技術”之說。總之，技術和業務的關係與雞和蛋關係類似。

這個我經歷過流程，可以講講流程。07年我們單位準備上企業的SAP系統，當時買的是IBM的，IBM的一個小團隊入駐我們單位來做這個專案。團隊成員與每個部門的人對接，我們做業務的，按照他們提供的excell表格填寫業務的具體資訊，就是每個客戶的情況，他們問的很詳細，企業的運作流程的方方面面，他們都特別清楚。最後，08年我們至今都在使用這個軟體，我們稱ERP。

我想說，要想做好，你需要體驗生活，下沉到企業，和業務配合越好，細節掌握越充分，你後邊的彎路越少。

可以學我，當主管。然後只寫最可服用的工具類甚至通用框架。然後就是新專案立項時候設計程式碼佈局，給以後寫程式碼形成高擴充套件。

我是工作多年的軟體開發工程師經歷過後端開發和前端開發，對於"程式設計師如何避免寫過多的業務邏輯程式碼"這個問題，職場新人時期也感同身受，往往提出問題時，你應該已經花費很多時間，深陷龐大複雜的業務邏輯迭代過程中而苦惱。

沒關係，下面我來通過幾個方面不論開發語言的通用解決方案幫你答疑解惑，助你抽絲剝繭，化繁為簡，優雅的開發、迭代業務邏輯。

我的觀點有以下幾個方面：

程式設計只是軟體的具體實現，軟體設計才是重點工作，決定專案的實現方向，前期的系統設計、概要設計、詳細設計也能一定程度避免後期開發中的思路不清晰實現方式問題提前預判。在軟體工程理論中，前期的需求分析、系統設計、詳細設計也是佔了很多比重的，實際工作中也是如此，真正按標準化軟體開發流程的公司是需要開發人員編寫概要設計設計、詳細設計文件的。我經歷的工作也是如此，設計文件很重要，一方面工作團隊能夠透過文件討論可行性實現、是否存在問題和改進及後期的維護交接和需求迭代，另一方面可以幫助開發者整理思路流程，羅列所需資源。

堅持嚴格抽離業務邏輯、通用邏輯，可以從是否具有可移植性，不同型別專案是否可以使用來思考。比如，我們需要一個方法是否為金額，那判定是否為金額的方法在本專案中可以用，在其他專案中也可以用。我們就可以抽出為獨立的檔案、方法。具體的語言實現可能不同，但思路相同。JavaScript語言可以抽離出為方法，Java可以抽離出為通用靜態類。當我們嚴格按照程式碼邏輯性質區分的思想工作時，你會發現前期的封裝，抽離，就是為了後期能夠方便呼叫做鋪墊，程式碼量也減少了，業務也清晰，開發效率得到提高。

主流的程式設計開發語言都是支援面向物件，用設計模式把業務抽象能夠有效避免重複工作，彙集通用的邏輯。比如，我們想要批次造車，車子又有不同的顏色、外形，如果純手工一個一個造會花費很大成本，而實際工廠造車，肯定是先設計模型，根據市場需求造出不同型別車子的樣板模型，然後再批次根據模型製作。程式設計開發也是一樣，如果按照面向物件的思維去思考問題，基本不會有太多重複勞動，重複的邏輯只需要寫一次，其他都是呼叫。

只要努力付出工作肯定會有所得，只是缺少善於發現的眼睛。工作中無論是做什麼事，我們都是可以從中有所收穫，但需要你善於總結和發現，其實收穫不僅僅是物質上的、精神上的，還有經驗、做事的經歷、方法、心得，只要對你有所幫助，對未來有意義，及時是潛在的提高也是收穫。發現問題，改進問題，不正是讓我們軟體開發人員不斷前行的所在，不被外在的評判約束羈絆，善於發現工作中的收穫。

核心業務”服務化“，讓核心業務應用獨立執行，方便不同系統呼叫，用當前熱門的概念來說就是SAAS（Software As A Server）軟體即服務。打個比方，原先實現判斷金額，前端是透過js寫方法呼叫，Java端是透過Java程式碼實現，其實這個邏輯前端、後端都是需要判斷，在以前大家各自寫各自的，同樣的邏輯，但因為平臺不同無法複用。此時就出現了服務化思想，比如我們用Java端的邏輯實現了金額判定，單獨我們把這個邏輯的專案抽出為”服務“，透過傳參返回響應，標準化的restful服務，這樣前端不同的專案可以透過http請求呼叫。

總之，透過以上我們系統化、工程化從軟體開發生命週期中，認真做好專案前期的軟體設計，專案中期的面向物件、抽象思維開發，抽離業務邏輯，專案後期的及時總結，以及對未來核心業務服務化的思考和實踐，我們一定可以化繁為簡，優雅的開發，有所收穫，有所提高。

做好需求建模，抽象，以及模組的可重用性，業務邏輯也可以做的很舒服。其實，真正做軟體的人眼裡，沒有業務邏輯之分。

業務程式碼是技術產品化的關鍵，是實現需求最直接的部分。脫離了業務，再牛逼的基礎程式碼，框架程式碼，構件程式碼……都是一文不值，它們無法成就產品。

實際開發中，大多數公司，大多數程式設計師，都是在寫業務程式碼。對產品來說，應用是業務。對方案來說，功能介面是業務。所以很多人總覺得自己所處位置較為低端，不在技術核心範籌，容易被別人替代，也難和新生力量競爭，因為新生力量更年輕，更精力豐富。

有主動想過最佳化業務嗎？有了解過同行或同類優秀產品的業務嗎？有參考學習優質開源業務嗎？有分析總結過業務和平臺(系統)的對接關聯嗎？有深入瞭解業務的本質嗎？

我建議你多用vba。我這邊重複的業務邏輯量很大，重複機能的程式碼很相似，我自己根據專案需求寫了一個vba。生成程式碼用的，自己改一改就好。根據需求做個工具，既能鍛鍊自己的邏輯能力，還能節省很多沒必要自己做的事情。挺好的。

其實如果不是做底層基礎技術研發的話，大部分程式設計師，主要還是在寫業務功能邏輯的程式碼。別小瞧業務邏輯程式碼，如果真正寫好，要把邏輯寫得清晰簡單易用，功能寫得健壯穩定，效能同時也達到要求的話，其實也是很不容易的。

我之前在軟體外包公司就做過4，5年的業務邏輯功能開發。在這個過程當中，還是有很多地方可以學習總結，然後提高自己的，比如以下兩個方面。

首先第一點要充分理解產品經理提出的業務功能需求。

這裡不單是知道自己要開發什麼功能，還要明白這個功能的需求背景是什麼？為什麼要設計這個功能？如果是你來設計這個功能的話，你會怎麼設計，要思考這些點，才能對自己的接下來的開發更有幫助，同時也建立起自己的產品邏輯思維。對不同行業上業務的理解，也是程式設計師需要積累的經驗的一部分，因為不同行業的業務千差萬別，複雜度也會有很大的不同，就比如說我之前做過的銀行內部管理的例子，他們就有很多特殊性的需求，每天出的報表，報表的價值在哪裡？為什麼要這麼做？如果都能理解的話，這對你未來繼續從事相關行業軟體產品開發的時候，非常有借鑑意義。

第二點就是自己承擔的業務功能點的開發自己其實是有程式程式碼結構設計自主權的。

同樣的業務功能，不同的程式設計師開發出來後，寫的程式碼是千差萬別的，如果是你來寫的話，你會怎麼去考慮這些結構，比如說應用了什麼樣的設計模式，這樣用有什麼好處？對未來程式的功能迭代升級擴充套件性有沒有預留出擴充套件的部分？同時不定期的去重構你的程式碼，讓你的程式碼看起來更精煉，更漂亮，這就是一個學習鍛鍊的過程，而不是說，每天就去重複地堆砌程式碼，回頭自己都看不懂，看不明白。我想這也就是一個優秀的程式設計師和一個普通碼農之間的區別。

最後要說的是，如果確確實實覺得現在的工作只是簡單的重複性寫程式碼，你可以在業餘的時間開發出工具去寫這種重複性的程式碼工作，從而節省自己的時間，提高效率。這裡不單是知道自己要開發什麼功能，還要明白這個功能的需求背景是什麼？為什麼要設計這個功能？如果是你來設計這個功能的話，你會怎麼設計，要思考這些點，才能對自己的接下來的開發更有幫助，同時也建立起自己的產品邏輯思維。千萬不要抱怨，努力和選擇都很重要，更要看你有沒有去挑戰自己的決心。

最好別天天鬱悶，一直持續在這種狀態當中，如果是這樣的話，莫不如停下來去好好思考，到底你想要什麼！你追求什麼！

題主意思是每天寫增刪改查寫膩了，像寫點技術性的程式碼又不知道從哪裡學，很好，說明題主目前階段屬於瓶頸期，就是每天工作覺得沒什麼難度，再難得業務邏輯無非就是耗時間寫罷了。你可以這樣，一週用兩天時間完成本職工作，其他時間自學研究一些自己喜歡的，比如開發遊戲，不管是PC的還是移動端的。又或者是接私活，錢總歸是喜歡的吧。