網(wǎng)上有許多關(guān)于代碼的段子，比如：想要不被別人代替，代碼要越亂越好。
當(dāng)版本迭代的時(shí)候，經(jīng)手這個(gè)項(xiàng)目的人通常會(huì)崩潰，如果這個(gè)時(shí)候，你還沒(méi)有離職，你也一樣會(huì)崩潰，因?yàn)槟憧赡芤呀?jīng)不認(rèn)識(shí)自己的代碼了。
項(xiàng)目系統(tǒng)總體設(shè)計(jì)階段，應(yīng)盡可能地考慮到未來(lái)可以遇見(jiàn)的情況，覆蓋到盡可能多的業(yè)務(wù)擴(kuò)展。項(xiàng)目雖然分階段開(kāi)發(fā)，各個(gè)階段完成的功能都不一樣，總體設(shè)計(jì)要指向最終的需求。
制定的協(xié)議要滿(mǎn)足整個(gè)項(xiàng)目所有數(shù)據(jù)的交互。
比如：
這里的 ID 設(shè)置為 1 個(gè)字節(jié)，可能有一定的風(fēng)險(xiǎn)。后面功能加著加著，可能 1 個(gè)字節(jié)的 ID 滿(mǎn)足不了，就得改協(xié)議。盡管可能滿(mǎn)足了某個(gè)項(xiàng)目的需求，但萬(wàn)一之后其它項(xiàng)目也用了這一套代碼，但是 1 個(gè)字節(jié)的 ID 滿(mǎn)足不了，又得改代碼。這里設(shè)置 2 字節(jié)可能會(huì)好一點(diǎn)，基本上能滿(mǎn)足絕大部分情況的使用。
不一定為了覆蓋范圍更廣而設(shè)置 4 字節(jié)，這樣可能有點(diǎn)冗余。很多情況都有一個(gè)平衡點(diǎn)，需要自己權(quán)衡。
Length字段只設(shè)置了 1 個(gè)字節(jié)，可能也有一定的奉獻(xiàn)。后面功能中如果有發(fā)較大的數(shù)據(jù)，可能要分好多包發(fā)，原本可以發(fā)得很快，被這里限制死了。到時(shí)候想要提速，就得改協(xié)議。
之前項(xiàng)目里，幾塊板間的通信都用同一套協(xié)議。但后期發(fā)現(xiàn)該協(xié)議滿(mǎn)足不了新需求，但為了不影響到前面的數(shù)據(jù)，又搞了一套協(xié)議。導(dǎo)致項(xiàng)目里有兩套差不多一樣的協(xié)議處理代碼。
協(xié)議應(yīng)該是項(xiàng)目一開(kāi)始考慮好、制定好，整個(gè)項(xiàng)目開(kāi)發(fā)期間，都不應(yīng)該再做改動(dòng)。
后面新增的數(shù)據(jù)，不應(yīng)該插入現(xiàn)有的數(shù)據(jù)中，應(yīng)該單獨(dú)增加一個(gè)數(shù)據(jù)ID。
比如：
現(xiàn)有的數(shù)據(jù)中，有一條數(shù)據(jù)叫做設(shè)備信息的數(shù)據(jù)，設(shè)備信息里包含了：設(shè)備IP、設(shè)備Mac。這個(gè)數(shù)據(jù)會(huì)顯示在手機(jī)APP上。對(duì)應(yīng)的 C 語(yǔ)言代碼：
#define??MSG_ID_DEV_INFO???0x0001
typedef?struct?_dev_info
{
?char?dev_ip[IP_MAX_LEN];
?char?dev_mac[MAC_MAX_LEN];
}dev_info_t;
假如后面需要再顯示一個(gè)設(shè)備的sn，這個(gè)數(shù)據(jù)我們應(yīng)該加在哪里？
如果是項(xiàng)目前中期，這時(shí)候還是在開(kāi)發(fā)階段，我們可以隨意修改。因?yàn)樵O(shè)備sn也是設(shè)備信息的一部分，可以直接在設(shè)備信息這個(gè)數(shù)據(jù)里添加會(huì)比較合理：
#define??MSG_ID_DEV_INFO???0x0001
typedef?struct?_dev_info
{
?char?dev_ip[IP_MAX_LEN];
?char?dev_mac[MAC_MAX_LEN];
????char?dev_sn[SN_MAX_LEN];
}dev_info_t;
如果是產(chǎn)品已經(jīng)在市場(chǎng)上流通，這時(shí)候這么加的話(huà)，軟件兼容性就不太好。因?yàn)榧偃缒愕氖謾C(jī)APP版本與設(shè)備版本不匹配，原有的設(shè)備IP及設(shè)備MAC這兩個(gè)設(shè)備信息可能都顯示不出來(lái)，因?yàn)槲覀冞@么一改，破壞了原有的數(shù)據(jù)結(jié)構(gòu)，而手機(jī)APP按照原來(lái)的數(shù)據(jù)來(lái)做解析的，會(huì)解析不過(guò)。
這時(shí)候可以這么來(lái)加：
#define??MSG_ID_DEV_INFO???0x0001
#define??MSG_ID_DEV_SN?????0x0002
typedef?struct?_dev_info
{
?char?dev_ip[IP_MAX_LEN];
?char?dev_mac[MAC_MAX_LEN];
}dev_info_t;
typedef?struct?_dev_sn
{
????char?dev_sn[SN_MAX_LEN];
}dev_sn_t;
這樣，哪怕手機(jī)APP版本與設(shè)備版本沒(méi)有對(duì)應(yīng)上，原來(lái)的數(shù)據(jù)還是能正常顯示的。當(dāng)然，最好的情況當(dāng)然是在開(kāi)發(fā)階段就合理地設(shè)計(jì)好。不然，像這種情況，只能犧牲一些程序可讀性來(lái)?yè)Q取程序兼容性了。這會(huì)讓后面看代碼的人覺(jué)得很奇怪，你這個(gè)sn不也是數(shù)據(jù)設(shè)備信息嗎，怎么還單獨(dú)給一個(gè)ID。后面接手這個(gè)代碼的人可能就會(huì)把這一塊代碼給改了。
溫馨提示：在沒(méi)有完全弄懂維護(hù)項(xiàng)目的代碼為什么這么實(shí)現(xiàn)的情況下，能正常在跑的程序還是別亂動(dòng)得好，哪怕你覺(jué)得這是屎山代碼。否則可能會(huì)出大問(wèn)題。要么等到軟件重構(gòu)時(shí)再修改，要么就繼續(xù)打補(bǔ)丁。
如果是刪除本模塊內(nèi)部自己使用的數(shù)據(jù)，你想怎么刪就怎么刪。
如果是刪除與其它模塊進(jìn)行交互的數(shù)據(jù)，這就不能這么隨意了。比如，請(qǐng)求、應(yīng)答的方式。應(yīng)答端給請(qǐng)求端返回的數(shù)據(jù)是不能隨意刪的，如果要?jiǎng)h，一定要確保請(qǐng)求端已經(jīng)沒(méi)有請(qǐng)求數(shù)據(jù)的需求，并且已經(jīng)去掉相關(guān)代碼時(shí)，這時(shí)候應(yīng)答端才去刪數(shù)據(jù)，否則還是留著吧。
其實(shí)數(shù)據(jù)定了，為了保證軟件兼容性，應(yīng)該是要禁止修改的。
如果一定要修改，可以先增加一條新數(shù)據(jù)，后面慢慢切為新數(shù)據(jù)、刪除舊數(shù)據(jù)。
正在使用的接口，應(yīng)該盡量不要修改。如果要修改，一定不要影響之前的功能。
之前就有遇到類(lèi)似的情況。舉個(gè)例子：
typedef?enum?_sys_status
{
?SYS_STATUS_IDLE,
?SYS_STATUS_RUNNING,
?SYS_STATUS_STOP,
}sys_status_t;
static?sys_status_t?g_sys_status;
sys_status_t?get_sys_status(void)
{
?return?g_sys_status;
}
這里的系統(tǒng)狀態(tài)是要顯示在手機(jī)APP上的，不同的狀態(tài)顯示不同的圖標(biāo)。后面要新增一個(gè)狀態(tài)，結(jié)果數(shù)據(jù)提供者這么改：
typedef?enum?_sys_status
{
?SYS_STATUS_IDLE,
?SYS_STATUS_NEW_STATUS,
?SYS_STATUS_RUNNING,
?SYS_STATUS_STOP,
}sys_status_t;
static?sys_status_t?g_sys_status;
sys_status_t?get_sys_status(void)
{
?return?g_sys_status;
}
接口提供者把新增的數(shù)據(jù)插入了中間，影響了枚舉原有的順序。結(jié)果手機(jī)APP上圖標(biāo)顯示亂了。
影響到接口的修改，要保證原有的數(shù)據(jù)不受影響。
在軟件升級(jí)過(guò)程中，需要考慮軟件所依賴(lài)的其他系統(tǒng)組件是否發(fā)生變化，以確保升級(jí)后軟件能夠正常運(yùn)行，不會(huì)影響其他系統(tǒng)組件的正常運(yùn)行。如果其他系統(tǒng)組件發(fā)生變化，則需要進(jìn)行相關(guān)測(cè)試和文檔更新，以確保整個(gè)系統(tǒng)能夠正常運(yùn)行。
另外隨著項(xiàng)目的迭代，這一套代碼有可能運(yùn)行于不同的系統(tǒng)不同的芯片平臺(tái)。
比如，我們嵌入式Linux項(xiàng)目，有些項(xiàng)目里會(huì)用到一些第三方庫(kù)，這時(shí)候可能會(huì)編譯成動(dòng)態(tài)庫(kù)的形式。要考慮升級(jí)的時(shí)候能不能升級(jí)動(dòng)態(tài)庫(kù)。如果不能，就得把依賴(lài)的庫(kù)一起編譯到可執(zhí)行程序里。
另外，如果使用動(dòng)態(tài)庫(kù)，之后產(chǎn)品軟硬件迭代換了一個(gè)芯片平臺(tái)的話(huà)，我們就需要重新交叉編譯一次所依賴(lài)的庫(kù)。如果為了保證這一塊的兼容性，也可以考慮把所依賴(lài)的庫(kù)與用戶(hù)代碼一起編譯。
當(dāng)然，這個(gè)根據(jù)實(shí)際情況進(jìn)行權(quán)衡取舍。如果依賴(lài)的庫(kù)很多，一起編譯到可執(zhí)行程序里，導(dǎo)致可執(zhí)行程序很大，到時(shí)候更新也不好更新。
涉及到功能的添加的，盡量不要影響到之前已開(kāi)發(fā)的功能。不然也會(huì)增加用戶(hù)對(duì)產(chǎn)品的學(xué)習(xí)成本。比如某些指示燈在前一個(gè)版本的快閃、慢閃代表什么意思，這個(gè)在之后就盡量不要去修改了，不然用戶(hù)又得重新理解。
在軟件升級(jí)過(guò)程中，需要考慮軟件的性能是否發(fā)生變化，以確保升級(jí)后軟件的性能仍然能夠滿(mǎn)足用戶(hù)需求。如果軟件的性能發(fā)生變化，則需要進(jìn)行相關(guān)測(cè)試和優(yōu)化，以確保軟件能夠正常運(yùn)行，并且能夠滿(mǎn)足用戶(hù)的性能需求。
比如，原來(lái)正常升級(jí)需要3分鐘，某個(gè)版本之后升級(jí)變成了6分鐘，升級(jí)效率變差了。
在軟件升級(jí)過(guò)程中，需要考慮軟件的安全性是否得到加強(qiáng)，以確保升級(jí)后軟件的安全性能夠得到保障，不會(huì)出現(xiàn)新的安全風(fēng)險(xiǎn)。如果軟件的安全性得到加強(qiáng)，則需要進(jìn)行相關(guān)測(cè)試和文檔更新，以確保軟件能夠正常運(yùn)行，并且能夠保障用戶(hù)的安全。
相關(guān)資料：
https://blog.csdn.net/zhang_yin_liang/article/details/129469171
