關於代碼交接的一點體會

這些日子有幸經曆了一次大規模的代碼交接，發現了不少問題，更總結了一大堆經驗。回想起來，這真稱得上是個技術活兒了，所以，撿一些覺得比較重要的體會記了下來。

再亂的事，總有頭緒，理清楚了掌握好節奏，一步步來。先說一下交接的順序：
1、整體結構分析。列出各模組的功能圖，以及模組間的呼叫歷程圖。
2、列出需求，排出產品期望的優先順序。然後按模組做技術分析，優先順序高，難度小，牽涉代碼範圍小的優先順序最高，其它依次後排。
3、無論從哪個角度來講，交接的過程都要和新版本開發並行。因此，需要列出每個版本完成的交接任務和需求任務。切記，交接過程中開發新需求一定要按模組來，不要在前期去搞那些影響範圍過大的需求。
4、新版本開發過程中，一次調整一部分模組，藉機整理結構，熟悉細節。在這個過程中，發現有問題的地方，該換人的換人，該重寫代碼的重寫代碼。經曆幾個版本的迭代，相信會穩定下來。

有幾個需要嚴重注意的地方：
1、“Read the fucking code”是全世界程式員頭疼的事，推倒重寫是很爽快，但這是工作，工作的目標是：用最小的成本換取最大的收益。
2、不要想著一步到位，所有代碼理順了再接需求。你不是一個人在工作，要和老大，和產品溝通，讓他們看到你在忙什麼，到什麼階段了。交接過程中最好的溝通就是按模組交接，交接到哪個模組，把需求鋪到哪個模組。
3、交接代碼必定要按模組分給不同的人去做，但讀別人的代碼需要經驗和技巧，為了避免因為人員水平參差不齊或者理解不一樣而影響交接品質，一定要定出可以量化的交接目標，讓每個負責模組交接的人都有標準去參照執行。

另外，有幾點很深體會，以前是潛意識地去做，但通過這次交接，加深了理解：
1、注釋的重要性。
精巧的結構、核心商務邏輯、關鍵演算法、工具類。這幾個東西一定要在代碼中加上注釋。
2、模組分包。
一個好的分包方式可以讓你在一個包中找到你想要的所有東西。
3、結構與人。
好的結構一定是能夠做到靠增加人數可以解決問題，同時每個人的重複工作又不多。