写出别人一眼就懂的代码：逻辑清晰，规范至上

　　凌晨一点半，甲方产品经理在群里甩了十八张截图，配文“就改一点点”。我原以为又是那种“按钮颜色深点”“间距小两像素”的破事儿，结果点开第一张——好家伙，直接要把整个用户流程推翻重做。微信消息提示音还在响，我盯着屏幕看了三秒，反手把电脑合上，摸出烟点上——这活儿要是接了，尾款估计得拖到明年清明。

　　上周刚交完一个商城项目，甲方验收时说“整体不错，但购物车逻辑有点绕”。我翻出代码，发现当初为了兼容旧版支付接口，把结算流程绕成了麻花。结果二开时，新来的后端盯着代码看了半天，发消息问我：“这‘if(flag === 1)’和‘if(flag !== 0)’是不是重复了？”我回他：“你仔细看注释——前者是‘旧版兼容’，后者是‘新版优化’。”他回了个“6”，转头把逻辑重构了，现在代码里连“flag”这个变量名都没了，全改成“isOldPayment”和“useNewFlow”。我原以为他会骂我“写得太烂”，结果他说：“至少注释清楚，改起来不抓瞎。”

　　说到注释，上个月接了个管理后台，甲方要求“功能要全，但界面要简单”。我按这个思路写了三百多行代码，变量名全用“user_”“order_”“data_”开头，函数名直接写“handleSubmit”“fetchData”“renderList”。结果交付时，甲方技术负责人看了十分钟，说：“你这代码写得挺‘直白’啊，连‘getUserInfo’都拆成了‘getUserBasic’和‘getUserDetail’。”我点头：“这样改起来方便，比如以后要加‘getUserPermission’，直接插中间就行。”他笑了：“我见过太多人为了‘简洁’把逻辑塞进一个函数，结果改的时候连自己都看不懂。”

文章配图，仅供参考

　　其实我最怕的不是改需求，是那种“逻辑混乱+没有规范”的代码。去年帮朋友救火，接了个烂尾项目，打开代码库一看——变量名有中文的、拼音的、英文的混着用，函数名有“doSomething”“handle_event”“f123”的，注释全是“// 这里改了”“// 暂时这样”。我花了三天时间理逻辑，发现同一个功能在不同页面用了三种不同的实现方式，有的用jQuery，有的用Vue，还有的直接写原生JS。最离谱的是，有个“计算总价”的函数，里面嵌了五层if-else，条件判断写得跟绕口令似的。我试着改了一处，结果其他页面全报错——原来那些“暂时这样”的注释，都是前人踩过的坑。

　　后来我定了规矩：所有项目必须按规范写——变量名用驼峰式，函数名用动词开头，注释写清楚“为什么这么做”而不是“做了什么”，逻辑分层用“MVC”或“MVVM”，复杂功能拆成小函数，每个函数不超过五十行。刚开始团队有人抱怨：“这样写太麻烦，效率低。”我回：“现在麻烦点，以后改起来省时间。你看那个烂尾项目，前人省了写注释的时间，后人花了十倍时间填坑。”他们没再说话，现在交来的代码，连测试都说“看得懂，改得动”。

　　其实甲方要的“就改一点点”，背后是“别让我看不懂”。他们不懂技术，但懂“麻烦”——如果代码逻辑清晰、规范统一，改起来就不会牵一发而动全身；如果代码乱成一团，改一处可能崩十处，到时候验收拖、返工多、尾款扣，大家都难受。我见过太多项目，前期为了“快”乱写代码，后期为了“稳”重构代码，结果工期翻倍、成本超支、关系闹僵。说到底，代码是给人看的，不是给机器跑的——机器只认语法，人得认逻辑。

　　现在我再接项目，第一件事就是定规范：变量名怎么取、函数名怎么写、注释怎么写、逻辑怎么分层、文件怎么组织。甲方要是不配合，我就说：“规范是为了你们好——现在多花点时间，以后少花十倍时间改。”他们要是还坚持“就改一点点”，我就把那个烂尾项目的代码截图发过去：“你们想变成这样吗？”通常这时候，他们就会乖乖去写文档了。

　　对了，刚才甲方产品经理发来修改文档了，我扫了一眼——需求点标得清楚，优先级标得明确，影响范围标得详细。我回他：“可以改，但得加三天工期。”他秒回：“行，尾款今天就打。”我点开转账截图，金额比预期多了两千——估计是看规范写得好，省了他们不少事。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!