一個項目在開發過程中，不可避免會遇到一些問題，出現這些問題的時候，該怎麼辦。目前我看到的處理方法無外乎兩種，一種就是找到問題的根源，解決它。另外就是繞開它。就純粹技術開發角度上講，“繞”當然是不可接受的，在這之前我對待問題的基本態度也是找到根源，解決它，不然心裏不舒服。但是從項目管理角度上講，第一種方法就未必是當然的選擇了，其中要考慮項目的進度等要求。8月份跳到了一家公司，在一個現有的系統上增加功能，做後續開發，和我以前對待問題的截然相反，這家公司對待問題的方法基本是能繞就繞。這可能和他們人手比較緊，追求開發效率有關係。
在我們的平臺上，跑的是uC/OS，中斷全部由OS接管，爲了簡單，程序沒有中斷嵌套。總得來說，我對這個系統的評價是相當低的。這個系統廢代碼連篇，不同的應用目標靠完全靠宏定義區分，導致程序流程很混亂。系統模塊化程度非常差，耦合度很高，這導致這個系統進行改進會相當的困難。大老闆的態度是現有的代碼經過了測試，比較可靠，也不同意進行改進和重構，這樣一來，這個系統的重構，優化，基本是不可能的事情。
最近我接手的程序出現了EEPROM讀取失敗的問題，經過定位，基本是讀取的時候，會讀出不連續的EEPROM數據，但是字節數是對的，經過今天排查，發現是由於在系統有頻繁中斷的時候，由於AT91SAM9G45芯片的TWI外圍在都操作的時候，沒有overload保護機制，讀取EEPROM是如果發生其他的長時間中斷，就會導致EEPROM數據被覆蓋。導致操作錯誤。這個問題其實他們以前發現過，當時他們採取的辦法是將操作EEPROM的代碼換了個位置，躲避了這個問題。
總結這個事情，個人對於問題的看法是，在項目迫不得已的時候，可以採取繞的辦法，但是在事後，一定要抽時間解決這個問題，不然，這個問題肯定會在以後某個時候再出來。類似地，對於系統，構建一個結構良好、強健的系統，在構建的時候可能會費時間，效率低，但這些花出去的時間一定會在以後得到回報。可惜國內負責任的程序員太少，能真正追求產品的的老闆也太少，導致項目開發總是強調眼前的功能，到最後，一定是的得不償失的。