在产品推向市场后，根据反馈信息对产品进行改进调整、升级换代是必不可免的，这也涉及到程序

1.写程序时，所有资源（IO口、RAM、ROM、堆栈、计数器、中断……等等）都是可用的，可以无拘束地使用；而改程序时，只能利用原先用剩下的资源。

2.写程序时，面向全局规划，可以合理安排各个功能的实现方法；而改程序时，是针对局部，为了避免影响其它部分功能，往往约束较大。

3.大多数人没有良好的编程习惯，事先不规划，事后不整理，脚踩西瓜皮，写到哪里算哪里。待到需要改动时，由于当时一些思路已经忘记了，没有留下足够的注释和说明文档，就摸不着边了。

4.由于没有一个统一的编程规范，如果原先的程序不是自己写的，那就更糟糕了。光看懂前任的程序就要耗费许多时间；而如果想较大面积地修改它，往往还不如自己重新写一个来得快些。

5.每次修改程序都是在原来程序的基础上打补丁，往往会为下一次的修改增加难度。最后，量变引起质变，活活把个好好的程序改烂掉了。

6.……

最近，坛子里，对编程方法思路等方面的讨论较多（而雕虫小技则遭受抛弃）。匠人也来凑热闹，请大伙来讨论：好程序如何才能经得起千回改？

 
一些不成熟的想法，权当抛砖引玉
 程序匠人 发表于 2004-7-30 11:34 侃单片机 ←返回版面   举报该贴

程序的改动大多数情况下都是伴随着硬件的改动。关于硬件的改动不是本贴的主题。不必作深入讨论。

程序如何才能经历岁月的考验，千锤百改，依然生机勃勃。一些不成熟的想法，权当抛砖引玉：

1.程序应该模块化，便于拆卸或增加。（这已经不算是新鲜观点了）。

2.使用RAM或IO，必须先定义再使用，避免直接引用。将来需要调整时，只要修改定义部分就好了。

3.相同或类似的程序段应该用子程序来实现，如果受堆栈等资源局限，不能使用子程序，则应该用宏来实现，这样以后需要改时，只要改一“点”，无须改一“片”。

4.写程序要有足够的注释、说明文档、流程图、原理图。便于以后能够快速勾起往日的回忆……

5.每次修改程序，应该同步更新相关的注释、说明文档、流程图、原理图。免得下次再改时对不上号。

6.应该详细记录每次程序修改的细节，形成一份历史记录。（强烈推荐这一点）

7.每次改动后的版本都应该保留。而不应该覆盖原始文件。

8.所有的设计方案应该妥善归类存档备份，有条件最好刻成光盘。避免日久年长因病毒或硬盘损坏而丢失。（别笑，真有丢了的。）

我想，“能够经得起千回改”是“好程序”的一个必要（不充分）条件。