前後端分離的專案，後端更需要了解業務。

首先，後端需要儲存專案需要的資料，需要設計資料庫。這就必須充分的完全的瞭解業務，細緻到每一個欄位。反過來說，資料庫設計其實是對系統功能的一種資料抽象，在設計資料庫的同時，也會迫使後端瞭解一遍業務。

其次，後端需要給前端提供資料介面。介面設計也會迫使後端去熟悉一遍業務，每提供一個介面，就是深入瞭解一塊業務的過程。另外，再加上對系統性能的考慮，還會針對業務進行系統性能最佳化，這些都必須是在保證業務需求下完成的。不符合業務需求的系統設計不就是耍流氓嗎？

最後，也是一個優秀後端的表現。那就是後端在提供介面時，需要去想象，或者說是在大腦中模擬使用者的頁面操作。哪個操作是純前端操作，不需要介面參與。哪個是資料提交操作，哪個是資料查詢操作，都必須瞭解清楚。一個功能的完成，必須在大腦中模擬出這個功能的完整閉環操作，這樣才可以在和前端的配合中如魚得水，合作愉快。不至於聯調階段手忙腳亂。當然，前端也需要了解業務，這個東西，瞭解越深入越好！

看到這個問題，作為一個從業15年，而且前端後端都做過的IT老兵，我的建議是：開發人員需要理解業務，理解的越深刻，產品的質量就越高，開發效率也會提升。而且不應該分前端還是後端。

前端工作最終的意義是充當使用者與後端中介，提供給使用者一個實現後端業務的操作介面，這其中操作邏輯的合理性和便利性會直接影響到使用者的使用體驗。前端人員對於業務的理解能力會對這種體驗產生很大的影響。打個比方，一個簡單的表單錄入校驗，如果開發對業務熟悉的話，就會設計出合理的校驗方式，符合業務的實際需求。當然，在大型開發公司，會有專門的UI設計師以文件的形式將這些校驗規則寫清楚，前端只需要照辦就行，但在一些中小型公司，可能就沒那麼幸運了，前端需要對業務有一定理解，這樣才會高效的開發出優質的前端產品。

對於後端，業務的理解直接會影響產品的效能。舉個例子，同樣一個功能，如果後端能理解這個功能對客戶來說使用非常頻繁，那就會考慮採用redis快取的做法來提升效能，如果不理解而採用直接操作資料庫的做法的話，那效能就可想而知了。

其實不管是前端還是後端，我們的目標的就是能開發出優質的產品，而優質的產品就是能很好的滿足客戶的業務需求，可以說產品就是業務驅動的，那我們有什麼理由不去好好理解業務呢？

在以上的分享關於這個問題的解答都是個人的意見與建議，我希望我分享的這個問題的解答能夠幫助到大家。