C端代码要求规范心得体会与经验总结

1.入参一定要校验

对于入参的必须参数，需要进行校验，要求不能为空且合法/符合逻辑，对于不符合预期的入参，要及时抛出异常

2.异常不能漏

对于可能发生的异常情况，要在catch中进行打点，对于可能不符合预期的数据（如从下游获取的数据），也要对可能产生的不一致进行校验，并进行打点，利于进行链路监控，在出现bug时及时定位原因。

此外，还要进行业务兜底，C端是敏感的，不要把异常暴露给用户，把兜底的逻辑做好，保证有基本的返回。

3.不要在代码中进行硬编码

涉及配置项的内容，可以放到配置中心，或者定义Config类，就是要把涉及核心逻辑的数据外置，降低方法内的耦合，提高内聚。

4.每个方法完成独立的功能

对于一些数据拼接的操作，数据处理，数据转换等，定义单独方法（如build…）来做这样的事情，把不关联的逻辑都单独抽成一个方法，理想的状态是，每个方法要解决的问题是十分明确的，每一步都是核心

的逻辑。可以打一个比喻，把大象放进冰箱分几步？第一步，打开冰箱，第二步，把大象放进冰箱里，第三步，把冰箱门观上。如果要写一个方法

public void putElephantsIntoIcebox(Elephant elephant){
	//第一步，打开冰箱
  openIcebox();
  //第二步，把大象放进冰箱里
  putIn(elephant);
  //第三步，关闭冰箱
  closeIcebox();
}

如果这就是我们的核心任务，那这个核心逻辑就只应该包含这三个方法，而具体如何打开冰箱，用手打开，用棍子撬开，用炸药炸开，，，这些是具体的实现方法，你可以用策略模式解耦，手就写手如何开的实现，棍子就写用棍子撬开的实现，炸药就写用炸药炸开的实现，它们都是完成一个功能，那就是打开冰箱。这些不要放到这个核心的方法里去做，而是定义一个“打开冰箱”的方法。每个方法应该是高内聚的，它专注于完成自己的事情。如果各个函数实现的功能混乱，会给代码维护带来很大的困难，这也是为什么要一直去进行代码维护和优化的原因。

5.合并逻辑，减少不必要的代码

这个环节就比较见仁见智了，理想的代码最好是每一行都是必须的，多一行浪费，少一行不行，没有不必要的逻辑，也能很大程度上提高代码的简洁性。而能做到这一点，我认为最重要的是对业务的理解，对业务的理解越清晰，越能明白哪些是需要的哪些是不必要的。

总结

根据我目前的总结，在完成代码功能的基础上，不断进行代码优化，这就是“测试驱动开发”，每一步都是可测的，可测试，也可观测。而优化的方式，目前看来都属于上述五种的一种，在进行代码优化却又不知道该如何实现时，可以对于每个核心而又待优化的方法，分别考虑以下问题：

1.如果这个方法出了问题，该如何观测？想象自己排查的步骤，便知道哪部分需要catch异常，哪部分需要打印日志，而哪部分又需要打点。

2.这个方法是否是给外部调用或涉及rpc调用？是的话，要进行参数校验，结合业务考虑各种可能的情况，并且要保证有兜底去返回。

3.是否有些配置项相关的可以提取到Config或者配置中心？把涉及的常量从方法中拉出来

4.当前方法实现的内容是什么？是否有不应该出现在当前方法的逻辑？有些和核心逻辑不想干的代码，应该放到其他方法中去实现

5.当前要实现的逻辑是什么？是否有冗余的部分？结合业务思考！

代码的规范和优化理论上是共通的，只是C端更加敏感，要求遵循的规范会更加严谨！这些经验在写各种代码时有意识的去运用，就可以提高代码的质量和可维护性。