总结程序员在团队开发中常犯的问题，千万注意！
大家好，我是鱼皮，还记得我的老弟小阿巴么？
之前，我曝光了这个初学前端的孩子第一次写后端代码时出现的囧事：前端老弟第一次写后端，崩了！
这篇文章发出来后，更多人认识了小阿巴，觉得他是个有趣的编程小辣鸡。但小阿巴是一个孤傲有志向的孩子，不想一直在大家面前出笑话。于是，这货不服气，又来找我，想跟着我做新项目。
正好，要开发一个新功能，就拉小阿巴一起吧。而且这次，整个大功能交给他全权负责！
没想到，小阿巴依然很快就完成了开发，兴致冲冲地提交了代码，拉着我来评审。
然而，当我看了他写的代码后，我发现，事情并不简单。
小阿巴真是太牛逼了，一些编程新手在团队开发中常犯的问题，这货一个也没避开，全都踩雷上了。
于是我决定再次曝光他，并且总结了他的问题，希望大家引以为戒。
团队开发雷区
格局小了
小阿巴写的代码中，有很多 “死” 值，比如有好几个地方用到了同一个机器的 IP 地址：
// 文件 1
getConnectByIp("8.8.8.8");
// 文件 2
getLinkByIp("8.8.8.8");
// 文件 3
return {
ip: "8.8.8.8"
}
我问他为啥这么写，他的回答不出所料：就是图省事儿~
这就跟我们复制粘贴一样，把重复的代码粘贴很多遍，写的时候是挺爽，但万一后面要修改了呢？要一个个地把所有粘贴的代码都改掉？
如果都是一个人写代码还好，自己可能还记得有哪些重复的代码，但如果是一个团队呢？
假如同事 A 写了一段代码，同事 B 和同事 C 都复制了他的代码：
但后来同事 A 发现自己的代码有 Bug！于是就只修改了代码 A，然而代码 B 和代码 C 依旧存在 Bug。
毕竟大家都喜欢复制代码的，尤其是在大团队中，你根本不知道自己的代码究竟被多少人复制了！一个 Bug 永流传啊。
所以无论是从可扩展性还是可维护性的角度，尽量少写 “死” 代码、少写重复的代码，可以将重复的值抽离成独立的变量、常量或配置文件，将重复的代码封装成组件，并编写文档和注释指引他人使用。一般代码重复 3 次，就可以考虑抽象了，别偷懒，要不然以后更惨。
过于自我
小阿巴在实现 “计算指定日期和当前日期相差的天数” 功能时，新引入了一个依赖库叫 Day.js 。
但事实上，项目已有日期处理库 Moment.js ，完全可以轻松地实现上述功能，没必要再去重复引入一个同类的日期处理库。
我问小阿巴，为啥要再引入新库，他的回答不出所料：俺用的熟！
大家可能觉得给项目引入重复依赖库并没有什么错对吧，但是对于团队项目来说，每个人如果都因为自己的习惯而引入重复库，可能存在很多问题：
- 依赖冲突：同事 A 引入 Log4j 日志库，同事 B 引入 Logback 日志库，项目可能就跑不起来了。
- 项目加重：每人都引入自己熟悉的库，那整个项目就会像滚雪球一样越滚越大，而且想拆分或去除某一部分，说不定雪球就碎了。
再举个夸张的例子，三位不同技术栈的前端开发一起来做项目，结果出现了三大框架出现在同一项目的三足鼎立局面：
这种项目的维护难度可想而知。
所以在团队中，架构师还是很重要的，最好事先给项目定下规矩：项目都给我用这个框架！日期处理都要用这个库！日志都要用那个库！
这就是技术选型的问题了，要综合考虑业务适应性、团队成员学习成本等。
但无论如何，谨慎给项目引入新依赖，不要一言不合就另辟蹊径！最好先仔细扫一遍项目现在的依赖，如果已经有能满足需求的，那直接用岂不美哉？实在要引入新依赖，也最好跟你的合作伙伴一起商量下，万一出了什么冲突可就不好了~
急不可耐
我看了小阿巴写的功能，惊讶地发现他根本就理解错需求了啊！
我让他拧个螺丝，这货给我造了个汽车？
// 预期
luoSi = ningLuosi();
// 小阿巴
car = buildCar();
连做什么都没搞清楚，就迫不及待直接上手写代码了，这可是大忌，典型的出力不讨好。
在企业中，我们作为开发，经常会和产品经理友好交流，要把需求彻底理解了，才能去设计方案，方案设计好才能去写代码，在整个过程中一定要和需求方反反复复确认清楚！
我打算再给小阿巴一个机会，这次过了好几天他才提交了代码，我一看，这货真的是拧好螺丝了，只不过。。。
项目里已经有扳手给他拧螺丝，结果这货自己造了个扳手？
function ningLuosi() {
// 预期：一行代码解决
useBanShou();
// 小阿巴，省略 1000 行代码
const tool = buildBanShou();
xxxxxxx
}
这也是新手常犯的问题，不看项目文档就上手写代码，结果有现成的轮子、简单的写法不用，非要自己再去造轮子，费事费力。
盲目自信
我感觉小阿巴有一行代码写的有问题，于是就本地运行了一下，果然发现了一个 Bug，页面直接崩溃了！
我把小阿巴叫过来问：你写完代码测试了不？你觉得功能有问题不？
他一脸自信地回答：没测，这功能不就是增删改查，能有啥问题？
于是我给他演示了一遍 Bug，他瞬间羞红了脸，哑口无言。
大家想象中好像经验丰富的程序员写代码更快，但事实上，经验越丰富，他们越会小心谨慎，在写完代码后认认真真地测试，而不是盲目相信经验和直觉。测试也千万不要只是草草地自己点一遍没问题就算了，而是要尽量覆盖所有正常，尤其是 异常 的情况。毕竟用户不听话，你无法想象这些家伙能在你的系统中干出什么事！
制造屎山
小阿巴的代码非常干净清爽，一个文件千行代码，一样注释都没有，我把他叫过来给我讲讲自己的代码，他竟然都支支吾吾说不出来！
一行注释没有也就罢了，代码还写的歪歪扭扭，不遵循代码规范，如果人人都是小阿巴，巨型屎山指日可待。
public static void main( String[] args) {
System.out
.println("i"
+ "am"
+ "shuai");
}
过眼云烟
通读一遍小阿巴的代码，除了上面的问题外，我还发现了很多小的错误。
于是我问他：你写完代码后，自己会再通读几遍呢？
结果这货竟然害羞极了，支支吾吾地说：没。。。没读过。。。
天啊！还有多少朋友和小阿巴一样，自己的代码犹如过眼云烟，写完就再也不看了呢？
自己写过的代码一定要多读几遍，就和考试做卷子一样的，检查一遍能发现很多问题。而且自学编程的时候，又没人逼你交卷对吧，还是要花些时间养成好习惯。
我现在写完代码至少会读三遍：写完一个子功能读一遍、测试前读一遍、提交前读一遍。即便如此，仍然出现过 Bug。
再说了，你自己写过的代码自己都不愿意看，还要别人审查的时候来看你的烂代码，发现问题再给你打回去修改，这不是浪费别人的时间么？久而久之，谁愿意看你的代码？谁愿意和你合作呢？
此外，即使有别人帮你审查代码，但有些问题也很难发现，线上出了问题肯定还是你背大锅。没有人可以拯救你的 Bug，除了你自己。
敷衍了事
最后这点，就是我之前专门写文章提到的大部分同学写代码的现状：仅仅满足于代码可运行、功能可用，而不注重细节、不做优化。
比如小阿巴的这段代码：
for(int i = 0; i < maxNum; i++) {
doSomething1();
}
for(int i = 0; i < maxNum; i++) {
doSomething2();
}
实际上是可以将两个同样的循环进行合并的：
for(int i = 0; i < maxNum; i++) {
doSomething1();
doSomething2();
}
很多同学一直抱怨自己整天增删改查，项目没竞争力。但实际上，你在做每个项目的过程中，都有很多进步空间。要仔细挖掘，而不是敷衍了事。
关于这点，大家可以看看我的编程习惯：我写代码时的小倔强 。
怎么样，这些雷你是否也踩过呢？团队开发可千万不能像自己写代码那样随意，希望大家把这些问题熟记于心，做一名优秀的程序员、可靠的队友。
那么问题来了，后面还要不要带小阿巴做项目呢？
最后再送大家 帮助我拿到大厂 offer 的学习资源~
我是如何从零开始自学编程，拿到腾讯、字节等大厂 offer 的，可以看这篇文章，不再迷茫！
原创不易，如果觉得文章不错，希望 点赞 支持下 ❤️