首页 > 带老弟做项目,凉了
头像
程序员鱼皮
发布于 2021-06-25 19:01
+ 关注

带老弟做项目,凉了

总结程序员在团队开发中常犯的问题,千万注意!

大家好,我是鱼皮,还记得我的老弟小阿巴么?

之前,我曝光了这个初学前端的孩子第一次写后端代码时出现的囧事:前端老弟第一次写后端,崩了!

这篇文章发出来后,更多人认识了小阿巴,觉得他是个有趣的编程小辣鸡。但小阿巴是一个孤傲有志向的孩子,不想一直在大家面前出笑话。于是,这货不服气,又来找我,想跟着我做新项目。

正好,要开发一个新功能,就拉小阿巴一起吧。而且这次,整个大功能交给他全权负责!

没想到,小阿巴依然很快就完成了开发,兴致冲冲地提交了代码,拉着我来评审。

然而,当我看了他写的代码后,我发现,事情并不简单。

小阿巴真是太牛逼了,一些编程新手在团队开发中常犯的问题,这货一个也没避开,全都踩雷上了。

于是我决定再次曝光他,并且总结了他的问题,希望大家引以为戒。

💣 团队开发雷区

格局小了

小阿巴写的代码中,有很多 “死” 值,比如有好几个地方用到了同一个机器的 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 ,完全可以轻松地实现上述功能,没必要再去重复引入一个同类的日期处理库。

我问小阿巴,为啥要再引入新库,他的回答不出所料:俺用的熟!

大家可能觉得给项目引入重复依赖库并没有什么错对吧,但是对于团队项目来说,每个人如果都因为自己的习惯而引入重复库,可能存在很多问题:

  1. 依赖冲突:同事 A 引入 Log4j 日志库,同事 B 引入 Logback 日志库,项目可能就跑不起来了。
  2. 项目加重:每人都引入自己熟悉的库,那整个项目就会像滚雪球一样越滚越大,而且想拆分或去除某一部分,说不定雪球就碎了。

再举个夸张的例子,三位不同技术栈的前端开发一起来做项目,结果出现了三大框架出现在同一项目的三足鼎立局面:

这种项目的维护难度可想而知。

所以在团队中,架构师还是很重要的,最好事先给项目定下规矩:项目都给我用这个框架!日期处理都要用这个库!日志都要用那个库!

这就是技术选型的问题了,要综合考虑业务适应性、团队成员学习成本等。

但无论如何,谨慎给项目引入新依赖,不要一言不合就另辟蹊径!最好先仔细扫一遍项目现在的依赖,如果已经有能满足需求的,那直接用岂不美哉?实在要引入新依赖,也最好跟你的合作伙伴一起商量下,万一出了什么冲突可就不好了~

急不可耐

我看了小阿巴写的功能,惊讶地发现他根本就理解错需求了啊!

我让他拧个螺丝,这货给我造了个汽车?

// 预期
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 的学习资源~

跑了,留下 6T 的资源!

我是如何从零开始自学编程,拿到腾讯、字节等大厂 offer 的,可以看这篇文章,不再迷茫!

我学计算机的四年,共勉!

原创不易,如果觉得文章不错,希望 <stron> 支持下 ❤️</stron>

全部评论

(2) 回帖
加载中...
话题 回帖

推荐话题

相关热帖

近期热帖

近期精华帖

热门推荐