EEPW论坛

在产品推向市场后，根据反馈信息对产品进行改进调整、升级换代是必不可免的，这也涉及到程序部分的改动。但是，好程序也怕千回改，大凡写程序的人都会有这种体验，就是宁可写程序，不愿改程序，原因如下：


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


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


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


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


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


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


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


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


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


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


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


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


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


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


8.所有的设计方案应该妥善归类存档备份，有条件最好刻成光盘。避免日久年长因病毒或硬盘损坏而丢失。
我想，“能够经得起千回改”是“好程序”的一个必要（不充分）条件。