在业主群聊了一宿，才悟出软件开发基本功到底多重要

发布时间：2026-08-05 10:58:03 丨 浏览次数：4

群里老赵前天甩了张截图，说新人写的代码，变量名是 a1、b2，函数叫 doIt，他看了二十分钟没弄明白要干嘛。我们几个人你一言我一语，越聊越觉得——好多项目翻车，还真就是软件开发基本功被大家当成了“太基础，没必要专门练”的东西。

麻烦先从起名和拆函数开始避免

写代码给队友看，比给机器看还重要。函数命名我给个土办法：起完名自己读一遍，看能不能立马说出它干啥。比如算月收入的函数，叫 calcRev()，谁知道是求“收入”还是“革命”？老老实实写成 calculateMonthlyRevenue()，虽然长点，但省了别人猜谜的时间。变量前面加个 is、get、handle 这类前缀，一眼就知道是判断还是操作，比注释还好使。

一个函数塞几十行，嵌套三四层 if，不说别人，自己下周回来看都晕。咱组里的默契是，单个函数尽量别超过一屏，条件嵌套一多就拆出去。比如权限校验那个流程，拆成 validateUserExistence()、checkPermission() 几个小块，每个只做一件事。拆太碎了确实调用链会变长，调试要多跳几层，可总比一大坨谁也改不动强。折中办法：以“能一句话说清这个函数在干啥”为界，别拆到只有一两行还来回传参。

架构不留后路，后面业务一变就傻眼

做模块拆分，订单、支付、物流各管各的，别共着一张表。当初我们吃过亏，一个促销字段改了，整条链路全得跟着动，发版跟排雷似的。接口设计也是，别一上来就把参数写死。像优惠信息那段，用 Map 存 {discount:[{coupon:true},{promotion:false}]}，后面运营想加个拼团标签，接口不用改，代码加个处理就好。这多写几行判断，初期看着啰嗦，可换来后面不被业务催命，值了。

异常处理得分个三六九等。连接超时、库存不足、密码输错，混在一起前端都不知道该给用户弹什么框。我们把业务异常拎出来，给个统一错误码和中文提示，测试说好歹能看懂报错了。

性能优化别靠猜，我们交过的学费

以前总有人拍脑袋就说“加个缓存就好了”，结果慢查询还是慢。后来学乖了，先看慢日志，发现商品搜索那段在 list 里疯狂循环，每次调用 indexOf 扫一遍。换成 HashMap 后，页面上那个转圈直接没了，肉眼看就是秒出。数据库连着查循环更是大忌，能用 WHERE IN 一把捞出来就别一次次跑。关联表超过三张，就别硬扛了，丢给 OLAP 或者先存一份宽表，这也是一个折中的坑，实时性差点，但业务能接受。

部署上，静态资源扔 Nginx 缓存，接口少传不少流量。关键节点设个熔断，流量冲过来不至于整个系统跟着陪葬。这些都不是啥高端技巧，全是一回回熬夜排障磨出来的习惯。

代码评审别走形式，我们就盯三样：是不是把报错悄悄吞了，空指针一 catch 啥也不干；是不是为了用设计模式，三个类能搞定的事搞出十五个文件；新人命名、缩进符不符合规矩——这些靠 CI 流水线就能拦住大半。每周扯个历史事故出来复盘，重点不是追责，是琢磨“当初为啥没发现，以后用啥手段能早点儿拦住”。

基本功这东西，你肯花时间慢慢磨，后面维护自然少遭罪。咱们组这周就从重命名几个函数、补两条慢日志告警开始，试试看。