專案開發中的「繞」
乙個專案在開發過程中，不可避免會遇到一些問題，出現這些問題的時候，該怎麼辦。目前我看到的處理方法無外乎兩種，一種就是找到問題的根源，解決它。另外就是繞開它。就純粹技術開發角度上講，「繞」當然是不可接受的，在這之前我對待問題的基本態度也是找到根源，解決它，不然心裡不舒服。但是從專案管理角度上講，第一種方法就未必是當然的選擇了，其中要考慮專案的進度等要求。8月份跳到了一家公司，在乙個現有的系統上增加功能，做後續開發，和我以前對待問題的截然相反，這家公司對待問題的方法基本是能繞就繞。這可能和他們人手比較緊，追求開發效率有關係。
在我們的平台上，跑的是uc/os，中斷全部由os接管，為了簡單，程式沒有中斷巢狀。總得來說，我對這個系統的評價是相當低的。這個系統廢**連篇，不同的應用目標靠完全靠巨集定義區分，導致程式流程很混亂。系統模組化程度非常差，耦合度很高，這導致這個系統進行改進會相當的困難。大老闆的態度是現有的**經過了測試，比較可靠，也不同意進行改進和重構，這樣一來，這個系統的重構，優化，基本是不可能的事情。
最近我接手的程式出現了eeprom讀取失敗的問題，經過定位，基本是讀取的時候，會讀出不連續的eeprom資料，但是位元組數是對的，經過今天排查，發現是由於在系統有頻繁中斷的時候，由於at91sam9g45晶元的twi外圍在都操作的時候，沒有overload保護機制，讀取eeprom是如果發生其他的長時間中斷，就會導致eeprom資料被覆蓋。導致操作錯誤。這個問題其實他們以前發現過，當時他們採取的辦法是將操作eeprom的**換了個位置，躲避了這個問題。
總結這個事情，個人對於問題的看法是，在專案迫不得已的時候，可以採取繞的辦法，但是在事後，一定要抽時間解決這個問題，不然，這個問題肯定會在以後某個時候再出來。類似地，對於系統，構建乙個結構良好、強健的系統，在構建的時候可能會費時間，效率低，但這些花出去的時間一定會在以後得到回報。可惜國內負責任的程式設計師太少，能真正追求產品的的老闆也太少，導致專案開發總是強調眼前的功能，到最後，一定是的得不償失的。
專案開發中的反思
接觸ios開發一年多，接觸到的專案也接近10個了，雖然對自己的進步不太滿意，但是還是有必要整理一下自己的經驗，以後可能會用得著。第五個經驗是關於專案中的各個模組。目前我知道幾種專案模組的劃分方式，它們都具有一定的合理性，都完全可以勝任任何ios專案的開發。但是在一位高階工程師進入開發小組後，一切都亂...
專案開發中的心得
在專案開發過程中需要經常做活動之類的，每個月都有活動，而活動毫無規矩可循，這樣的話就只能每個活動都寫不同的程式了 這時候如果在已經穩定的 中去寫活動的話會很容易出錯，而且可維護性不高，因為活動都是短期的，過了就基本上沒有什麼用了，所有，建議放在登入頁裡面，使用者登入的時候判斷是否參與活動等等，因為登...
繞不開的this
猶豫兩秒要不要整理this，從紅皮書上看了半天，沒搞懂哎 弱爆了 什麼是this？this是在執行上下文建立時期建立的乙個執行過程中不可改變的變數。執行上下文是指js引擎會將 執行前需要的變數this提前宣告好儲存在變數物件中的過程，作用域鏈也儲存在這樣類似陣列的形式儲存在函式中的scope屬性中。...