精通语言、函数与变量：1年实习的提效之道

　　前不久线上又炸了，这次是埋点上报的接口超时——产品非要在前端埋二十个字段，后端解析的时候变量名还写错了，我原以为只是拼写问题，结果一查日志，好家伙，函数里循环嵌套了三层，变量作用域直接乱套，编译进度条卡着的时候，隔壁工位老张突然喊了句“谁的外卖到了”，群里还发了张“代码已死”的表情包，我当时就懵了。

　　后来复盘的时候，带我的师傅说：“你这变量命名跟闹着玩似的，‘temp1’‘temp2’，谁知道它们是干啥的？”我还不服气，说“反正能跑就行”，结果他直接翻出我三个月前写的代码——那会儿我刚接手用户权限模块，为了图快，把所有中间变量都叫“a”“b”“c”，后来需求一变，加了个新字段，直接把“a”和“b”的逻辑搞混了，线上出了两次白屏，灰度发布的时候被测试骂得狗血淋头。

　　那天加班到挺晚，窗外还在下雨，旁边工位的风扇“嗡嗡”响，我突然想起刚入职的时候，产品经理拿着原型图跟我说：“这个功能很简单，就加个按钮。”结果我写了个“addButton”的函数，结果后来需求变了，按钮要动态显示，我又在函数里加了个“isShow”的变量，结果函数越写越长，最后自己都看晕了，还是师傅过来，指着屏幕说：“你这函数名起得就不对，‘addButton’听着像只加按钮，但实际要做的是控制按钮显示，不如叫‘handleButtonDisplay’，变量名也别用‘isShow’，直接用‘visible’，这样别人一看就知道是布尔值。”

　　后来我仔细翻了翻之前的代码，发现那些让我头疼的bug，十有八九都是变量名起得模糊，或者函数职责不单一导致的。比如有一次，我写了个“getUserInfo”的函数，结果里面除了查用户信息，还顺便更新了缓存，后来缓存策略变了，这个函数直接崩了，改的时候差点没把我逼疯。还有一次，我为了偷懒，把两个逻辑相似的操作合并到一个函数里，结果需求一变，两个逻辑需要分开处理，我直接把函数拆成了三个，改得那叫一个痛苦。

　　现在想想，这些坑其实都是“优胜劣汰”的结果——那些写得烂的代码，要么被自己改得面目全非，要么被同事吐槽得抬不起头，最后要么被重构，要么直接下线。反而是那些变量名清晰、函数职责单一的代码，哪怕需求变来变去，也能轻松应对。比如我之前写的“parseQueryParams”函数，变量名全用英文，函数只做一件事——解析URL参数，后来需求加了分页和排序，我只需要在函数里加两个变量，逻辑一点都没乱，测试还夸我“改得快”。

　　不过我也不是一开始就懂这些的。刚入职那会儿，我觉得“变量名起得花里胡哨”是“炫技”，函数写得“短小精悍”是“高效”，结果被现实狠狠打脸。有一次，我为了显示自己“厉害”，把一个复杂的逻辑写在一个函数里，变量名全是缩写，结果自己过两天再看，直接懵了，还得重新理逻辑。后来师傅说：“代码是写给人看的，不是写给机器看的，机器只认语法，人得认逻辑。”我还不信，结果后来接手别人的代码，发现那些变量名起得好的，函数写得清晰的，改起来就是快，那些写得乱的，改一次骂一次。

　　现在我再写代码，变量名先想清楚，函数只做一件事，哪怕多写几行，也要保证逻辑清晰。比如上周写个“exportExcel”的功能，我专门起了个“prepareExportData”的函数，变量名全用“exportData”“sheetName”这种，函数里只做数据准备，不涉及文件导出，结果产品突然说要加字段，我只需要在“prepareExportData”里加变量，逻辑一点没乱，测试还说“这次改得挺稳”。

文章配图，仅供参考

　　下一步我打算把之前写的那些“烂代码”都翻出来，重新理一遍变量名和函数逻辑，哪怕花点时间，也比线上出问题再改强。不过我也知道，这事儿急不得，毕竟“优胜劣汰”是个过程，得慢慢磨，慢慢改——就像师傅说的：“代码写得烂，不是你的错，但一直不改，就是你的问题了。”

（编辑：我爱资讯网）

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