认识重构
- 本人所在的技术部有很多的产品，面向不同的用户，产品的建设过程是依赖于需求推动的。当需求明确之后，往往会伴随快速的开发，并且因为开发人员的经验，导致不同的代码模块会有不同的代码质量。当产品在演进过程中，发现不得不重构的时候，往往就已经到了非常难的境地。而重构带来的代码清晰，结构清晰，质量和稳定性还有效率都更提高的方式，能够使产品更为的健康。除了产品健康以外，重构的过程也能锻炼技术人员的技术思维和技术能力，使得他在构建另外的产品或新的任务时，能够规避已经发生的问题，获得更好的提高。长期来看，无论是人员经验的提升，还是产品健康度的提高，无疑为这个团队和这个团队所承接的产品起到了非常正向的作用。
- 一个能够提出重构工作的开发人员，是他的主动性和能力的体现。
为什么大家不愿意做这项工作？
这里我们从不同的视角来看待这个问题。从组织和领导的视角来看，如果组织层面或领导的风格，并不认为这是一件很有价值的事情，那么往往在推进的过程中，团队会自然而然的以交付为主而放弃质量；从个人来看，当我对这段代码重构的时候，很容易陷入不改，则没有问题，改则出问题的境地，那么出问题又要需要承担缺陷带来的影响，这就是所谓老的传统企业的，少做少错多做多错不做就不错；组织如果是快速变化缺少稳定性的，那么必然会追求短期的利益而重构，只会带来长期的利益，可能与团队的或者是团队领导人的利益的预期不一致。
但是我们要看到作为技术团队中的一员，产品的健康度和代码的清晰是技术团队产生的直接价值，而所谓的产品的推广程度，还有用户量，则更多是以业务和运营驱动的结果。所以代码质量将是技术团队的核心竞争力，我们丢弃了重构的主动性，则同时丢弃了随时改善代码的可能性，因为代码不是一朝一夕的，不是通过一次大的运动就可以解决质量的问题。
如何解决？
- 组织层面尽量让技术团队面向的产品和用户相对稳定，规避人员和团队的快速调整，使大家只重视短期利益，长期利益就会被忽略。
- 领导在追求长期利益的前提下，应该更多的关注代码的质量，并且认识到好的代码质量是长期效率提高的基础。可见的是，一个结构清晰代码的产品，无论是演进还是迭代，都将事半功倍；一个长期处于亚健康的产品，将在后续的演进中投入更大的开发，收获更小的成效。
- 团队应该以质量为第一目标，鼓励大家在发现产品代码质量的问题是第一时间评估解决，任何为了工期赶进度而丢掉代码质量的风气，都会被无限放大，最终导致失控。
- 团队应该给每个人都会有清晰的负责的模块，包产到户，这样他就会对自己负责的代码的部分有更好的设计与开发。
- 个人应该认识到，重构这项工作对个人能力的成长，还有个人实现自身的价值是一个非常重要的渠道。
