前几天在澳门大三巴附近的一家咖啡馆里，我碰到了老周。老周在圈子里有个外号叫"码神"，倒不是说他技术天下第一，而是他写代码有个特点——能用最土的办法解决最刁钻的问题。那天他刚从一场技术沙龙下来，手里还攥着半杯凉掉的冻柠茶，跟我聊了整整一个下午。我把他说的那些东西整理了一下，有些是技巧，有些是思路，还有些纯粹是踩坑踩出来的经验。这些东西在正经的教程里不太看得到，但真到了项目里，往往就是这些边角料能救命。

一、别急着写代码，先把数据结构想清楚

老周说他在澳门这边带过几个刚毕业的年轻人，发现一个通病：拿到需求就开始写函数，写着写着发现数据传不过去，又回头改结构，改完结构发现接口对不上，再改接口，最后整个模块像打满补丁的旧衣服。他的建议很朴素——花二十分钟把数据结构画出来，比写两百行代码都有用。

他举了个例子。之前有个项目要做澳门各堂区的人口流动统计，原始数据是一堆带时间戳的记录。年轻人上来就想用数组存，然后每次查询都遍历一遍。老周看了一眼，说你把时间戳当键，用哈希表按小时分桶，每个桶里再按堂区做二级索引。改完之后查询速度从三秒多降到几十毫秒。数据结构对了，算法甚至不需要优化。

他还提到一个细节：很多人喜欢用嵌套很深的字典或对象，觉得灵活。但老周说，嵌套超过三层的结构，维护成本会指数级上升。他的做法是扁平化，用组合键或者单独的索引表来关联。代码看起来多写了几行，但半年后回来看，能省下大量挠头的时间。

二、日志不是用来"有"的，是用来查的

老周对日志这件事有执念。他说他见过太多项目，日志打得密密麻麻，真出了事却什么都查不出来。问题出在哪儿？出在日志只记录了"发生了什么"，没记录"为什么发生"。

他的做法是每条关键日志必须带三个东西：上下文标识、决策依据、预期结果。比如处理一笔订单，日志里会写"订单ID xxx，用户等级为黄金，依据规则表R12给予九折，预期金额xxx"。这样一旦金额不对，直接搜订单ID就能看到整个决策链条。

他还强调日志分级要克制。DEBUG级别的东西在线上环境基本是噪音，INFO要留给真正重要的状态变更，WARN和ERROR必须能触发告警。他见过有人把用户输入校验失败也打成ERROR，结果告警群每天响几百次，最后所有人都把告警静音了，真出事的时候没人知道。

另外一个小技巧：日志里的时间戳统一用UTC，但显示的时候转成本地时区。澳门这边有时候跟内地、香港、葡萄牙的团队协作，时区混着来，不统一的话对时间线能对到崩溃。

三、异常处理不是try-catch就完事了

聊到异常处理，老周叹了口气。他说现在很多代码里的try-catch就是个摆设，catch块里要么打印个e.printStackTrace()，要么干脆吞掉。他管这叫"异常黑洞"——出了问题，程序不崩，但行为完全不对，查起来比直接崩溃还难。

他的原则是：能处理的异常才捕获，不能处理的让它往上抛。什么叫能处理？就是你有明确的补救措施。比如网络请求超时，你可以重试；文件不存在，你可以用默认配置。如果只是"捕获一下让程序别崩"，那还不如不捕，让进程挂掉至少能触发告警。

他还提到一个容易被忽略的点：finally块里不要写可能抛异常的逻辑。他之前排查过一个bug，数据库连接在finally里关闭，但关闭操作本身抛了异常，把try块里的原始异常覆盖了，结果日志里看到的全是关闭失败的报错，真正的问题被埋了。后来他改成用try-with-resources或者手动判空关闭，问题才暴露出来。

关于重试，有个坑要避开

老周说重试机制是个好东西，但很多人用错了。最常见的错误是无差别重试——不管什么异常都重试三次。如果是网络抖动，重试有用；如果是参数错误，重试一万次也没用，反而浪费资源。他的做法是给异常分类，只有明确标记为"可重试"的才走重试逻辑，而且重试间隔要指数退避，别搞成固定间隔把对方服务打垮。

四、命名这件事，值得多花五分钟

老周说他判断一个代码库的质量，有时候不看架构，不看设计模式，就看变量名。如果满屏的data、info、temp、flag，这个项目大概率维护得很痛苦。

