写点什么

带老弟做项目,凉了

发布于: 2 小时前

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


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


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


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



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


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



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


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


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

💣 团队开发雷区

格局小了

小阿巴写的代码中,有很多 “死” 值,比如有好几个地方用到了同一个机器的 IP 地址:


// 文件 1getConnectByIp("8.8.8.8");
// 文件 2getLinkByIp("8.8.8.8");
// 文件 3return { 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 的,可以看这篇文章,不再迷茫!


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


原创不易,如果觉得文章不错,希望 点赞 支持下 ❤️

用户头像

鹅厂全栈,爱做项目,分享技术 2021.02.26 加入

公众号【程序员鱼皮】领 6 T 最新编程资料和学习方法 💎 做了个网站叫【编程导航】:www.code-nav.cn ✨

评论

发布
暂无评论
带老弟做项目,凉了