写这三种代码，只能叫码农，不能叫工程师

如何评判一个工程师的能力，那么可以直接看他写的代码。我们常常用字如其人来描述对一个人的评价，虽然不够客观，但也有一定的依据，同样我们也可以用码如其人来衡量一个工程师，即便是架构师，也要好好写代码，只有好好写代码，才能够了解系统的细节，而细节，往往才是工程中的关键所在。

有国外媒体做过调查，下面这3种代码，是工程师们认为最难忍受的！写出这3种代码的，一般在CodeReview环节都会被狠狠地批斗。

1、重复代码

俗话说得好，抄代码一时爽，一直抄代码一直爽。俗话又说，抄代码一时爽，功能变更火葬场，我们平时做需求，最喜欢的莫过于这个功能改动有风险，不如把代码都拷贝出来，然后再改改。

我在上家公司，是做电商行业的，有部分的工程师就喜欢这么写代码，就拿交易结算成单系统来说，一开始我们只有自营的商城，写了一套结算成单系统，后来有了一些第三方商户，又把原来的代码拷贝出来，第三方商户的走第三方的交易成单，后来有了拼团订单再搞一套、CPS订单再搞一套，每套都包含整个交易的完整流程。一开始，这种模式的确能够快速迭代，而且每次都不改动旧代码，直到有一天，开始了增加一些新功能，例如支持会员积分，于是papapa，修改了6，7套代码支持积分，例如库存支持一些新的属性，例如我们新增了一些仓库，这些仓库要支持闪电送货，每次需求，都要改一坨代码，如果架构合理，对不同的模块进行合理的抽象，例如一次电商交易流程，无非就是查询商品数据、查询用户数据、计算优惠、计算库存、积分、计算物流、成单、支付等流程，不同的交易模式往往只是少数模块的区别，应该进行多态的方式去编码，后面维护的成本会低很多。有关电商的流程，大家可以关注我，后面可以慢慢介绍。

2、超长函数

3000行的函数见过么？1万行的函数我都见过。超长函数最大的问题，就是职责不清晰，这个函数当爹又当妈，最大的问题是，超长函数往往有其它副作用，例如一个临时变量一下子是放金额的一会就变成库存的id了，这都是非常容易留坑的，如果有人改代码，非常容易就踩坑。这是我遇到过的一个真实案例，有个开发小哥用一个临时变量，在一个分支内去做商品的优惠金额，另外一个分支内去做积分的数量，还有很多电商交易结算用到的其他内容，写了5000多行的结算系统。有一天，另外一个人来改这块代码，没有完全理解这个内容，就开始改了，完了，最后造成了线上0元单。

所以如果我们能够区分函数的职能，最好拆分出子函数，一个函数最多不要超过100行，做到函数名即注释。

3、超长参数

超长参数，是每个程序员看到都想砸键盘的事情，因为我们现在的代码往往有很多分层，要是一个方法增加了一个参数，往往要改动6，7处代码，这是很头疼的事情，如果提供新方法，又容易踩到重复代码的问题。所以，最好的方法是，除了一些底层的接口，上层的方法最好是采用Request的类进行传递，毕竟这个世界上还有比女人更善变的动物，那就是产品经理。

只要你能够避免上面这3点，相信你就能写出大家都能看懂，更重要的是，能够心平气和的去看的代码，当然，如果要写出更好看的代码，就需要进一步的学习，掌握一些设计模式，常用的语法糖，相关的数据结构与算法，做多codeReview，相信你也可以写出更优秀的代码。关注我，后面会分享程序员各种技巧，一起学习，共同进步。