他的命名习惯是：变量名要能回答"这是什么"和"用来干什么"。比如同样一个布尔值，叫flag没人知道什么意思，叫isEligibleForDiscount就一目了然。函数名要用动词开头，processData不如normalizeUserInput来得清楚。类名要避免Manager、Helper、Util这种万能后缀，因为一旦用了这些词，说明这个类的职责没想清楚。

他还提到一个细节：缩写要统一。项目里如果用了cfg表示config，那就全项目都用cfg，不要一会儿cfg一会儿conf一会儿config。这种不一致看起来是小事，但搜索的时候会让人抓狂。

五、版本控制不只是commit和push

老周说他在澳门带团队的时候，发现很多人的Git用法停留在"写完代码，git add .，git commit -m 'update'，git push"这个阶段。他说这样用Git，等于买了一辆跑车只在小区里开。

他的建议是：commit要原子化，一个commit只做一件事。修bug的commit不要混着新功能，重构的commit不要混着格式化。这样出问题的时候，revert或者cherry-pick都方便。commit message要写清楚"为什么改"，而不是"改了什么"——因为改了什么看diff就知道，为什么改才是关键信息。

他还推荐用rebase来保持提交历史整洁，但强调一条铁律：已经推到远程的公共分支不要rebase。他自己吃过亏，有一次在共享分支上rebase，把同事的提交搞乱了，花了半天才恢复。

分支策略要简单

老周说他不喜欢复杂的Git Flow，什么develop、release、hotfix一大堆分支，小团队根本管不过来。他的做法是主干开发，功能分支短期存在，合并后立刻删除。发布用tag标记，紧急修复从tag拉分支，修完合并回主干再打新tag。简单，但够用。

六、性能优化要先测量再动手

老周说他见过太多"我觉得这里慢"的优化，改了半天，性能没提升，代码可读性倒是降了不少。他的原则是：没有 profiling 数据，不动性能。

他分享了一个案例。之前有个接口响应慢，团队里有人说是数据库查询问题，有人说是序列化问题，吵了半天。老周拿火焰图跑了一下，发现时间花在一个看似无害的字符串拼接上——那个拼接在循环里执行了几万次，每次都在创建新对象。改成StringBuilder之后，响应时间直接降了百分之四十。

他还提到，优化要有优先级。先解决算法复杂度的问题，再考虑减少常数因子。一个O(n²)的循环，你把里面的操作优化得再快，数据量上来照样崩。反过来，一个O(n)的算法，里面多点几次函数调用，影响其实有限。

七、测试要写，但别为了覆盖率写

老周对测试的态度很务实。他说测试覆盖率是个参考指标，不是目标。为了凑覆盖率去写一堆断言等于没断言的测试，纯粹是浪费时间。

他的做法是：核心逻辑必须写单元测试，边界条件必须覆盖，集成测试挑关键路径写。什么叫关键路径？就是用户最常用的功能，以及出问题影响最大的功能。比如支付流程、登录流程、数据导出，这些必须测。至于一些边角的管理后台功能，如果人力有限，可以靠手工测试兜底。

他还强调测试要能快速运行。如果跑一次单元测试要五分钟，没人会愿意在开发过程中频繁运行。他的经验是单元测试整套跑完不超过三十秒，超过这个时间就要考虑拆分或者用mock减少依赖。

八、文档写在代码旁边

老周说他以前也迷信独立的文档系统，后来发现一个问题：代码改了，文档没人改，过几个月文档就成了误导。他现在的做法是，能写在代码注释里的就写在代码注释里，特别是那些"为什么这么写"的解释。

比如一个看起来奇怪的边界判断，旁边加一行注释说明是因为某个上游系统的历史遗留问题。这样后来的人看到这段代码，不会轻易"优化"掉，因为知道背后有原因。

对于跨模块的架构决策，他会写一个简短的ADR（架构决策记录），放在代码仓库里，跟代码一起版本控制。内容不用多，几百字说清楚背景、选项、决定和后果就行。这样新人入职的时候，翻一遍ADR就能理解系统为什么长成现在这样。

老周最后说了一句话，我记到现在：编程这件事，技巧是末，思路是本。技巧可以查文档，思路只能靠多想。他见过太多人收藏了几百篇"实用技巧"，真到写代码的时候还是凭直觉。直觉不是坏事，但直觉需要靠大量的思考和复盘来喂养。澳门这边地方小，但代码的世界很大，多想想为什么，比多记几个快捷键有用得多。