[色彩构成采集与重构]漫谈重构.doc

[色彩构成采集与重构]漫谈重构 篇一 : 漫谈重构 因为工作内容的原因，我在前后两家公司中的工作中主持和经历了十余次代码和架构的重构，下面随便说说我对重构的一些经验和想法。 首先重构面临的背景都是相似的，程序员们为了快速完成需求和上线而写出了最基本的代码，而在功能的不断扩充过程中，以打补丁的方式对代码进行扩充，中间还会面临着开发人员的变更和离职。逐渐的，代码就会越来越臃肿，渐渐的变得难以维护。 糟糕的架构会有什么样的影响？首先是开发效率的降低，在糟糕架构下加进新功能，会受之前代码的影响，可能存在意想不到的改动点和问题点，开发和调试时间都会大大增加；其次是故障率的提升，在质量低下的代码中，总是容易藏着很多不易发现的坑，这些都会成为故障的隐患；同时，架构也会使得需求的完成大打折扣，使得设计好的目标，因为架构限制或者性能等原因，只能完成80%甚至更低。 重构不能凭空重构，一定是要解决一个问题，一般情况下重构要解决的问题大致有以下几种。 重构时，第一道难关是如何过领导这道关。很多领导都要背着产品指标和任务，大多人也更关心其能够在多长时间做出什么，重构这种事情，在很多时候，有可能是“费力不讨好”的代名词，因为在大多情况，无法帮助领导完成指标。这种情况下，如何获得领导的支持就极其重要了。 对于重构，一种方法是，让重构与某些技术或产品指标挂钩，例如完成新产品、改进效果、提高性能等，相当于是重构伴随着其他改进搭帮上线，那么这种情况可以比较顺利的完成重构。 而如果单纯的为了架构的合理性而去重构的话，就需要去说服领导，为什么原来的架构会降低开发效率，新做的架构能带来哪方面的提升。一定要让领导明白，这个能带来实实在在的长期收益，不管性能、效率、安全等都可以，而并非只是“看着不爽”而进行的重构。 如果团队规模有一定的人的话，也可以分出一部分进行新型架构的开发，而另一部分人在现有架构上进行改进，使得短期目标和长期目标两不耽误。这时候，值得注意的就是，不管从代码还是设计角度上来看，都要让现有做的事情能够复用，而不是新架构上线之后就会被废掉。 如何进行渐进式重构，也是很多架构师需要去思考的问题。就是不搞一下子半年一年的重构，而是以月为单位，快速的迭代，能够很快的看到效果，并且小规模投入使用。 不管怎样，重构，一定不能是为了重构而重构，或者对前人的代码看着不爽，或者抱有技术完美主义而进行重构，最重要是找准其要解决的实际问题，这时候的重构，能带来的是开发效率上的提升。 而在重构的过程中，也需要做好新架构的设计，并且拥有一定的前瞻性，否则很容易出现新架构、新新架构、新新新架构这样子的事情。另外，也要尽可能的增强代码的复用性，让其中的模块，在任何一个架构中都能够很好的被应用，当然这个要根据具体情况具体分析。 对于重构，也尽量不要拥有技术完美主义。很多时候，使用最成熟的方案及最简单的架构模型实现所需要的功能一般来说更加“简单可依赖”，有的时候架构过于复杂反而喧宾夺主，因为所有架构都是为了功能服务的。同时，也尽量不要使用很多未经广泛使用的前沿技术，因为这些在开发和部署过程中，很多都可能会遇到意想不到的问题，延缓开发速度并影响线上效果。 此外，作为重构时的负责人，一定要紧跟代码开发的过程，并随时进行指导，一般情况下，不要相信写出糟糕代码的人，经过略加指导就能写出漂亮代码了。我曾经有过这样的经历，要将一个超大的类按照功能进行模块化拆分，设计好了架构及每个子模块就让组员进行开发。开发完了我看代码时登时就抓狂了，模块是拆分了，每个功能也都建立好了子类，并通过主类调用子类，但是每个子类又都将主类作为友元，又去调用主类里面的成员变量和函数。这种代码，再次重构也是难免的，这个给我的经验教训就是，重构的工作一定要做细，迭代中的代码检查也是必不可少的。 当然，重构再怎么样，也是一种推翻重做，耽误时间的做法。从我的经验来看，其实大多数的重构都是可以避免的，这需要从以下几个方面去提高。 良好的编码风格，好的习惯往往很难是天然形成的，更多是在工作中不断的老带新中耳濡目染练出来的。很多领导希望员工全部时间都用来做项目，不断地去压更多的活，实际上是在用跑短跑的方式跑长跑，很容易出现后劲不足的情况。而我在微软的经历，也让自己感受到了从潮手到逐渐成熟的过程，后来在搜狗时即使再忙没法搞teamreview，我也会去尽量给每个组员检查他们的代码，帮助别人去提高。 初期的架构设计，这个也是非常重要的。架构设计能不能一次到位，这个不太好说。但是相信好的架构，一定比粗糙的设计能够坚持更长得多的时间。并且好架构可以考虑到未来可能扩充的规模和功能，为未来的发展留好接口。同时在其中所有的