在產品推向市場后，根據反饋信息對產品進行改進調整、升級換代是必不可免的，這也涉及到程序

1.寫程序時，所有資源（IO口、RAM、ROM、堆棧、計數器、中斷……等等）都是可用的，可以無拘束地使用；而改程序時，只能利用原先用剩下的資源。

2.寫程序時，面向全局規(guī)劃，可以合理安排各個功能的實現方法；而改程序時，是針對局部，為了避免影響其它部分功能，往往約束較大。

3.大多數人沒有良好的編程習慣，事先不規(guī)劃，事后不整理，腳踩西瓜皮，寫到哪里算哪里。待到需要改動時，由于當時一些思路已經忘記了，沒有留下足夠的注釋和說明文檔，就摸不著邊了。

4.由于沒有一個統(tǒng)一的編程規(guī)范，如果原先的程序不是自己寫的，那就更糟糕了。光看懂前任的程序就要耗費許多時間；而如果想較大面積地修改它，往往還不如自己重新寫一個來得快些。

5.每次修改程序都是在原來程序的基礎上打補丁，往往會為下一次的修改增加難度。最后，量變引起質變，活活把個好好的程序改爛掉了。

6.……

最近，壇子里，對編程方法思路等方面的討論較多（而雕蟲小技則遭受拋棄）。匠人也來湊熱鬧，請大伙來討論：好程序如何才能經得起千回改？

 
一些不成熟的想法，權當拋磚引玉
 程序匠人 發(fā)表于 2004-7-30 11:34 侃單片機 ←返回版面   舉報該貼

程序的改動大多數情況下都是伴隨著硬件的改動。關于硬件的改動不是本貼的主題。不必作深入討論。

程序如何才能經歷歲月的考驗，千錘百改，依然生機勃勃。一些不成熟的想法，權當拋磚引玉：

1.程序應該模塊化，便于拆卸或增加。（這已經不算是新鮮觀點了）。

2.使用RAM或IO，必須先定義再使用，避免直接引用。將來需要調整時，只要修改定義部分就好了。

3.相同或類似的程序段應該用子程序來實現，如果受堆棧等資源局限，不能使用子程序，則應該用宏來實現，這樣以后需要改時，只要改一“點”，無須改一“片”。

4.寫程序要有足夠的注釋、說明文檔、流程圖、原理圖。便于以后能夠快速勾起往日的回憶……

5.每次修改程序，應該同步更新相關的注釋、說明文檔、流程圖、原理圖。免得下次再改時對不上號。

6.應該詳細記錄每次程序修改的細節(jié)，形成一份歷史記錄。（強烈推薦這一點）

7.每次改動后的版本都應該保留。而不應該覆蓋原始文件。

8.所有的設計方案應該妥善歸類存檔備份，有條件最好刻成光盤。避免日久年長因病毒或硬盤損壞而丟失。（別笑，真有丟了的。）

我想，“能夠經得起千回改”是“好程序”的一個必要（不充分）條件。