刚学编程那会儿，脑子里只想着怎么让代码跑起来。只要能输出结果，管它过程多乱。后来项目大了，改一行代码能崩三天，才明白光会语法远远不够。
别急着敲键盘，先想清楚要做什么
有次接了个需求，用户要上传文件后自动生成缩略图。我二话不说就开始查图片处理库，写完才发现漏了“大文件要分片上传”这一条。返工重做，时间全浪费在无效劳动上。
现在接到任务，第一反应不是打开编辑器，而是拿张纸画流程。这个功能涉及哪些环节？用户可能怎么操作？异常情况有哪些？把这些理顺了，再动手写，效率反而更高。
函数不是越短越好，而是越“专一”越好
以前觉得函数短就是好代码，恨不得把所有逻辑揉进一个 return 里。结果半年后自己回头看，完全不知道当初写的三元表达式在判断啥。
现在更愿意把一个复杂判断拆成多个小函数：
function isValidUser(user) {
return user && isAdult(user.age) && hasVerifiedEmail(user);
}
function isAdult(age) {
return age >= 18;
}
function hasVerifiedEmail(user) {
return user.email && user.isEmailVerified;
}每个函数只干一件事，名字直接说明意图。别人看代码时，不用猜这个条件到底在判断什么。
别怕改结构，坏的设计比没设计更危险
有个项目一开始用全局变量存用户状态，开发快是快，可一旦页面跳转或刷新，数据就丢了。后来换成本地存储+内存缓存的组合方式，虽然多写了几十行，但用户体验稳定多了。
很多人说“能用就行”，但在软件里，“能用”和“好用”之间差的是可维护性。今天省下的时间，明天可能要用十倍去还。
学会用“抽象”偷懒
做过三个类似的后台管理页，每个都有列表、搜索、分页。第一次全手写，第二次复制粘贴改字段，第三次干脆抽了个通用表格组件。
抽象不是为了显得高深，是为了少写重复代码。当你发现“这玩意儿好像在哪写过”，就该停下来想想能不能提炼一下。
比如处理 API 返回，统一加个拦截器处理错误提示和 loading 状态，比每个接口里手动写 try-catch 强多了。
调试时别光盯着变量值
有次接口老报错，打印了一堆 log 发现参数没错。最后才发现是调用顺序错了——还没登录就去请求用户信息。这时候光看数据没用，得理清执行流程。
现在遇到奇怪问题，第一反应是画个调用链，或者用浏览器的调用栈看看函数是怎么一层层进去的。有时候问题不在代码本身，而在你没想到的执行路径。
编程到最后，拼的不是谁记得函数多，而是谁更能想清楚问题。写代码像做饭，调料再多，火候不对也白搭。多花点时间琢磨“为什么这么写”，比背一百个语法糖实在。