1，首先要明確是需求看不懂，還是程式碼邏輯看不懂，如果連需求都看不懂，那誰能救你，你自己去找產品或者領域專家，好好請教請教；

2，需求看懂了，業務程式碼看不懂。

這種情況可以原諒，如果你是喜歡debug的一個程式猿，不要著急，找到一個入口，一點一點深入，抽絲剝繭。

再有，跟你的同事多溝通。

3，程式猿普遍不善於言談，喜歡獨自作戰。但是不要忘了，溝通是解決問題的關鍵，及時溝通，及時反饋更是關鍵，切記切記。

溝通，溝通，溝通！！！！

重要的事說三遍。

Java程式設計師看不懂業務，那肯定是要努力搞懂業務，這點是毫無疑問的。那麼如何做到搞懂業務呢？經過多年的開發經驗，總結出了以下幾點寶貴建議。聽我慢慢道來。

不論到什麼時候，我總是勸解新人要調整好自己的心態。

遇到困難，不要害怕自己弄不明白，弄不出來，就算弄不出來，老闆也不一定會直接就開除你。困難是大家都會遇到的，人們往往身在其中而陷入恐懼和無助，但是作為局外人而言，他們更希望看到人們面對困難時所作出的努力和付出。

你不需要真正獨擋一面，但是最起碼要表現出吃苦耐勞，勇往直前的精神。這是一個新人應該做到的一點，也將是一個成功之人不斷進步的必要前提。

一時半會看不懂業務邏輯，可能是由於資訊量過於龐大，這一點我也深有體會。不過我的解決辦法是大致過一遍整個業務邏輯，將很模糊的地方標記出來。

另外，所有業務都會有非常關鍵的執行步驟，很多其他的操作可能都是為某個或某幾個步驟鋪墊和創造執行條件。

所以，掌握流程的關鍵步驟可以讓你事半功倍，這樣你也不會非常迷茫。

將關鍵步驟掌握之後，你就需要以這些關鍵節點為出發點，分段理解各個環節，化整為零，逐個擊破。

到了這一步，你就可以將業務邏輯逐條分析，細緻分析。切不可急躁。另外，你也可以像領導進行諮詢，對於不是特別清楚的地方，一定要溝通清楚。或者讓理解比較好多人，大致給你講一講這一步要幹嘛。多方位尋求幫助。相信不會太久，你就可以將業務完全搞懂了。

另外一定要相信積累的力量。

綜上，就是我的觀點，希望可以幫助到你。

在解答題主問題的時候，先來看一個故事：我在HW的時候，負責一個版本的開發，這個版本的工作量大約是2000行左右，但是我除了做完這個功能，還將關聯的功能全部掌握清楚了，程式碼（大約10000行）也全部看了一遍，做完這個版本後，我對這個版本相關的整套業務全部很熟悉了。經過一兩次會議後，大家發現我對這塊掌握最熟了，接下來就有趣了：產品討論需求找我、測試有問題也找我、老大對外支撐也找我；後來，不是我負責的功能他們也找我，即使我當時不知道，我也會看程式碼或者找文件幫他們回答。。。。。。最後我就成了我這個系統的“專家”了。雖然這個時候我還是做業務的，還是寫業務程式碼，但是我已經對整個業務都很熟悉了。如何看程式設計師的水平高低：

首先就是看出現問題之後的排查能力，其次就是業務的理解能和邏輯思維，之後就是對技術的理解，尤為重要。如果題主是一個完全不懂業務的程式設計師，那麼就從你接手的專案的程式碼開始看，並且多看有原始碼的專案。在各樣的專案中操練自己的理解能力；

看問題不能只看自己眼界內的，可以提升一個高度。就跟我開始講的故事是一樣的。首先可以讓自己對公司整個IT架構有了解，之後清楚網路架構、儲存架構。清楚的知道自己的業務模組在技術上處於公司那一部分。

你所做的業務對於公司的發展和業務戰略上有那些幫助。常常思考哪些地方是可以最佳化的。保持這樣的思考，久而久之，在你再次接到新的需求的時候，你會有自己的想法，並且就會判斷這個需求是不是合理，這種設計是否符合公司整體利益或者架構風格。

保持這樣的思考也會幫助你儘快晉升到架構師的思維模式。

業餘的時候自己一定要嘗試去做一些開源專案，或者是加入一些開源專案。也是拓寬眼界的方式。並且根據別人的對比也能清楚的知道自己的差距和優勢在哪裡。

公司當中有技術會議的時候，多多參加。有機會就參加，一定學會傾聽和溝通。傾聽別人的觀點；