不要著急寫，這個坎我也經歷過。先理清楚這個功能是幹嘛的，然後就是想這個功能具體實現的步驟，之後按這個步驟，在把步驟按點拆分。 你應該是剛學沒多久，如果做過一套專案，你會發現這些東西就那麼回事。

後端程式碼的邏輯性比較強，還是有很多技巧可以學習的，避免給自己填坑

1.一定要弄懂業務邏輯，所謂程式碼不過就是把業務邏輯翻譯成程式碼，如果業務邏輯都不懂，那麼程式碼肯定寫不好

2.將程式碼模組化，模組化的好處是容易理解，並且容易測試

3.不斷重構程式碼，一個人的能力是不斷進步的，一個月後看你一個月前寫的程式碼都能發現很多不足之處，經常梳理，邏輯肯定是越來越清晰

4.多看原始碼，很多框架的原始碼寫的非常好，原因是作者的水平一般都很高，並且是很多人智慧的結晶，模組化和抽象程度都非常好，從別人的原始碼中也能學到很多優秀的技巧

我們站在一個更高的高度看待這個問題:後臺主要是功能是幹什麼？1.接受請求中的引數 2.完成業務邏輯 3.返回資料給前端

理清了思路，我們一般怎麼處理？

1.對引數合法性進行校驗

2.呼叫快取(資料庫完成相應的功能)

3.得到資料，封裝好響應。

先想清楚了後寫程式碼，自己是哪一步不清晰。然後對症下藥。

不管寫什麼程式碼都是一個思想。先別管什麼面向物件、設計模式，資料結構、複雜度低的演算法…你先把你的需求，你要完成的功能，一步一步面相結構的實現。功能實現了，再用面相物件的思想按你們公司的開發規範最佳化你的程式碼。

寫程式碼和寫作是一樣的，一定是先有底稿之後才開始寫，而不是上來就不分青紅皂白的寫。因此，在寫程式碼之前一定要思考你想要實現的功能在邏輯上是否已經理順了。可以從如下幾方面下手，提高自己這方面的能力：

1） 寫程式碼前先畫流程圖，不一定是多規範的流程圖，可以是草稿，主要是幫助理清思路。

2） 寫完程式碼之後要修改，即使非常有名的作家也不可能一次性的寫出偉大的作品，都是反覆修改後的結果。程式設計也一樣，是一個需要經常推敲，最佳化的過程。

3） 參考別人的程式碼，同樣以文學類比，那個作家不是讀了一車一車的書，程式設計也一樣，一定要閱讀優秀的程式碼。Java方面如SSH框架、Hadoop等。

寫Java程式碼已經有四年的時光了，過的真心好快，從入職時的培訓，到進入團隊的窘迫，什麼都不懂的尷尬，拿到一個課題默默的探索，完成Zookeeper的應用間資訊的傳遞都可以興奮的一晚上誰不著覺……到如今，獨立負責業務線的需求評審、方案設計、核心邏輯的實踐，並有餘力去鑽研更深層次的原始碼，去了解其中的真意，是成長，也是沉澱。總會有一些懵懵懂懂的日子，從蹣跚學步到得心應手，我們要經歷的是堅持和不斷的學習，並注重積累。

剛開始工作，對Java基礎有一定了解，但是介入系統的開發，深感遠遠不夠，在Leader的推薦下，去詳細閱讀了《Head First Java》，其中高效而精煉的程式碼段，對我的幫助很大，其中的程式碼邏輯在隨後的編碼生涯中得到了一次又一次的實踐檢驗。一邊融入團隊，一邊閱讀一些邏輯性強的程式碼，在不斷的實踐中，能力得到鍛鍊和提升，能夠勉強做團隊的後臺管理專案，並應用於線上。編碼生涯就這樣開始了，是職業也是選擇。

在隨後的編碼過程中，基於團隊協作和專案交接，能夠或多或少的看到同事和前輩的程式碼，在編碼之前，總是會去閱讀之前同事的程式碼，瞭解其中的邏輯，從而思考自己的解決方案，怎麼處理才能高效而優雅的完成相關的編碼任務。讀不同風格的程式碼，瞭解其中的設計邏輯和編碼之美，即使再糟糕的程式碼，也有其中的亮點，以學習的思路去詳讀能夠接觸到的程式碼，反思自己程式碼中的不足，集各家之所長，不斷讓自己的程式碼邏輯更縝密，不斷讓自己的程式碼實現更優雅。

到一定階段之後，同事的程式碼對個人的幫助就微乎其微啦，此時，開源社群應該成為我們的重要助手，多接觸接觸一些優秀的開源原始碼，如Dubbo、Spring等。在此之前，還建議多看看JDK原始碼，尤其是util和current包，其中的設計之美，經歷了一代又一代Java人的錘鍊，能深入其中的人真心會感到優雅。而Dubbo和Spring作為我們熟悉的框架，在各自的領域發揮著不可估量的作用，其中的設計模式和架構理論經過了實踐的檢驗，其中縝密的邏輯和優雅的實現值得我們花時間去研究。

走過平庸，路有所成，一件事情堅持久了，就會變得不那麼平凡。千萬條的路，而自己只能走其中的一條，既然選擇了，就毋庸置疑，就堅持走下去，總會有所收穫、技有所長。

後端程式碼複雜度透過分拆、分而治之來解決。首先通常透過拆分工程、多個工程間可以存在依賴關係，但一定要單向依賴，不能成環，如果有環就得考慮把環形依賴部分拆分出來成為單獨的工程，來解決環形依賴。

