<h1 id="toc_0">代码重构会不会太low?</h1>html
<p>说到重构，其实可能每一个人心中的理解都不太同样。</p>程序员
<p>单纯意义上来讲，重构是对代码的再调整，在不改变业务逻辑的前提下，下降代码的长度、圈复杂度、重复度，提升其可读性、可维护性和可扩展性。简单来讲，就是把代码整的规整干净，逻辑清晰，井井有条。</p>数据库
<p>然而，这每每不是产品线但愿获得的答案，不一样的产品线在和咱们接触的初期，都会很明确的说，个人系统须要重构。但当咱们介绍完什么是重构，若是作重构时，或多或少的，对方会流露出失望或者不觉得然。</p>编程
<p>做为一个程序员，我固然知道对方在想什么，把代码整这么漂亮有什么用呢？系统只要没有bug就好了；咱们没有这么多时间花在这种费力不讨好的事情上。</p>设计模式
<p>码神训练营有一节“编写可读代码的艺术”的培训课，教如何写clean code的同时，还有一段专门讲重构代码。听培训的同窗多半兴趣度不高，然而看起来简单的规则，其实不是每一个人都真的理解和玩得转。</p>缓存
<h2 id="toc_1">来点咱们真正须要的吧！</h2>架构
<p>产品线关心的是改善他们的业务痛点，因此常常会有人纠正咱们说，大家说的代码级的重构，咱们说的是架构级的重构。</p>并发
<p>不一样的产品线的业务痛点可能不尽相同：</p>数据库设计
<blockquote> <ul> <li>代码复杂度高，分支多，动辄上千上万行的代码，致使问题难以定位，测试覆盖不到，也不敢轻易修改；</li> <li>相似的bug反复出现；</li> <li>系统间耦合紧密，单个功能点的修改每每或涉及多处代码的修改，或者单个功能的延迟致使整个系统没法上线；</li> <li>系统的CPU占用率高，Memery占用率高，要吗卡死，要吗直接挂掉；</li> <li>系统响应慢，用户抱怨多；</li> <li>并发致使的各类不肯定bug，测试环境复现不了，一上线又冒出来；</li> <li>等等；</li> </ul> </blockquote>函数式编程
<p>因此，产品线的指望很是明确，我但愿经过架构重构，改善以上状况，至于代码漂不漂亮，并不重要。</p>
<h2 id="toc_2">目标很远大，现实很骨感</h2>
<p>这种想一步到位，一针见血的想法能不能作到？我想若是是在传统行业，有了解产品整个成长过程的工程师，代码通过深思熟虑的设计，仍是有可能作到的。</p>
<p>惋惜对于高速发展的互联网来讲，人员流动快，产品上线压力大，这种任务几乎就是mission impossible了。</p>
<p>不少人想到了，既然原来系统这么庞大，还没人熟悉，干脆重写得了。问题是谁能保证新写出的系统能比老系统更好，前人填过的坑，都能在新系统中一一规避呢？</p>
<p>因此，咱们可能仍是须要从代码重构下手。</p>
<h2 id="toc_3">用重构打开系统优化的大门</h2>
<p>咱们团队有一个说法叫“小步快跑”，其实我还想到一个说法叫“星星之火，能够燎原”。把代码的复杂度降下来，重复度降下来，不是最终目的，只是最初手段。</p>
<p>几乎我碰到的全部重构项目，在重构早期，面对系统已有的问题，接手重构和咱们的同窗有时会哀声叹气，都有种无从下手的感受。然而随着重构的深刻，对系统的改造开始不仅仅局限在代码上，方案也开始逐步清晰。手段和方法开始不断涌现：</p>
<blockquote> <ul> <li>采用面向过程编程，仍是面向对象编程，仍是函数式编程？</li> <li>可否引入DSL，代码生成等方法？</li> <li>是否须要引入设计模式，例如策略，桥或者状态机？</li> <li>是否须要并发，是否须要同步？</li> <li>是否须要数据缓存，是否须要事件驱动？</li> <li>业务模型是否合理，数据库设计是否合理？</li> <li>系统分层是否合理，是否作到了单一职责，高内聚，低耦合，可扩展？</li> <li>系统配置是否合理，启动参数是否合理，线程池是否合理？</li> <li>业务逻辑是否恰当，流程是否清晰？</li> <li>等等</li> </ul> </blockquote>
<p>以上这些手法，将再也不被认为耍花腔，over design，而是重构系统后应运而生的最佳方案。<br/> 一个几十万行代码的系统，它庞大，复杂，没有头绪，若是盲目的下手，可能会带来整个系统的崩盘。而重构的做用，就是从一处着眼，把相对独立的部分重构成如乐高积木块的一个单元，而后逐步扩散，剥离无用的部分，清理出主线，最终实现一个清晰可扩展的系统。</p>
<p>因此，其实重构能够说很简单，也能够说很复杂。不过有了代码重构这个钥匙，再厚重的大门，也是敲得开的。</p>
<h2 id="toc_4">让重构成为一种生活习惯</h2>
<p>无论怎样，要把系统重构或者优化到满意的状态，特别是一个已经有几十万行的代码的系统来讲，都不是一朝一夕能完成的工做。他须要和开发团队的总体配合和新需求的共同排期。与其让系统有一天膨胀到走不动的时候才想起重构，最好的办法，仍是把重构融入到平常的工做中。一个好的工程师，或者工程师团队，应该敏锐的及时意识到系统即将面临的问题，并及时引入重构。</p>
<p>或许有些你们都认为合理的事情，实际上是不合理的：</p>
<blockquote> <ul> <li>你的产品真的须要这么多代码吗？</li> <li>这个系统真的须要这么多子系统吗？</li> <li>团队中真的须要这么多人吗？</li> <li>相似的功能真的须要反复开发吗？</li> <li>你真的须要每天加班吗？<br/> 经过持续的重构，防止代码腐化，保证代码的简洁高效，让它适应新的产品需求，或许会是以上问题的一个良方。</li> </ul> </blockquote>
<p>最后说一句口号，你不是码农（屌丝），你是软件工程师（白富美），你更是意识构建的“艺术家”（高大上）。<strong>代码能够像一堆杂草，也能够如变形金刚，好与坏全在你一念之间。当咱们接手一堆烂代码时，除了骂骂前面挖坑的人，也提醒本身不要成为下一个被骂的人。</strong></p>
原文出处：https://www.cnblogs.com/wangtcc/p/10603000.html