關於公升級firmware的問題
提出了一種新的方案，針對於新的方案，修改xml檔案，支援新方案的公升級。
但是如果修改xml檔案，各種裝置的xml檔案都需要修改，工作量還是比較大，維護也比較麻煩。
當時在設計的時候，為什麼不考慮能不能不修改xml檔案，就可以進行公升級呢？
實際專案完成以後，發現還是可以不改動xml檔案，在client端進行一些處理，還是可以達到目標的。這是非常好的事情。
大大降低了維護的成本。
以前ftp上傳的檔案，放到記憶體中，然後解壓操作，記憶體的速度非常快，但是firmware檔案比較大，不得不移到flash上操作，但是這意味著時間花費將增加許多。如果此時client傳送命令查詢，下一步工作還沒有開始，返回乙個錯誤值。解決方法：
這個操作是乙個新的程序，在後台執行，應該檢查程序，判斷程序是否存在，如果存在，返回乙個特定值。
以前只是要求client等待更長的時間，唉！在有些case可以通過，有些就會失敗。早點想到這個解決方案，就不會有問題了。
列印程式：
1. 如何紀錄mac位址在資料庫中？
定義兩個字段，mac0 and mac1,分別記錄前四位和後兩位，並且以整形儲存。
2. 如何記錄名稱？
在盒子中，定義比如32位元組的字段，每次都讀或者寫這麼多，只負責紀錄，也不需要顯示，這就足夠了，不用特殊處理中文字段，由訪問程式自己處理。
3. 不需要紀錄名稱到盒子中，直接記錄到資料庫中，方便快捷。。。。
好好思考！！！！
尋找簡單的方法：
**有bug需要修改，開始感覺非常複雜，修改這個問題，同事卻說：
1.為什麼需要這個變數，pdef? 僅僅是為了得到名稱，所以我們如果能夠想辦法傳入乙個名字就可以了，其實得到這個名字非常方便，輕鬆搞定。
2.eeprom問題定位
eeprom在vx下測試可以正常讀，寫失敗。說明大概率是寫驅動的**出了問題。還好，另外乙個os的讀寫eeprom是正確的，如何快速除錯定位？
既然讀可以成功，大概率說明讀操作時，暫存器操作還是正確的。檢查寫操作，檢查**不仔細，確實沒有發現問題。
eeprom通過i2c進行控制，所以**分為eeprom驅動，i2c驅動，真正暫存器操作是在i2c中進行
實在除錯不出來，使用乙個最笨的辦法，整體移植，將另一os的驅動，i2c的驅動，替換vx下i2c驅動，本來不抱有任何希望，結果真正被打臉，竟然成功了！！！
最後發現錯誤還是暫存器操作，通過暫存器寫操作，引數值value被截斷：
value = param1&0xff
高位資料丟失，所以寫操作失敗！
事後覆盤，自己除錯花費時間太多，入手沒有抓住關鍵：
既然寫操作失敗，我真不應該對vx下i2c驅動整體替換，僅僅針對寫操作**替換就可以，完全不需要整體替換
不過還真是，萬萬沒想到**替換有時候還是乙個有效辦法
不輕易說不可能：
public a: public b, 類a 繼承 類b， b實現資料的處理，現在需要將一些資料處理放到a，只要b的處理函式是virtual 就可以了，沒有什麼難度。
多多思考？多問有沒有更好的方法？為了懶惰，實現創新！
這比開發更加有意義！！
在開發中缺少思考。這是很多程式設計師的通病。
我們在專案開發中的一些思考
關於專案中的一些思考 專案目前已經進展了一些時間，而且前期也執行比較穩定，但總覺得有些什麼東西不對，究竟是什麼呢？不知道，但心中總有點不放心。我想大家有時也會有這種感覺，就像有什麼心事一樣在心頭，揮之不去。但這件事總會有想通的時候，我想這一天不會太遠了 終於有一天，我躺在床上，腦子好像有點什麼似的，...
前端關於專案，需要自己平常思考的問題
美團校招專案面試 1.專案開發過程中如何保證 是高質量的，或者如何定義 高質量？你講的這幾點是否應用在你的專案中了？2.瀏覽器的相容，你是如何去判斷自己做的系統要滿足使用者使用哪些最低版本的瀏覽器，就是說你做的系統要相容到什麼瀏覽器，你是如何去判斷的？3.專案開發過程中，最大的痛點是什麼？為什麼出現...
開發 專案發布引起的思考與總結
營銷系統中經常會有重構乙個活動的需求，有時需要推翻原來的方案重新制定新的策略，就需要考慮新舊資料的相容，若存在快取的話，也需要考慮快取的更新，尤其是對於使用者流量比較大的活動，下面是乙個細化的場景 舊活動a有著很大的使用者流量，qps經常輕易達到900，新的需求是把舊活動a重構成活動b，同時新增了一...