刚带团队那会我特别爱看别人代码，看得多了就发现一个规律，工资高的那批人写出来的东西不一定多花哨，但都有几个共同的小习惯。这些习惯不盯着屏幕看半天根本发现不了，可就是这些细节，把效率和安全都拉开了差距。
第一个习惯是写代码前先花十分钟理清数据流。月薪三万的同事接到需求不会直接开干，他们会拿张纸或者开个空白文件，把输入是什么，输出是什么，中间要经过哪些转换画出来。数据从哪个接口来，走到哪一步可能变成空值，哪些字段在哪个环节会被修改，全都在脑子里过一遍。等真正动手写的时候，函数之间传参就像流水线一样顺畅，很少出现调了半天发现某个变量根本没传过来的情况。
这个习惯最直接的好处就是省调试时间。很多人写代码像挤牙膏，写一行跑一次，报错了再改，改完接着往下写。看起来每一步都挺快，实际上碎片时间全浪费在切换上下文上了。人家先把路看清楚再走，一路走到黑不带停的。你看着人家半小时写两百行，其实人家那两百行结构完整，你写两百行要改四十处。
第二个习惯是每个函数只干一件事，名字起得跟大白话一样。看那些高薪工程师的代码，函数名读出来就知道里边干什么，calculate_total_price，validate_user_input，format_response_data。进去看函数体，少的十几行，多的三五十行，很少有超过一百行的。每个函数里只有一个循环或者一个判断，逻辑嵌套超过两层就得拆。有回我review一个同事的代码，发现他把登录验证和订单生成写在一个函数里，当时就让他拆了。他还不服气，说反正都能跑。结果隔两周需求变更，要加会员折扣，那个函数改起来差点把登录逻辑也弄坏。
拆得细有个实在的好处，就是每个函数都能单独测，单独改，单独替换。项目跑一年两年，需求变来变去，函数拆得越细，动一处影响面越小。你想想，改一个两百行的函数和改一个二十行的函数，风险能一样吗。
第三个习惯可能最容易被忽略，就是处理异常情况比处理正常流程还仔细。月薪三万的代码里，正常流程写起来反而快，基本的赋值、调用、返回。真正的功夫全花在那些“如果这里是空的怎么办”，“如果用户传了个负数呢”，“如果第三方接口超时了怎么降级”。他们会专门写分支来兜住这些边界条件，每个可能出问题的地方都有提前的检查。
有次线上出了个bug，用户提交订单时商品库存刚被清空，结果订单表里写入了一个负数库存。低工资的开发说这是并发问题，得改架构。高工资那个同事看了半天，说这叫没做前置校验。他在写扣库存那个函数的时候，早就把“库存小于要扣的数量”这种情况拦下来了，直接返回错误码，根本走不到写订单那一步。一样的问题，有人等它爆了再修，有人早就在源头给堵住了。
这三个习惯看着都不难，难的是天天这么做。写代码这件事实在是良心活，你糊弄它，它后面就在线上给你找麻烦。老板不是傻子，谁写的代码线上稳定，谁写的代码天天半夜被叫起来修bug，时间长了心里都有数。工资差的不是一星半点，差的就是这些平时看不见的功夫。
我见过太多人写了三年代码还在用全局变量，函数名起得跟密码似的，异常处理全靠try一包完事。他们觉得自己很忙，天天在改bug，其实那些bug一大半本来就是自己写出来的。把习惯改了，把活干利索了，你才有空去学新东西，才有空去思考更好的架构，这才是往上涨薪的那条路。
代码这东西，你认真对待它，它就不给你挖坑。你随便写，它还你一个只能靠加班撑着的项目。做久了你会发现，真正拉开差距的不是什么高深算法，就是这些每天重复的、不起眼的小动作。
