参数判断的重要性

后端开发中，参数判断容易让人忽视，很多时候，参数判断出现遗漏，然后不得不在业务处理中作出补丁，其实现在想来，违反了编码的规则和优雅度。

参数判断作为任何一个接口开发的首要步骤，是万万不能省略的，任何接口的第一层，就是参数判断，参数数量，字段是否存在，这些判断，是业务逻辑开始的前提，业务逻辑是构建在这个基础上的，业务逻辑中不该再出现补丁一样的参数判断。

关于重构

业务逻辑开发中需要时刻关注重构，当然，不是说任何时候都建议重构，一旦代码上线，任何形式的重构都是需要谨慎对待的，毕竟一旦出现错漏，会出现严重的生产事故。

在开发中应该秉持着时刻重构的心，为啥这么说呢，因为业务逻辑的抽象是一个渐进发展，循环往复的过程。

二八定律与代码演进

很多时候都需要代码升级，但是不会有人提议说项目伊始就整个无比复杂的代码，各种安全措施全部加上，因为安全措施越多，代码维护越难，需要的基础工作也越多，感觉还是符合二八定律的，可能做百分之八十的隐藏工作，才能够保护百分之二十的功能代码，真正起作用的就那百分之二十代码，剩下的百分之八十代码都是没用的，这个没用是指在安全的操作前提下。

所以，为了更快的响应变化，这百分之八十的代码是否需要加，什么时候加，自然就变成一个渐进过程了，当业务量增大到一定程度，会发现，增加那百分之八十的代码，会带来超过百分之八十的工作量的回报，那这个时候就是动手的时候了。

方法粒度与重构

那如何才能更好的重构呢，感觉需要对方法进行专用化，一个方法尽可能解决一个问题，但是这个方法粒度同样也需要掌握分寸。

就是如果这个方法的复用性很高，那么这个方法就需要尽可能做到细粒度，做到细粒度就说明这个方法出问题的概率低，因为方法本身极为纯粹，简单，那么重构时候，只需要直接引用该方法即可，这个方法本身基本不需要修改，重构的是使用这个方法的上层方法。

如果一个方法四五个输入，七八种组合，十来种输出，那么，每次重构都会提心吊胆了，生怕哪个环节出错，拆了东墙坏了西墙。

可读性与复用性的平衡

这个是有点难的，因为人的逻辑思维是连贯的，一杆到底是很正常的，在写业务的时候，还要想着拆分，是有考验的，同时，维护的人也不想修bug时候看个业务逻辑，往下跳个十来个下级方法吧，那种看着看着就不知道在看啥的感觉，导致代码可读性很差。

所以要形成关键方法细粒度化，同时业务逻辑方法整体分层控制在几层之内，也就是，几层方法中，某些层是极为精简的，这些方法可以被其他业务复用，有些方法则是和本身业务逻辑高度绑定的，可复用性差，又没有差到完全无法复用。

感觉这既是编码的高级阶段了，可读性，复用性相互平衡。

参考资料