首先透過橫向分拆出controller、cxmodule、module等層次，module作為業務層根據業務功能的不同進行縱向分拆，分成analysis、dwmodel、metadata、schedule等功能模組，在各個功能模組中，橫向分拆出exteral、handler、service、sqlmap，其中exteral負責資料介面，提供可呼叫的服務和介面；handler作為控制層，透過排程程式碼負責業務的排程，以及一些引數封裝、結果集處理等操作；service則是負責具體業務的業務處理層，除了增刪改查外，一些貼近業務的功能也會在service中完成；sqlmap用於定義操作資料庫的SQL語句。

透過這種分層的方式，實現程式碼層次的分隔，做到各守各層、結構清晰，對於一些跨模組呼叫的介面，如在不同模組中需要對同一張資料表進行操作時，可以將介面提升到上層cxmodule中作為公共介面，實現類和方法的複用；對於一些可複用的、相對獨立的功能，可以透過在cxmodule中定義一個乾淨的介面，在module的功能模組中透過實現介面實現業務邏輯，而不使用spring的事務管理機制，降低程式碼的複雜度。

這是一個比較嚴重的問題，這也是我為什麼老說能不能學好程式設計也是要看“悟性”，我就見過邏輯思維極度混亂的人。對於改進的方法，我只能提幾點小建議。

敲程式碼之前要多思考，多畫流程，多考慮分支，多考慮可能發生的異常。

雖然很多公司沒有為程式設計師留出單獨的設計時間，但是當拿到一個需求的時候，不是立刻動手敲程式碼，而是要先思考，儘可能把所有的業務分支都考慮清楚。

舉個例子，任務表裡有一批資料，需要寫一個批處理方法對其處理。

最簡單的流程：Java程式碼中訪問資料庫，select * from table , 查詢出來資料後，在Java中遍歷處理。那麼可能會有的問題有哪些，解決方法又是什麼，我們一起來看看：

如果資料太多，一次性把資料都讀取到記憶體中就會有問題。解決方法：分頁查詢。

處理過程中，任務表還有資料插入，會造成漏處理或重複處理。解決方法：增加處理/未處理標誌欄位。

其中一條資料處理過程發生異常，程式會中斷。解決方法：增加異常處理，單條資料處理異常也不會造成程式中斷；發生處理異常的資料，標誌位寫入處理失敗。

資料量多，單機處理效率慢。解決方法：分散式Job，部署多臺服務對資料進行處理。

這麼一看，一個很簡單的需求，其實包含的可能性是非常的多的。我們在正式開發之前，儘量把所有的可能性都考慮到。

另外，我們在做Java開發的時候，儘量做到一個方法只做一件事兒，避免把大量程式碼都寫在一個方法裡面，這樣不僅會讓別人讀不懂你的程式碼，而且時間長了，自己都不知道自己的程式碼是什麼意思了。

邏輯混亂這個問題與程式語言的使用無關，並且是一個需要題主非常重視，儘快改正的毛病。

程式是什麼，程式是以程式碼作為工具，以資料結構做載體，表達你的演算法邏輯的作品。

不客氣的說，看一個人的程式碼就能看出這個人是否聰明，以及是否擁有技巧。

我來介紹下相對來說能夠讓你邏輯清晰的工作習慣，養成好的習慣之後，這個毛病自然也就改掉了。

如果是要實現一個複雜的功能，首先要做的是對各個子功能進行拆分，將複雜且綜合的功能分成多個模組，每個模組只負責一個功能。每個功能就對應了一個低耦合的函式，每個低耦合函式就代表了一個獨立的子流程，當我們把每個子流程實現後，只需要用資料把它們串聯起來，一個完整的系統就完成了。

我們以一個低耦合的函式為例。

首先要畫一個流程圖，建議就用鉛筆在紙上畫草圖，因為後期一定會有反覆的改動，鉛筆更有助於修改。而且因為是草圖，不是用來述職的PPT，因此不建議浪費時間在電腦上畫規規矩矩的流程圖。

要明確的是，流程圖雖然不會出現在程式碼裡，但是它是程式碼背後的核心邏輯體現，畫流程圖的過程是整理自己的思路，這是磨刀不誤砍柴工的過程。

這個流程圖的重點有三個點：輸入，輸出，各種if場景的處理。

明確輸入輸出是為了保證就算後期要修改函式的內部邏輯，也不會影響函式之間的通訊。此外，也是有助於在畫圖時時刻提醒你，這個函式的目標是什麼：是根據這樣一個輸入，產出那樣一個輸出。

對於各種if場景的處理，是重中之重。

有的固定步驟可以用一句話就帶過，但是要根據場景做出不同的處理的時候，一定要在流程圖上畫清楚。

在流程圖畫清楚之後，就可以用程式碼實現這個流程圖了。

有了流程圖幫你提前理清執行邏輯，寫程式碼時候就僅僅是將你的思想付諸於程式碼的過程了。

記住，永遠不要邊寫程式碼邊想邏輯。

不知道你邏輯混亂是指哪部分，如果是對java框架比如Spring的使用感覺混亂的話，那麼先深入理解MVC分層模型的本質，在實際開發中制定自己的分層規則，然後嚴格執行就好了，隨著開發經驗的提高，你的分層規則會越來越清晰和規範。

如果是對業務邏輯混亂，那麼首先是真正理解業務，理解業務後將複雜業務拆分為一系列簡單業務（如果不能拆分，說明你對業務的理解還不深入），再實現自然不會混亂，其實就是開發規範中很重要的單一原則，每個類或每個方法儘量只做一件事。