最近Jerry把自己寫的深入學(xué)習(xí)SAP UI5系列的幾篇文章，發(fā)送到自己組建的SAP技術(shù)討論群：

Jerry剛學(xué)SAP UI5時，對官網(wǎng)上的一些文檔理解得不深，后來調(diào)試了框架實(shí)現(xiàn)，才徹底搞清楚。

有朋友發(fā)表了一些不同的意見。

比如郭爺認(rèn)為：

我來唱點(diǎn)反調(diào)，我覺得讓企業(yè)用sap而不是用小框架的一大原因就是不需要開發(fā)者花時間搞清楚底層原理就可以做出東西，從而提高效率和標(biāo)準(zhǔn)化水平。如果是作為項(xiàng)目實(shí)施的顧問，我不太建議話太多時間研究這些，文檔本身已經(jīng)解釋的很好了。

當(dāng)然如果已經(jīng)能應(yīng)對項(xiàng)目上的大部分問題了，閑來沒事純研究ui5的框架是沒問題的。

還有在sap研究院內(nèi)部肯定是要有更深層次的研究的。

所以，請大家根據(jù)自己的實(shí)際情況，靈活使用我寫的這個SAP UI5框架深入學(xué)習(xí)系列：

架構(gòu)這個東西，至少是中觀的東西。與直接DeBUG看代碼（微觀），是不同聽角度。當(dāng)項(xiàng)目上需要跨系統(tǒng)集成，甚至企業(yè)信息化整體架構(gòu)時，就顯得特別重要。

如果能夠從中層看微觀，更寬的視野，也能拓展DeBUG解決問題的思路，還可以規(guī)避陷于細(xì)節(jié)。當(dāng)然不是說DEBUG不重要。是兩個方面，互補(bǔ)的關(guān)系。

郭爺認(rèn)為：

我在項(xiàng)目上的技術(shù)選型的時候，如果一個技術(shù)產(chǎn)品的文檔本身不能解決問題，我會在技術(shù)決策上打一個大大的問號，因?yàn)樽鳛橐患移髽I(yè)我不期望甲方內(nèi)部的開發(fā)能夠持續(xù)的有源代碼層面的理解能力，所以如果不能文檔層面解決問題，我覺得這個產(chǎn)品沒有enterprise ready

主要還是能力問題，在甲方可能偶爾會有幾個開發(fā)能這么深入研究，但是這屬于偶然因素。做什么樣的開發(fā)會決定應(yīng)該研究哪些，畢竟深度和廣度都是不可能兩個都要的

更多Jerry的原創(chuàng)文章，盡在：“汪子熙”:

總結(jié)

以上是生活随笔為你收集整理的一个讨论：SAP项目实施的顾问，需要花时间去调试代码了解技术细节吗的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。