认识达内从这里开始

当ui设计师在完成界面设计策划之后，一般都是由前端工程师来进行设计的重构，让图纸变成一个可以被访问的页面。那么，我们在重构的过程中，又是在什么时候进行的呢？下面我们就一起来了解一下关于界面重构的时候都需要注意哪些问题。

(1)当添加新功能时如果不是特别容易，可以通过重构使添加特性和新功能变得更容易。在添加新功能的时候，我们就先清理这个功能所需要的代码。花一点时间，用滴水穿石的方法逐渐清理代码，随着时间的推移，我们的代码就会越来越干净，开发速度也会越来越快。

(2)修改Bug的时候去重构，比如你在查找定位Bug的过程中，发现以前自己的代码或者别人的代码因为设计缺陷比如可扩展性、健壮性比较差造成的，那么此时就是一个比较好的重构时机。可能这个时候很多同学就有疑问了，认为我开发要赶进度，没有时间去重构，或者认为我打过补丁把Bug解决不就行了，不需要去重构。根据笔者之前多年的经验得出的结论：遇到即要解决即那就是每遇到一个问题，就马上解决它，而不是选择绕过它。完善当前正在使用的代码，那些还没有遇到的问题，就先不要理它。在当前前进的道路上，清除所有障碍，以后你肯定还会再一次走这条路，下次来到这里的时候你会发现路上不再有障碍。

软件开发就是这样。或许解决这个问题需要你多花一点时间。但是从长远来看，它会帮你节省下更多的时间。也就是重构是个循序渐进的过程，经过一段时间之后，你会发现之前所有的技术债务会逐步都不见了，所有的坑相继都被填平了。这种循序渐进的代码重构的好处开始显现，编程的速度明显会加快。

(3)CodeReview时去重构，很多公司研发团队都会有定期的CodeReview,这种活动的好处多多，比如有助于在开发团队中传播知识进行技术分享，有助于让较有经验的开发者把知识传递给欠缺经验的人，并帮助更多的人对软件的其他业务模块更加熟悉从而实现跨模块的迭代开发。CodeReview可以让更多的人有机会对自己提出更多优秀好的建议。同时重构可以帮助审查别人的代码，因为在重构前，你需要先阅读代码得到一定程度的理解和熟悉，从而提出一些建议和好的idea,并考虑是否可以通过重构快速实现自己的好想法，最终通过重构实践你会得到更多的成就感满足感。为了使审查代码的工作变得高效有作用，据我以前的经验，我建议一个审查者和一个原作者进行合作，审查者提出修改建议，然后两人共同判断这些修改是否能够通过重构轻松实现，如果修改成本比较低，就在Review的过程中一起着手修改。

如果是比较大型比较复杂的设计复查审核工作，建议原作者使用UML类序列图、时间序列图、流程图去向审查者展现设计的具体实现细节，在整个CodeReview中，审查者可以提出自己的建议或者修改意见。在这种情景下，审查者一般由团队里面比较资深的工程师、架构师、技术专家等成员组成。

关于CodeReview的形式，还可以采取极限编程中的“结对编程”形式。这种形式可以采取两个人位置坐在一起去审查代码，可以采取两个平台比如IOS和android的开发人员一起去审查，或者经验资深的和经验不资深的人员一起搭配去审查。

重构的这三个时机要把握好原则，即什么时候不应该重构，比如有时候既有代码实现太混乱啦，重构它还不如重新写一个来得简;此外，如果你的项目已经进入了尾期，此时也应该避免重构，这时机应该尽可能以保持软件的稳定性为主。

好了，关于界面重构的问题我们今天就给大家简单介绍到这里了，如果大家对网页设计或者网站开发感兴趣的话，可以与我们的在线咨询联系，获取更多材料进行了解。