現代應用開發中或多或少會使用到各種開源，自研的庫，框架等，各種資料良莠不齊，
除了部分成熟開源，商業框架的文件做得很好，使用廣泛，生態完整，的確很多問題可以處理。
但自研的通常就是重災區，資料少，不同步，
那麼如何在這類這類框架中找到問題處理的方向，甚至解決方案呢？
昨天幫同事處理了乙個uee框架使用的問題，可做借鑑。
1.對框架有個基本了解，例如框架的大體結構，層次，work流程。
對於各個部分如何work這塊我認為是很關鍵的，
例如以安全界大哥大struts2為例，理解乙個action的生成，要配置哪些檔案，
這些檔案怎麼配合，生效路徑是怎樣的，和其他框架如spring怎麼結合，
整個過程可以能在腦子裡放電影式過一遍，當然能高畫質就最好了。
這個主要是建立框架的使用模型，方便和其他框架進行模擬，解決一些基本的使用問題，
並為後續深入打好基礎。
2.了解框架的實現原理，假設你有開啟uee對應的生成件指令碼檔案，
就會發現裡邊有5w行js,連ide都會卡頓一下，怎麼破？其實還是有門路的，因為uee是基於ng1的框架，
這個檔案裡邊有一大半是jq和ng1的**，後面部分才是擴充套件功能。
所以掌握ng1的框架原理至關重要，例如dirty check，directive這些黑科技，
以昨天的問題為例，就是直接進到對應directive的實現中，對比行為差異，
最後可以發現多配置乙個引數就可以解決問題。
理解關鍵特性的實現原理，這樣在除錯驗證過程中才心裡有底，不會瞎矇。
3.工欲善其事，必先利其器，熟練掌握各種工具，小到除錯技巧，大到各種輔助工具。
除錯技巧，例如上面的問題除錯，一次觸發會數十次call,乙個個檢視很容易miss target,這個時候就應該用條件斷點。
類似的技巧還有異常斷點(查詢某個特定異常)，賦值(改變執行路徑)等。
如果大段**不知**有bug，可以兩分搜尋，在斷點處驗證正確性。
除錯不是用來找bug的，它只是驗證的過程中順手找到bug。
至於輔助工具，反編譯工具，抓包工具，各種shell命令，指令碼語言，技多不壓身，總有合適的。
4.注意積累，適時總結。很多人不是厲害，只是踩坑多而已。
所以還是要多填坑，多填別人的坑，這樣就顯得很厲害了，填坑機會就更多了，這是個良性迴圈。
當然萬事開頭難，一開始還是要注重程式設計規範學習，看點書，
遇到問題的時候多找找資料，爭取系統的過一下相關知識點。
例如你今天遇到了classdefnotfoundexception，問題解決了，
那麼就看看這種異常有哪些情況下會出現，怎麼避免，和其他相關異常有什麼區別？
可能有很多人已經知道了，寫出來很low，但做一下總結總是有好處的，日積月累，做好填坑的準備是關鍵。
書寫節奏有點亂，非喜勿噴。今日@廣州地鐵。
如何解決問題
最近打算去新的崗位，嘗試新的業務，當然也就需要新的思考，新的碰撞，想起前段時間看過溫伯格1982年出版的 你的燈亮著嗎？把序言中的總結點摘錄下來，希望能給自己帶來些許思路。問題其實就是你期望的東西和你體驗的東西之間的差別。動手去解決問題之前，好好想想問題的 如何站在各個角度來看待面臨的問題，以能夠知...
如何解決問題
很多時候只是解決問題的表象，即來乙個問題處理了，但並沒有歸因，找到更深層次的根本矛盾。如乙個專案比其他專案問題更多，更不可控，如果只是列出所有的問題逐個解決處理，只是在解決問題本身，並沒有定位根本原因。根本原因是專案難度更大？專案成員表現 狀態不好？根據根本原因如何處理。為了解痛點和原因，需全面評估...
Web應用中的路徑解決問題
在開發 的時候 經常遇到一些 路徑問題。比如 子資料夾下的檔案要引用上級目錄中另乙個子資料夾的東西。或者是因為巢狀頁面導致 原頁面中的 資訊等資源因為路徑錯誤而找不到 有以下解決辦法 string path request.getcontextpath 工程路徑 string basepath re...