昨晚又熬到了凌晨两点,盯着报错信息发呆。
想起刚做开发那会儿,觉得自己啥都能搞,前端后端数据库,样样精通。现在回头看,那时候的我就像个拿着玩具锤子的小孩,看什么都像钉子。
这篇文章记录了我这几年踩过的10个坑,有些现在想起来还会脸红。如果你也在做全栈,或许能帮你少走点弯路。
那时候每天刷技术博客,看到新框架就兴奋得不行。
React刚熟悉一点,Vue3出来了赶紧去学。还没搞明白Vue,又听说Svelte性能更好。结果就是每样都懂一点,但真正用起来哪样都不够深入。
记得有次面试,面试官问React的虚拟DOM原理,我支支吾吾半天说不清楚。明明用了两年React,但只停留在会用API的层面。
现在的想法: 与其东一榔头西一棒子,不如选定一个主技术栈深耕。把底层原理搞透了,学其他的反而更快。
// 以前的学习方式:广而不深
const skills = {
react: "会用useState和useEffect",
vue: "看过文档,写过todo",
angular: "跟着教程写过demo",
svelte: "听说性能很好..."
};
// 现在的学习方式:深耕一个
const skills = {
react: {
hooks: "深入理解实现原理",
fiber: "知道调和过程",
ssr: "能独立搭建Next.js项目",
testing: "会写完整的测试用例"
}
};
刚开始做前端的时候,总觉得后端是高深莫测的东西。数据库、服务器、API设计,感觉都是大牛才能搞的。
有次项目需要对接后端API,接口文档写得不清不楚,我也不好意思去问后端同事具体逻辑。结果前端代码写得乱七八糟,各种if-else判断,最后维护起来特别痛苦。
真正开始学后端后才发现,很多概念其实没那么复杂。HTTP就是请求和响应,数据库就是存数据的地方,认证就是验证用户身份。
转变: 开始自己搭建简单的Node.js服务,用Express写API,慢慢理解了前后端数据流转的过程。现在和后端同事沟通效率高了很多。
刚工作那会儿,总觉得自己的代码是艺术品,不愿意让别人看到"不完美"的代码。
直接往main分支推代码,从不提PR。觉得code review就是在找茬,浪费时间。结果写出来的代码只有自己能看懂,过了一个月连自己都看不懂了。
有次线上出了bug,我花了两天才定位到问题。如果当时有人review我的代码,这个低级错误根本不会发生。
改变: 现在每个功能都会开分支,写完后主动找同事review。虽然有时候会被指出问题有点尴尬,但确实帮我避免了很多坑。
// 以前的提交信息
git commit -m "fix bug"
git commit -m "update"
git commit -m "change stuff"
// 现在的提交信息
git commit -m "fix: resolve user authentication timeout issue"
git commit -m "feat: add pagination component with loading state"
git commit -m "refactor: extract common validation logic to utils"
刚学会一点设计模式,就想在项目里都用上。一个简单的状态管理,非要搞个复杂的架构。
最夸张的是,我曾经为了一个显示用户头像的功能,写了200多行代码,包括什么单例模式、工厂模式。同事看了直接说:"这不就是一个img标签的事儿吗?"
醒悟: 简单的问题用简单的方法解决。复杂的架构是为了解决复杂的问题,不是为了显示自己很厉害。
以前写代码,都是在浏览器里手动点点测试,觉得自动化测试太麻烦。
直到有次改了一个组件,结果影响了十几个地方,花了一整天才找到所有问题。那时候才意识到,如果有测试用例,5分钟就能发现问题。
开始写测试后发现,测试不仅能发现bug,还能帮我理清代码逻辑,写出更好的代码结构。
// 现在写组件都会配套写测试
describe('LoginForm', () => {
test('显示用户输入的用户名', () => {
render(<LoginForm />);
const input = screen.getByLabelText('用户名');
fireEvent.change(input, { target: { value: 'testuser' } });
expect(input.value).toBe('testuser');
});
test('提交时调用登录接口', () => {
const mockLogin = jest.fn();
render(<LoginForm onLogin={mockLogin} />);
// ... 测试逻辑
});
});
遇到问题第一反应就是去Stack Overflow搜,找到答案直接复制粘贴。
有次从网上复制了一段代码处理日期格式,当时能用,但过了几个月发现在某些时区下会出错。因为我根本没理解代码的逻辑,只是碰运气。
现在的习惯: 看到解决方案后,先理解原理,然后根据自己的需求改写。即使多花点时间,但避免了后续的麻烦。
以前觉得写完代码扔给运维就行了,部署、监控这些和开发没关系。
直到有次凌晨收到报警电话,线上服务挂了,我对生产环境一无所知,只能干着急。运维同事帮忙排查,发现是我写的一个死循环导致内存泄漏。
改变: 开始学Docker,了解CI/CD流程,至少能看懂日志,知道自己的代码在生产环境是怎么运行的。
刚开始写代码,总觉得写得越多越厉害。一个功能能写100行,绝不写50行。
后来维护老代码时痛苦不堪,才理解了"最好的代码是不用写的代码"这句话的含义。
转变: 现在写代码前会先看看有没有现成的库,能复用的就复用,能简化的就简化。
作为开发者,总觉得功能实现了就行,UI丑点没关系。
结果做出来的东西,用户体验极差,按钮位置奇怪,颜色搭配刺眼,交互逻辑反人类。产品经理和设计师天天找我调整界面。
改变: 开始关注设计原理,学会使用设计系统,至少保证做出来的东西不会让人看了想关网页。
刚毕业那会儿,觉得程序员就应该996,周末不写代码就是不上进。
连续几个月高强度工作后,开始对代码产生厌恶,看到IDE就头疼。那段时间写出的代码质量也很差,bug一堆。
醒悟: 写代码是脑力活,需要持续的创造力和专注力。适当休息不是偷懒,是为了更好地工作。
这些坑,大部分人都会踩。踩坑不可怕,可怕的是踩了坑还不知道反思。
现在回头看,每个坑其实都是成长的机会。虽然当时很痛苦,但确实让我对开发这件事有了更深的理解。
如果你也是全栈开发者,或许正在经历类似的困惑,希望这些经历对你有所帮助。大家都是一路摸爬滚打过来的,互相理解,共同进步。
你踩过哪些坑?欢迎在评论区聊聊,说不定能帮到其他正在爬坑的同学。
我是一个还在学习路上的全栈开发者,会持续分享一些实际的开发经验和踩坑记录。如果对你有帮助,欢迎关注交流。