重构程序的经验教训.

最大的教训,当然就是对程序而言.扩展性是非常重要的.
如果扩展性不行,就必须重构,然后各种编译时,运行时错误.
这样你以前调试好的程序就没用了.非常浪费时间及精力.所以程序的扩展性在一开始就要考虑好.

//错误的代码,可删掉.//可变成切换尾,再变回来,a,b交换//假如切换不对,这个就错了.显 切换子(向量<串>&o,极 为尾){//c,b,a断定(为尾&＃61;&＃61;1,"错误,要为1");串 无;x&＃61;切换尾;串2项(o,无,c,b,a);置y();}//这里单代表单符.不是串.
//不是这样切换的,切换要用&＃96;切尾&＃43;切回&＃96;.


目前而言.c&＃43;&＃43;的调试我都是用打印大法.不能根据不同的类进行开关.否则,把类名加入每个编译时参数及每个调试语句,又是很难受的.或者再继承一个调试标志,再初化.都不好.我也没有解决办法.
对于简单的规则而言,可以把许多规则都集中在一个配置文件.
别人的程序,因为配置项较多,就一样一个配置.我的简单,就集中在这一个配置文件.
把一堆难看代码,用一个简单函数包在一起.放在一堆.好看点.
感觉模糊测试没多大用.找不出啥问题.偶尔碰出来一两个,但都是运气.不如搞个完整的测试集.
我记得原来最喜欢用Shift&＃43;delete了,都养成习惯了.后来.这个方法要不得.因为偶尔动作太快,就
把对你有用的给删掉了.连后悔的机会都没有.于是,我只好养成只按一个delete的方法.还是爽,后悔的次数要少些了.
写程序的时候,编译时错误不是难点,运行时错误才是难点,很难找有哪些错,可能现在程序还有一些地雷.
写程序前,有些流程要搞懂.最开始写的时候,就是编程.但运行时,总是出错,就是流程搞错了.
先要干什么,再干什么,接着干什么不要搞错了.
还有尽可能的移动.,因为输入可能只是一次性的,不再用了.,这时就可移动了.
程序的逻辑一定不要出错.如如(小.成功&＃61;&＃61;0)下;//不成功,则下,这一句,要首先放在该段前面.要求必须成功.
如果失败,则下.
对基类的操作,会影响所有子类.对有些公共方法放在基类,调试时就要小心.
对基类.虚 空 函数()&＃61;0,表示虚函数.
把所有不要的函数(写错的函数)放在一个专门文件里面.这样文件也稍微干净点,有时看可以看看.
最坑人的是:
针对向量的判断如:如(依.大小()&&有一(依,m))中;.假设不要前面的依.大小(),则光是有一(依,m),你可能得出
的是错误结果.所以,要小心这种逻辑坑.
把一堆功能接近或关系紧密的代码另外单独放一个文件.主类里面不要放太多.最多4,5个大类就够了.不然,
太难看.
主类里面的数据,或不变的东西,都可以放在基类,不再考虑.只关注变化的东西.
复制过去的代码时,很多都调试好了,除了小细节,还是很容易的.主要是过去未提取出来,构成一个类.
一个类,其实就是个大函数.公开的方法或数据要少而精,而且不要变.不要像别人,新版本与旧版本不兼容.
我的接口都没变,怎么会不兼容?.
类中的临时数据跨多个函数,只好放在类中.不能放在方法里,该如何破?跨了3,4个函数.没法,只好放在类中,
但一定要注意,它只是临时数据.不能用的.
还是那个调试问题,不好解决啊.偶尔还是要用异常,没得法.

抓(文系错误&e){}抓(异常&e){静 出向量 出{"错误01.txt"};打印(e.什么());出.加(b);b&＃61;e.什么();出.加(b);}

很多时候错了,有可能是基础类有问题了.因为我的基础类并没有像别人那样经过充分测试.
所以,以后要加强测试/完整测试.这非常重要.
有针对性的测试比模糊测试强多了.模糊测试就是吹.
自己的文件或程序要经常使用,不要怕错.错才好修改.
我的文件里面注释比代码还多.就是要多写注释,实在烦的话,就另外放一个文件里面.
既干净,还可以看看当时想法.
c&＃43;&＃43;里面对类的成员函数很难用批处理.你不得不写对(动&p:列),这一句.很折腾.
类的依赖关系.要少.一定要仔细把握程序的流程.
最重要一点;所有程序块都要运行到.运行时错误,只有运行时才能发现,就只能测试时把所有块都测试到.
这样错误就可能少一些了.我在运行时,就发现错误跟着流程块走.先是第一块出错了.
再是第二块错了.基本上每写一块,这一块就有错.一会儿这个类错了,一会儿那个类错了.
错误何其多.所以,可以算写程序&＃61;写代码&＃43;写测试,必须重视测试.不能像微软,搞个AI测试,那是不靠谱的.
再说一遍:测试块,每块代码都要测试.这很重要,非常重要!