開發中的新理解——成長在2013
今年在公司裏，收穫很多。從很多方面，都一個新的認識。因爲參與公司的幾個項目。有的是維護原有代碼，有的是從需求開始，從0做起，有的做了一半，因爲調整不做了，有的剛開了個頭，因爲其他項目需要暫停了。每一個項目，做的程度都不一樣。但是每一個項目，都讓自己對於完成一個項目，有了更深的認識。也慢慢在改變自己以前那種學校式的研發狀態。由一開始想從每一個項目中學習新技術，到想辦法確保每一個項目都能按照預期按時結束，做出能夠交付的穩定產品。而這本身也是一種學習。
/* ---------------------------------------------------------------------------*/
年初，公司接到一個項目，給客戶提供一套軟硬件系統。其中自己負責的部分，需要對一年半前的代碼進行維護，修復其中的Bug。對於這份代碼由於是一年半前由兩個人寫就。當維護的時候，第一件事就是怎樣讀懂代碼，找到能入手的地方。當開始研讀代碼的時候，發現全局變量定義實在是多。一個.c文件中，多的時候就會有二十幾個。而代碼之間的耦合，造成全局變量的定義和使用可能在幾個.c文件中。函數間的參數傳遞，有些就是直接用全局變量實現的。代碼過長的函數，就有好幾個，有的函數一個switch就會有200行以上。當時，讀到這些代碼的時候，第一反應是一定要把這些當時認爲不好的代碼全部修改了。確實一開始也這樣做了，以爲只要費些時間就會弄完，然後，有了一個熟悉的代碼理解也會更快。
但是一段時間後發現要改的地方真是很多，而且測試起來也很難辦。因爲是嵌入式上的程序，很多地方都要手動去一個個測試（當時如果知道了《重構》的經驗與教訓或許不會那麼大刀闊斧的來）。測試的過程十分麻煩，而且會造成有些地方測試不到。由於源代碼底層代碼與應用層代碼耦合比較厲害，如果有改動，底層的不穩定會導致整個系統的不穩定。而這個在最後發現了。由於中途臨時需要交付一個Release版本，有些地方改了還沒有測試，只好將沒有測試的地方恢復。這樣代碼中就出現了改了一半的代碼。由於自己在修改的過程中，也沒有遵循原有代碼的代碼風格（由於原有代碼tab鍵與空格混用，看不出風格，變量名也比較隨意）。也有些地方遵循自己的編程習慣，修改了代碼中存在遞歸的代碼。
最後發現，程序並沒有比原來更好理解，耦合性還是很高。在後期考慮到硬件有一個元件已經停產，所以建議更換新的模塊。更換後，由於對於新的模塊不是十分熟悉，導致出現了比較嚴重的問題。這個事後自己反思的時候，認爲當時提的一個很錯誤的建議。在項目的後期，已經沒有多少時間去測試穩定性了，而此時卻將以前穩定的元件替換掉，而換新的元件，測試時間又沒有那麼多。直接導致了不穩定的存在。事後，也確實因爲這個元件，導致了第一批出貨出現了返修。爲此，連續三個週末在公司解Bug。
整體的維護中，雖然改善了原有代碼的的Bug，但是卻也引入了新的Bug。在這個過程中，前期也是自己對於代碼維護的理解有偏差。如果說重構，也要是用到的地方進行重構，而不是對於很多地方重構。更不應該在項目後期，進行元件的替換。如果說維護是爲了保證產品的穩定性，那麼就要在最小的範圍內做修改。儘量避免修改不需要修改的代碼。但是，這裏邊涉及一個問題，怎麼判定那些是需要修改，那些事不需要修改的？有些容易判斷，但是有些就十分模糊。
這裏還有一點，如果說盡可能減少修改的地方，那麼對於維護者而言是否會接受這樣的概念？對於一個初做的人，總會想多做一些。是得過且過，還是精益求精？這個或許《重構》最後的一個建議很好“使重構成功的不是前面各種技術，而是這種節奏”，懂得重構是在於“可以自信地停止重構”。但是這種節奏的獲得需要有大量的實踐纔會獲得，這種自信也需要從實踐中一點點獲取。在此次維護結束後，想要找到自己在維護的過程中犯下的錯，以期以後不會在同一個坑中栽倒第二次。如何在以後的類似工作中做地更好，在反思了一些以及看了一些書後。認爲維護過程中有幾點是嚴重犯錯的地方：
沒有做到對於不必要的地方不修改；
缺少質量管理的觀念。
經過這次維護的經歷，得出了以下幾點：
確定code style，編寫易讀性代碼，代碼可讀纔會使維護更容易；
使用lint工具檢查代碼；
積累重構；
注意C的安全性與非安全性；
建立代碼質量的觀念，建立產品質量的觀念；
/* ---------------------------------------------------------------------------*/
年中，接到另一個項目。和前一個項目完全不一樣，這個是要從零開發。自己負責軟件中的一部分。初期由自己做設計初步的通信協議，以及通信機制。在開發過程中，發現由於客戶不瞭解元件的特性，推薦的元件型號不滿足客戶自己的要求。於是，進行了元件更換。在新的元件上，很容易做到客戶要求的指標。這些完成後，要給客戶提供一批樣品進行測試。這個過程中發生了一些意外。試產的第一批在使用測試程序後，發現有一半測試不合格。經過測試分析，發現硬件的模擬部分不同PCBA之間存在差異，原有程序的初始值在差異較多的時候會出現異常。於是將程序的初始值，修改後重新測試發現大部分輸出都正常了。
在後來生產的過程中，發現由於實際要裝配的東西很多，裝配的過程很多，而選擇的外殼內部空間較小，造成內部空間很緊張，給裝配人員實際造作中帶來很大麻煩。直接的影響就是裝配的效率偏低。在催促他們提高裝配速度的時候，也確實很難提高速度。測試的項目很多，需要時間。外殼的尺寸和元器件之間內部空間的限制，以及外殼螺絲都成了影響的一個因素（採購的外殼，有些螺絲因爲攻絲有問題，導致螺絲裝卸較困難）。元件多，要裝的步驟會相應多一些。
在這個過程中，反思爲什麼會出現這樣的問題。
首先，軟件上的設計一開始沒有深入瞭解具體的硬件情況，導致軟件上的參數設置和硬件的偏差配合不上很好。對於具體要應用的場合瞭解還欠缺深入。在提供給測試部的程序將測試程序與正式程序分開，導致測試人員在測試完成後還要重新燒錄正式程序。如果當時，自己在設計程序的時候，將測試流程包含在正式程序中，通過特殊條件觸發，能減少測試人員的測試時間，提高他們的速度。同樣，在需要的一些測試環節，或許還有可以提高的地方。
其次，選擇的外殼和連接線，PCBA之間配合不好。這方面如果考慮多一些，裝配人員就能省下來很多時間，提高裝配效率。也不會抱怨產品那麼難裝配。更降低了裝配的主動性。
在這個過程中，深深感受到保證每一環正確的重要性，即使有一步缺失都會造成最後產品生產的進度與性能。
/* ---------------------------------------------------------------------------*/
後來又根據需要接手了兩個，由於預期的調整，每一個都做了有一個月左右停下。
/* ---------------------------------------------------------------------------*/
在這個過程中，慢慢明白了，在一個團隊中、在開發產品的工程中最重要的不是技術問題，因爲對於一個開發者而言技術通常不是問題。技術可以一點點習得，技術可以google，可以研究，可以向別人請教。而一個開發者通常欠缺的是——建立項目的概念，進行有效溝通。項目進行過程中，每一步都是由有效的溝通驅動。瞭解需求，團隊合作，協同開發，測試反饋，生產反饋……。如果這些過程中，有地方沒有明確理解對方表達的意義，或者沒有明確表達自己的意思，都會造成整個項目開發上的delay。沒有正確瞭解需求，開發出來的將是一堆無用的代碼；沒有團隊間的有效溝通，開發中成員間將會互相掣肘；沒有有效的測試反饋，開發出來的將是質量無法保證的程序；沒有生產部門的有效反饋，開發出的有可能是不利於生產的產品。同時建立一個項目管理的概念，也是十分必需。如果將項目廣義化，我們工作中接到的每一個任務，對於我們自己而言都是一個項目，我們開發結果的使用放就是我們的客戶，而我們自身就要做好對於這個任務的管理。保證給我們的“客戶”是高質量的產品，只有每一個環節都有高質量的產出，纔會做出最後高質量的產品（產品質量符合木桶理論，注1）。由此而言，作爲一個開發者，要關心的不僅僅是技術，也要關心於有效溝通，建立項目管理的觀念，將它們用於平時的工作。技術可以保證我們出色完成當前分配好的工作，但是並不能保證我們提供一個高質量的產出，更不能保證項目的順利完成。所以，技術很重要，但它不是全部。
/* ---------------------------------------------------------------------------*/
整體而言，這一年在公司經歷了很多。從技術，到其他感受也很深，收穫也很大。
從一開始想要探究代碼，到現在對代碼三思而後行；
從一開始想要鑽研，到現在工作上enough is good；
從一開始不知何爲代碼安全，到現在編程時刻將代碼安全放在心頭；
從一開始不知如何修改代碼，到現在試着找找重構的節奏；
從一開始只知開發，到現在從測試、生產、使用的角度考慮設計；
從一開始把代碼管理當做備份，到現在建立branches，打tags，查看版本graphic；
從一開始不會lint，到現在用lint工具檢查C代碼；
從一開始對項目一知半解，到現在慢慢建立項目管理的概念，指導平時的工作；
……
這些的這些，記錄了一年的酸甜苦辣，記錄了一年的變化。走過，“回首向來蕭瑟處，也無風雨也無晴”，留下的是——成長。
/* ---------------------------------------------------------------------------*/
注：
關於合作。
……
關於《重構》