业务场景

  • 我刚开始写js代码的时候，经常会这样去写js代码：如果给出了一个需求，那么我会去写一个函数来实现这个需求，于是我很自然、从容地从头开始写，写着写着，写到最后发现这个函数代码量是惊人的多，到这一步我还是没有意识到这样子写造成的严重问题！反而我更觉得自己是有多么牛逼写了这么长的一段我自己都很去看懂的代码。后面我发现问题来了：1、如果我在一个文件里面写了几个函数，我发现这几个函数之间有相同的部分，我为什么不能把它提炼出来公用呢？这样减少了每写一个函数重新写一遍公共部分的时间，同时也提高了代码的复用率、减少了文件的大小，这在网络中就很有利于减少传输时延；2、假设某一天决定更改代码逻辑或者修改bug的时候，这才是最痛苦的时候，因为很难找到你想改的那个部分，即便你认为你自己很清楚你写的代码，你也不敢随意改，因为这些代码有很强的关联性，万一改这里会影响其它地方怎么办？还有毕竟时间长了，你肯定会对自己写的代码忘乎所以的！3、恕我直言，这样写代码真的很不美观！

能解决的问题

  • 1、能有效提高代码的复用率，因为你函数代码在减小的同时，实质上是在做把一个复杂的功能用一些很小的、独立开来的、可复用的小功能函数了，这些“小函数”不仅能在当前的函数里面调用，也可以在其它业务函数里面调用，所以可以有效的提高函数复用率！

  • 2、减少了函数的之间的耦合，更便于查找、分析及调试问题。比如当某段很长的代码被分解到一些很小的代码块之后，这些代码之间联系减少了，因为它们都可以单独作为一个功能函数，当某个时间段需要修改代码逻辑的时候，就不用去改那个原本很大、很难看出问题的代码了。而是找到对应的功能部分，从而只改那一部分，而这样改又不会影响其它部分，这将是一个对于你工作很轻松的一件事情。就好比一个很复杂的建筑被分离成一些小部件之后，你就能找到其中的每个部分的代表房子的哪个部分了！

  • 3、良好的注释作用，因为如果分离出来的小功能函数再给它一个很好的命名的话，那么这个本身就是一种很好的解释作用，远远胜过于你写了很长一段冗长的代码，让你“丈二的和尚摸不着头脑”！

案例