菜鸡女程序员干开发三年的分享

做过app、小程序、saas。

目录

·首先，我自认为自己是一个菜鸡

·其次，能干活不等于你是一个合格的程序员（这个合格标准是我自己定义，因人而异）

举个例子：

再举个例子：

·再次，不要小看索引

·从次，避免for循环套for循环，for循环套查询

·最后，对接第三方这种不要害怕

·另外，多百度

---

正文开始

·首先，我自认为自己是一个菜鸡

一：面试里问到的redis缓存穿透，击穿，雪崩我在两年的职业生涯中并没有遇到。因此我觉得我缺少了一些解决这类问题的实践能力。

二：高并发。没有遇到，大多数中小企业是不会遇到高并发问题的，首先客户量就不是很大。我缺乏相关经验及解决方案。

三：多线程。终于理解为什么高级程序员面试才会问多线程的问题了，因为基本用不到。我缺少与高并发相关的时间问题累积及解决经验。

综上，我觉得我干了两年了还是个初级开发，我没有抱怨，我不是一个上进的人，我挺安于现状。

·其次，能干活不等于你是一个合格的程序员（这个合格标准是我自己定义，因人而异）

当你实现了一个产品需要的功能时，对你来说即便逻辑是一些简单的CRUD，纵使这些你天天写，但当测试介入时，你依然不能稳稳通过，因为业务并没有你所理解的表面意义那么简单。是的，我干了两年了，有些业务需求也不是一下子就能get到的，这就是沟通的重要性。特别是已有项目做更新优化迭代的时候。

举个技术方面例子：

h5页面的链接，产品可能告诉你链接尽量设置简单一点，想我这种没啥经验的，直接给前端返的：https//zheshiyigeyuming/detail?id=1,有经验的可能都要笑话我了，作为开发你要考虑到这个数据的保密性，我这样子直接在h5展示，人家随便改个值，信息岂不是一览无余。正常情况下这个参数内容是需要加密的。合格的程序员是需要考虑到这种基础的问题的。这也印证了我很菜的事实。

再举个技术方面例子：

一个实现类里面，多个接口都用到了根据id查询一条记录的查询方法，在我得知mybatis-plus的lambdaQuery()这种查询方法时，我在每个需要根据id查询一条记录的方法里面都写了一遍super.lambdaQuery()，因为我当时觉得已经够简便了。现在的我对于这个行为的反应是：emmmm，这很难评。合格的程序员会把他抽出来的，只用写一遍就！行！啦！

举个需求方面例子：

产品告诉你这个编辑页面所有内容都可以编辑的时候，你不仅要考虑页面交互逻辑，更要考虑关联表数据存储逻辑。很多细小的东西，产品只是告诉了你他要什么，具体很多细节你在实现的时候，没有考虑那么多，只是按照产品的需求按部就班的做，到测试阶段，一些不合理性才会暴露出来，导致你需要对自己的代码更新优化，甚至于重写。我初期十分的痛苦，只是机械性的把功能做出来后，还需要花大量时间优化修复bug。我觉得合格的程序员，在梳理逻辑的时候，就能考虑到一些潜在问题，避免后续bug不断，

·再次，不要小看索引

数据库索引，我本来觉得我用不到这玩意儿，就像多线程那种（可能有点夸张了）离我很遥远的东西，但是你的业务中，总有那么几张表的数据是非常庞大的，类似于支付记录，支付操作记录，流水记录，这时候你会发现与这几张表相关的接口响应不是瞬间的，总要转那么几圈才有结果。因为小体量数据接口请求都是毫秒级别的，个别几秒钟的请求就会非常突兀，测试肯定就会需要你优化。这就得上索引了，嘎嘎好使。

·从次，避免for循环套for循环，for循环套查询

虽然你做的项目，用户量不大，数据量不大，但是，咱不能堆shi山给后面接我手的人啊。这里说的是避免，不是绝对，哈哈哈哈哈程序员的严谨（狗头）。

不知道还有没有人不知道用map可以避免循环套循环。把一个list转map，另一个list循环，根据公共字段map.get即可。在一个同事那里学到的，当初瞧不上map，从次爱上它。

·最后，对接第三方这种不要害怕

这东西是举一反三的，我有幸对接过e签宝，请求参数按页来，当我拿下它的时候，我觉得再复杂的三方也不在话下了。总归是配置，封装，发送请求，接收，验签，处理，响应。

支付更别说了，接过一个就都会了，涉及到金钱方面的仔细仔细再仔细就行了。

·另外，多百度

有问题不要自己闷头苦想，可以多搜索，只要不是疑难杂症都能搜到解答。不要一有问题就麻烦别人去找别人问，很多问题你自己搜索都能搜得到解决方案，往往很多问题你问出嘴就要后悔了，在你当时看来这个问题可能是你遇到最难的，但是你回过头来看，那只是个百度就能解决的小插曲。（除了刚到公司，初生牛犊不怕虎，但时间久了，还是什么都问的话，你的技术水平会被质疑的）。但是我是女孩子，感觉我公司同事对女程序员还挺包容，我有啥逻辑顺不通或者测试跟我争执的时候，同事还会来帮帮我。感恩。