作者：durance

场景

面试官：你先自我介绍一下吧

舍友：我是云南的，云南怒江的，怒江…….

面试官：那你介绍一下你的项目吧

舍友：好的。我的项目…..这里……事务….Spring……Redis…..mp……阿巴阿巴….

面试官：其他还有做什么吗？

舍友：主要差不多这些了

面试官：那你这不都是CRUD吗？

舍友：

面试官：没有别的吗？

舍友：

前言

在我们面试或者老师评价我们的项目时，有的时候会看到面试官或者老师对自己的项目进行评价。

当然，后面舍友回去等通知了。🤣

说这项目没啥亮点，都是CRUD，应该加些亮点来提高自己项目的含金量。

很多网友表示：

“难道不是？”

“简单明了，搬砖就是搬砖”

“不管交互体验，还是更快的执行效率，都是为增删改查服务”

“crud也有好的和烂的”

“office也是增删改查，怎么他们没搞出来”

“电工的工作也很简单，不就是接一下电线吗，开一电路开关吗，但是不是了解的人敢接吗”

大家认为即便只是 CRUD 也是有一定门道的。

其实在前端也有类似的问题存在，就像前端经常也被叫做 切图仔。都是类似性质的事

那到底如何摆脱这个所谓的 “只会CRUD” 呢？

实训经历分享

因为我是软件工程专业的，所以在每个学期末会有一场实训。

简单来说，这个 “实训” 就是 自己 或者 一个小组一起敲代码做一个项目，一般由老师定一个主题。然后围绕这个方面写一个网站，或者小程序等等。

在上其中一节课时，老师就提到，项目中不要只有 增删改查，尽量加些亮点。

当时就在思考：写这种什么 xx管理系统，xx众包系统 不就是 增删改查吗，还能写什么。

我组的项目是一个 众包类型的系统，类似于一个找工作的平台。当时只是大一大二，自己的技术没有很成熟。

后面就想🧐，我在这里去实现一个简历的上传下载，是不是脱离了所谓的CRUD了呢？

于是我带着好奇心去询问老师，结果当然，这不算一个亮点。毕竟上传下载的代码也是网上找的模板。

引言

其实无论对于什么样的观点，主要是对于简单的 CRUD 这点，我们认为对个人能力方面没有太大的提升。并且又一直在做类似这样的业务。

如果长时间水平没有提升，在于程序员这种技术行业里，就容易向鄙视链下方行走。

在对于我们所在的环境，不是我们的导师或者谁能够多么好去引导我们，而是对于当前所拥有的资源，我们可以怎么去更好的利用和学习。毕竟主动和被动的差别是很大的。

这里我给学弟学妹提一些建议，关于自己如何提高相关的coding能力和coding视野

成长建议

1.技术栈

首先是技术栈这一块，不用局限于校内学习的内容。像国内很多高校对于中间件等的学习还是比较少的。

尽量在自己的项目中能够使用比较新的技术，尤其是高并发等需要的比如MQ，Spring Cloud之类的。这样能够让自己在技术选型方面不掉队。

个人项目，锻炼为主。主要目的就是去熟悉相关的技术。

在项目方面，也不用太多，精写一两个项目出来就好。不断迭代更新，更有利于自己去总结归纳。

2.功能性业务

在这点上，我们可以尽可能去实现复杂的业务。对于自己的项目，很多时候是需要自己给自己想需求的。这点也让我们自己能有更大的发挥空间。

我们以一个帖子平台为例：

一个删除用户的接口，一开始我们只能想到删除该用户数据。实际上的业务，也需要对用户所产生的数据做处理。

比如删除用户的评论，删除用户的帖子等等。（不一定是删除，可能也是换种显示之类的）

不断锻炼自己对于业务的思考，考虑业务的完整性等。

其次就是做一些更 “高级” 的业务，比如支付、生成等的业务。

可以选择沙箱测试，因为实际支付需要需要有商户号等等，或者选择些第三方。学生的资源还是比较少能接触支付的。

3.安全性业务

在功能上达到一定难度后，业务不一定是围绕功能怎么样怎么样的。也可以考虑在安全上去做处理。

比如你需要对一个接口进行防刷的实现。当然实现的方式有很多，很多熔断，降级的操作也能保护一个接口。

这类业务主要考虑对一个系统的保护，比如使用过滤器去实现一些限流，鉴权，限制的之类的。降低被攻击的可能等等。

4.优化性代码

我在前段时间实习时，我们组会定期召开一个小组会议，来对每个阶段做一次总结。总结的内容不仅仅限于绩效上的东西。

有一次总结时，会议提到了每次的需求排期不仅仅要排到需求完成的时候。应该在多预留出20% 的时间来对代码进行优化。

除去完成这些外部需求（产品来的），组内内部也会自己生产需求。内容主要就是系统优化相关的。

这一点我认为公司做的还是很不错的，能够将代码优化坚持去做，甚至是建立一个需求去做。

我认为也是我们个人值得学习的地方，我们在做个人项目时，也可以花些时间去优化代码，其实也别有一番风味。

比如尝试去思考一个接口如何进行优化：

能否降低数据库查询次数

或提高sql查询效率

能否减低RPC调用次数

能否省去些多余的逻辑判断等

5.引入设计模式

除去编写各种业务，更高一层面，去考虑将设计模式引入自己的业务，降低系统的耦合度等等。

除去个人项目，在公司开发中很多需要考虑的问题是要能够让下一个开发者可以上手。

引入一些设计模式，能够大大降低系统相关的耦合度，提高些可读性等等。

在往上，甚至是DDD之类的领域架构。当然，DDD落地的公司还是很少的。

结语

其实还是很多业务是CRUD实现的，就像网友说的，CRUD也有好的烂的。希望我们能在一次次经验中得到成长。

其实自己也是最能感受自己是否成长的人。

顺便吆喝一句，（技术大厂内推，前后端测试捞人）

希望本文能够对你有所帮助。