带大家做了 10 多个项目，发现了一些通病

带大家做了 10 多个项目，发现了一些通病

大家好，我是程序员鱼皮。就在昨天，我又带大家做完了一个新项目 《智能协同云图库平台》，已经带大家做了十多个项目了，自然也发现了很多大家在学项目过程中的问题。

最了解学生的，莫过于老师和学生自己。而我经历了自学阶段，从学生成长为了老师，所以也很清楚怎么自学项目，效率才能更快一些。这篇文章，就分享一下我发现的大家自学项目时的通病。

注意，本篇文章中我写的所有内容，目的都是为了帮你节约时间，提高自学效率。

如果你正好有下面这些情况，请务必及时调整！

1、重复工作

任何业务类项目基本都是从项目初始化、编写增删改查开始的，在你做第一个项目的时候，自己手动编写这些代码没有任何问题，主要是熟悉自己搭建项目的方法和过程。但当你做第 2 个、第 个项目的时候，如果还在从 0 开始写基础代码（比如全局异常处理器、一些工具类），那就属于是浪费时间了，完全可以通过复用自己之前的项目代码、使用工具自动生成、或者搭建一个自己的项目模板来提高开发效率。

像我工作的时候遵循一个原则 —— 只要有重复劳动，都会尝试能否通过自动化的方式来提高效率。大家学项目时也是如此，避免在重复工作上耽误时间，不要满足于 “自己重复代码写得有多快”，而是要多把时间花在学习新的技术知识上。

2、死守教程

大家都知道，每个教程中作者都会选择特定的版本、技术和工具来教学，没有人能保证这些技术和工具不更新，所以每个教程一定有自己的 “保质期”。

像我在几年前最开始带大家做第一个项目 —— 用户中心项目时，就吃过技术更新的亏，由于前端框架的更新，导致前端部分的开发跟教程有一些不一致。所以后续我在带大家做项目时，会倾向于选择稳定的框架和版本。

当然，这是对于项目作者来说的。那对于学习项目的同学来说，可能就会产生很多问题：

• 为什么我使用的版本跟教程不一致了？
• 为什么教程中用的工具有这个按钮，但我用的工具没有这个按钮？
• 为什么我在官方文档中不到教程中写的内容了？
• 为什么我跟教程中操作一模一样，但是运行结果不同？

很多初学者会因为这些问题，纠结很久，甚至不敢接着往下做项目，其实大可不必。

任何教程都有保质期，但解决问题的方法是灵活的。

如果使用的版本或环境跟教程不一致，那么不妨安装跟教程相同的版本（比如前端可以用 VM 管理 ode.js 版本），或者查阅下如何使用新版本；如果用了比教程更新的工具，那么就在网上搜一下新版本的工具有没有教程中要执行的功能；如果官方文档跟教程中的内容不一致，那么就仔细阅读一下官方文档中最新的使用方法；如果跟教程中操作一模一样但结果不同，那么不妨自己 Debug 一下来解决问题，有可能就是教程本身有错误呢？

总之，在出现跟教程不一致的地方时，可以先记录一下问题，并且自己查阅资料和文档，不必完全死守教程。

、滥用技术

之前有个同学问我：鱼皮，我们公司想做个发券功能，现在的想法是用 Redis 分布式锁 + 消息队列 + blablabla。。。

我反问他：你们发券功能的 QPS 是多少？同时要发多少张券？

他跟我说：我们是管理员给用户发券，每批 1000 张。

我接着反问他：既然是管理员控制发券，数量也只有 1000 张，那你不妨思考一下，真的有必要用到这些技术么？

类似的情况我之前也分享过，可以看 这篇文章 。

在企业中，业务 > 技术，技术是为业务服务的，要根据业务选择合适的技术实现。

一般来说，我们在思考业务实现方案时，能少用一个技术就少用一个技术，减少开发和维护成本。

但我发现有些同学可能是学的技术多了、也可能是八股文背多了，在做项目功能时，反而是先搬出一大堆的技术，完全不去考虑有没有必要用这些技术，有点儿 “为了学习而学习” 了。其实从学习的角度来说，多用点技术倒也没什么问题，但是如果你把这些写到简历上，面试官就会问你：“为什么要用这个技术？不用它行不行？”，这时你又该如何回答呢？

所以大家即使是自学项目，也建议到合适的业务场景，合理运用技术。就像我昨天刚给大家讲完 DDD 领域驱动设计，有些同学就表示 “以后就用 DDD 架构来做项目了”，但其实大家自己做的项目，90% 以上是没必要用 DDD 的。

DDD 的目录结构

当然，多学新技术肯定是好的，相当于填充了我们的弹药库；但使用弹药时，肯定优先选择成本低的、最合适的。

4、不够灵活

我在讲 DDD 领域驱动设计时，先问了大家一个问题：如果必须要 2 选 1，你觉得开发项目时理论和实践哪个更重要？

结果大家一致选择了 “实践”。

没错，理论再完美，不能落地也无法创造价值；理论再丰富，也不一定能满足所有的实践需要。做项目时，理论的指导固然重要，但一定要结合实际情况按需运用和调整。

举个例子，大家学数据库理论的时候，老师可能会讲 “我们可以通过外键来保证数据完整性，要遵循第三范式，要遵循 ACID 原则”。但实际开发中，我们可能会用逻辑外键（不添加外键约束）的方式来实现表之间的关联，可能会违反数据一致性，但是能提高写入性能。

我在带大家做项目的过程中，发现很多同学就会特别执着于 “理论和规范”，比如：

• 你的目录命名怎么是 utils 而不是 util？为什么数据库对象用 Entity 而不是 PO？
• 为什么你的数据库字段用驼峰而不是下划线？
• 为什么你只创建一个对象，却不使用单例模式？
• 为什么你的接口不遵循 Restful 的规范，删除资源时还是使用 Post 请求？

这些都是我经常收到的问题，但其实都是无足轻重的问题。大家不要把时间浪费在纠结理论或规范上，毕竟这些都是人定的，在不违背原则或产生 Bug 的情况下，我们保证团队内部、或者自己开发时的规范保持一致即可。养成统一的编码风格和开发习惯，也能帮我们提高开发效率，没必要完全和教程保持一致。

除了上面几点外，我们也要时刻把握自己的学习重点，比如后端方向的同学，就尽量不要花时间在调试前端的样式上。像我大学的时候就是学的有点太杂了，有一段时间沉迷于抠前端的像素无法自拔，现在回过头来想想，确实浪费了太多时间。