为什么在添加一个新功能前先整理代码？

       在添加一个新功能前，要先整理现有的代码，使其能非常容易的添加新功能。

      一直对这句话理解很肤浅，只是从字面意思理解而已。今天写代码突然有种感觉，好像自己理解了，所以拿出来和大家分享一下，也自己记录下来。

       我做一个库存管理的模块，在出入库时都会有更新库存台帐、更新库存账目和更新库存容量的动作，今天添加了一个盘点的功能，在盘点时也更新库存台帐、库存账目和库存容量。由于在盘点时，盘点物料明细中没有物料主键和库存主键，只有其名称，所以直接去更新库存账目和库存容量不能实现，只能从库存台帐中取物料主键和库存主键才行，然后才能完成功能，这样就有点走弯路。
        所以我把出入库的代码整理了一下，出入库时只更新库存台帐，把更新库存账目和更新库存容量的功能移到库存台帐的业务类中，这样在更新库存台帐时系统自动更新库存账目和更新库存容量。这样在盘点时只更新库存台帐就可以了。

常见的整理代码的时机有两个，实现一个功能之前，以及之后。

每一小块功能做完了以后应该始终给自己一点时间，消除显而易见的“坏味道”：长方法，重复，不清晰的条件逻辑，等等。这个时候的清理通常不会产生新的对象，因为这时候你通常不知道什么位置需要扩展。你只是让代码变得干净。

做新功能之前应该始终给自己一点时间，找出要做的事情和现有代码之间的关系：是修改，还是扩展。一个修改应该只影响一处代码，找到你应该修改的那一处。如果修改点/扩展点不清晰，重构让它变得清晰。然后再做你需要的修改。

现有的代码经常会被后来的代码使用到，就像大楼的基础，如果现有的代码不做整理，就好象地基不深、不牢，对整座大楼的质量会产生问题。

如果现有的代码会被以后经常用到,您是怎么编程的呀?难道凭着感觉,我要加功能了,所以改代码,而没有需求文档或者别的规范??我认为,软件设计时就应该考虑到软件的现有需求,还应该考虑到未来可能的需求..代码应该在功能之后整理就好了

2002年穿越过来的?

"坏味道"，好词，想不起在何年马月的一本书看过这个词了

我的推荐添加完功能后整理；有时间的话我会在功能添加前整理，完成需要添加饿功能后，再看看能否再整理。就是麻烦了点 ！！！
   "坏味道"没记错的话应该是来自 《重构 改善既有代码的设计》

我记得是gigix翻译的....

人们不喜欢增加功能代码的主要原因是恐惧.
------------------------------------------
装修有什么难的
为什么大家没事不装修?
1.家具放在哪里
2.就是拆墙,是否承重墙
3.刨地板,是否有管线
4.不能一间一间的装只能全装一遍,时间体力耗费大
5.不能确定自己的设计自己会满意
6.由于现在的装修还能凑合.
7.对装修公司的不信任.
-----------------------------------------

这与软件有太多相似之处了.

再来看看公司的装修
-----------------------------------------
1.吊顶.可以把以后所要加的可能性留出空间
2.全开间,可以用隔断来分割房间
3.地毯,不用刨地
4.工位都一个样子,想移就移了.

off topic 一个，为什么大家不按照公司装修的方法来装修呢？