代码之美：命名、注释与重构的艺术

周末加班改bug时，隔壁工位的小王突然冒出一句："这段代码简直就像没洗的袜子堆！"我们凑过去看，发现前人写的函数里各种魔法数字、嵌套循环，活脱脱的"代码"。这让我想起刚入行时前辈说的："好代码自己会说话，坏代码天天说脏话。"编程中的virtue，正是让代码保持优雅的秘密。

藏在变量名里的善意

上个月帮实习生调试程序，看到他写的var a = [1,2,3];时，我仿佛看到自己刚毕业时的样子。好的命名就像给陌生人指路：

• 快递驿站原则：userDeliveryAddress比uda更易懂
• 时间胶囊测试：三个月后还能秒懂变量用途才算合格
• 避免精神分裂：整个项目保持camelCase或snake_case统一

命名美德对照表

函数设计的边界感

就像微波炉不该兼任洗衣机，函数也应该保持单一职责。上周重构的订单系统，把原先120行的processOrder拆分成：

• validateInventory
• calculateDiscount
• generateInvoice

现在新人接手调试，再也不需要带着救生圈跳进代码海洋了。

注释的正确打开方式

见过离谱的注释是// 这里要改，但暂时没空，结果三年都没人动。优质注释应该像博物馆讲解牌：

• 解释为什么这么做，而不是复述代码动作
• 标记临时方案时必须带TODO和日期
• 遇到复杂算法时画ASCII示意图

注释类型对比

版本控制的君子协定

上周五部署失败，查到后发现是某同事的commit message写着"fix bug"。好的提交记录应该像快递单号：

• 使用feat:/fix:等语义化前缀
• 关联JIRA编号或issue链接
• 正文说明改动背景及影响范围

午休时看见测试组的妹子在翻《重构：既有代码的设计》，书页边角已经卷起。窗外的云朵慢慢飘过，会议室传来产品经理的笑声，这样的下午适合泡杯咖啡，给那个200行的函数做个大扫除。