写了7年代码，聊聊那些没人告诉你的程序员注意事项

刚入行那会儿我特别信一句话：能跑就行。功能测通了，提交，收工。直到有次线上出问题，我翻日志翻了两个小时，最后定位到一行判断写反了。要是日志打全一点，五分钟就能找到。后来我才明白，程序员踩的坑大多不是技术难度，是习惯。

代码是写给人看的，顺带让机器跑

我现在看别人的代码，第一眼看命名，第二眼看异常处理，第三眼才看业务逻辑。命名糊成一团，逻辑再漂亮也是负债。之前接手一个项目，里面躺着 data1、data2、dataList2 三个变量，我花了一下午才搞明白谁是谁。

• 变量名别用 a、b、tmp、data，三个月后你自己也看不懂
• catch 里不要只打一行堆栈，把入参和业务标识一起带上
• 关键分支加日志，日志里带订单号、用户 ID 这类能追下去的东西
• 单个函数超过 80 行就该拆了，拆完单元测试也好写
• 提交信息写清楚改了什么，别清一色 "fix bug"

还有个容易忽略的点：别在代码里埋魔法值。0、1、2 分别代表什么状态，只有当时写的人知道。定义成常量或者枚举，成本几分钟，省下的是后面无数次翻代码的时间。

需求没对齐，写多少都是白写

前年我做一个数据导出功能，产品说"导出全部"。我理解成导出当前筛选条件下的全部，做完演示的时候他说要的是全库所有数据。两天白干。这事之后我养成一个习惯：动手前用自己的话把需求复述一遍发给对方，对方回个"对"再开工。

边界情况是另一个重灾区。空值怎么处理、字段超长怎么办、同一秒进来两个重复请求算谁的，这些不写进文档，测试阶段一定炸。我现在会在接口文档里单独开一节"异常场景"，想到的都列上，哪怕最后不实现，至少大家知道有这回事。另外别怕问问题，卡在一个点上耗一整天，不如开口问一句。自己先查十分钟，查不到就问，这不丢人。

身体和节奏才是长期成本

久坐、熬夜、外卖，这三样凑一起，三十岁之后身体会给你寄账单。我认识一个做后端的哥们，连续三个月赶项目，最后腰椎间盘突出住了院，钱没多拿多少，罪没少受。我的做法是每工作 50 分钟起来走两分钟，买了个升降桌，晚上十二点前关电脑。听着像废话，但坚持半年，颈椎和眼睛的状态确实不一样。技术可以慢慢学，身体垮了学什么都没劲。

说了这么多，落到我自己的习惯上就三条：代码留痕、需求对齐、身体别透支。这些东西不写在招聘 JD 里，却决定了你能在这行走多远。