哪个蠢蛋写的烂代码?

举报
G-washington 发表于 2020/02/14 20:51:33 2020/02/14
【摘要】 最近看到一个问题,叫做「你们会因为代码烂,而入职两三天选择离职吗?」其实早先有过一些关于代码质量的讨论,比如「关于烂代码的那些事」,「程序员的日常:哪个蠢蛋写的烂代码?」,「你的代码写的很烂」。这让很多程序员感受到共鸣,大家纷纷出来吐槽。

最近看到一个问题,叫做「你们会因为代码烂,而入职两三天选择离职吗?」。

其实早先有过一些关于代码质量的讨论,比如「关于烂代码的那些事」,「程序员的日常:哪个蠢蛋写的烂代码?」,「你的代码写的很烂」。这让很多程序员感受到共鸣,大家纷纷出来吐槽。

大家都在抱怨同事的代码写的烂,前同事遗留下来的代码bug多...... 那问题来了,写这些烂代码的人都去哪了? 好奇怪哎!

遗憾的是,你既可能是那个吐槽别人给你留下了麻烦,也可能是别人嘴里那个制造麻烦的人。

非常有幸,我在维护一些历史超过10年,历经无数代优秀工程师开发迭代的项目。作为一个工作超过6年的「老人」,我有话说。

笔者总结,其实最难的不是自己写代码,而是维护别人写的代码,在复杂的逻辑中找到某一个隐藏得很深的bug,或者在某个(些)位置添加一些代码以实现新的功能。你需要按照最初实现者的思路去理解,这往往是最难的,这个过程中非常让人容易产生挫败感和不良情绪。

如果原作者仍然在职还好,有问题直接去问,但假如他已经离职,你很可能偶然会遇到下面的问题:

1. 原作者设计得太复杂, 一点小的改进都要大费周章,完全掌控他的代码需要不少时间。

2. 代码性能不好。之前因为用户量和访问量太少而相安无事,现在问题突然爆发了,拖慢了整个应用甚至影响到基础设施。

3. 想要修改功能时却发现程序里充斥着各种无法理解的逻辑,改完之后莫名其妙的bug一个接一个。

在程序员这个职业里面,英雄主义实在太普遍了。有无数的理由说服领导、PM和自己,要重新造个轮子,因为大家都认为自己天下无敌了,但是又不好承认看不懂别人的代码。如果你的个人影响力和表达能力有限,没有足够的理由说服其他人选择这个轮子,又不愿意花时间推动和完善,那么最后的结果是,你认为这么美好的东西,真的只是你这么认为。等你不再维护了,离职了,下一个人又会循环这个过程... 等几年之后,项目是越来越大,但是里面大量的代码都是dead code,也就是无作用的代码。而且新人还不敢动,尤其是里面有一些magic number,复杂算法片段。

我对命名这件事做的极为不好,大部分的命名除了惯例,就是从各种开源项目里面学到的用法和套路,所以我建议所有入行的人尽最大的能力学好英语。我之前见过一个英语极好而且非常喜欢阅读英文原著的工程师,但是他写代码很「飘逸」,怎么说呢, 就是他会直接用英文原著的一些词语作为变量名字,逼格极高,但是我经常得谷歌翻译了,因为看变量名完全不懂这是啥啊。有时候还得问他,他总是拽拽的说,这个是因为XXX典故......,恍然大悟。

看代码就可以看到作者的性格和风格,比如有的人喜欢用设计模式,有的人喜欢把新学到的编程技巧强行放到项目里。高级特性齐飞,一眼瞅去:高端。但是对于真的高手来说,其实露怯了,因为用的人根本没懂正确和合理的使用场景呢。 一个真实的故事,在一次代码评审中,我们质疑了一下「为什么在这里要使用装饰器?」,结果对方的回应是:「因为这样显得逼格高...」,我当时心中千万只羊驼呼啸而过,想象下我的心理阴影。

但是不是所有前人写的都比自己差呢?其实不尽然,甚至于是可能会让你不愿意接受的事实。我以前也很唾弃别人的代码。当我看到一段不符合自己价值观的代码,理所当然认为这毋庸置疑的写的烂,于是我删掉了那段代码,用自己认为更好的方法重新写了一遍,心情极好,觉得我挽救了这个项目。当我对这部分业务逻辑熟悉了之后,回头再看,发现我所删掉的那段代码其实用的处理的方式是最恰当的,而我重写的虽然语法用的很好,但可扩展性很差。

其实有时候我们不理解的,不是人家用的差,而是我们的格调低。我开始收起我的傲慢,不会一上来就指责别人,对不甚了解的领域保持敬畏,以免看起来像个小丑。

上面的也是在吐槽,我还是说点对写好代码的理解吧。

代码是给人读的,顺便让机器执行

上面这句话我非常认同。好的代码是什么样子的呢?

Bjarne Stroustrup(C++之父)说:

逻辑应该是清晰的,bug难以隐藏。

依赖最少,易于维护。

错误处理完全根据一个明确的策略。

性能接近最佳,避免代码混乱和无原则的优化。

整洁的代码只做一件事。

Michael Feathers(《修改代码的艺术》作者)说:

整洁的代码看起来总是像很在乎代码质量的人写的。

没有明显的需要改善的地方。

代码的作者似乎考虑到了所有的事情。

可以感受到,对好的代码的理解有很多共通的地方:

1. 代码简单,代码意图明确,其他人才容易与你协作。

2. 可读性和可维护性要高。

3. 以最合适的方式解决问题。

4. 和大家共勉,不要做别人嘴里的「蠢蛋」。


Python语言给外人第一印象就是简单,上手快,有其他开发语言经验的人一周就可上手工作,好像Python就是这么简单似得。可是为啥合适的Python高级开发者这么难找?因为绝大多数开发者都止步于能完成工作这个程度,也就是我们经常自嘲的一个词「码农」。

不记得在哪里看过, 程序员有三种(我重新润色了一下):

1. 拿钱干活,不爽就换 - 程序员只是一份工作。

2. 只要能实现功能就好,学习进步太累了。这年代做技术没有管理挣钱多,技术搞得再好有什么用? 还不是买不起房啊。这年代关键是你认识多少人。你是不是有眼光去一个能上市会让你暴富的公司,能不能唬住粉丝儿和投资人。

3. 热爱程序本身的人, 这些人可能只有1%, 他们有目标的写程序, 他们愿意思考, 愿意听取正确地/更好的方法, 他们会热爱学习新的东西。

现在产品开发迭代非常快,一周要上多个版本,每天要提多个Pull Request,对于前2种人,只能疲于应付工作,怎么样能在天赋不够又不想多花时间进步的前提下完成工作,还能到领导的好评呢?这是一门艺术呢......

优秀的工程师在思考、重构,「其他」工程师在给自己找理由:「怎么组织代码、怎么提升运行效率、原理是什么」这些重要吗?代码能跑起来不就完了。需求这么多,做都做不完,哪有时间考虑怎么做得更好啊?

明年的今天「其他」工程师还写一样的代码, 唯一不一样的是Ta老了一岁。

对于这种「其他」工程师,我也确实没有办法,每个人有自己选择生活和工作的权力,我绝对尊重,本文也不是给这些人看的。

我的经验

假如你不满意现状,希望做得更好,但是苦于不知道自己进阶,我分享下自己的经验。

  1. 多看书,多读其他人的博客,阅读优秀的开源项目的代码甚至语言本身的源代码。这是一个长期的、琐碎的、需要学习之后记忆和实践的过程,看代码要思考别人为什么这样写,组织结构为什么这样用,这样写代码为什么快。当然最重要的还是实践。

  2. 想好了再开始写。大家都知道,核心的、重要的系统的代码上线后改动起来会很麻烦,非常有可能给未来留大坑,甚至于要耗费以年为单位的时间来填。所以前期的数据库表结构设计、工程实现这些东西要先想清楚了再开始写。

  3. 给自己提要求。实现过程中不断的提高要求,这个要求就是比你现有的能力要高一点点。一段代码写出来的时候考虑一下会不会有比自己写的好的方法,之前有没有遇到过别人的实现借鉴下等等。

  4. 选择更强的队友。遇见什么样的人,就会变成什么样子的人。去一个身边技术水平都比你烂甚至只是相当的环境,你能提高的空间非常有限。遇到一帮厉害的队友,能帮助你坐上进阶直通车,前提是你的心理素质要高,要不然长期的受到别人吐槽会产生大量不良情绪的。

  5. 对别人吐槽狠。这是我的个人秘笈。之前我写代码也没有那么高的要求,后来在代码评审的时候,我为了证明比人代码写的烂,不惜花费大量时间找各种证据吐槽别人(不能说人家写的烂,但是又写不出来更好的,做这种嘴炮啊),这个过程对我有极大的能力的提高,也包括搜索信息的能力。而且你吐槽了别人,别人正憋着劲还回来。你总不希望这件事发生吧,所以你只能让自己的代码写的更好,这无形中让你对自己的代码要求要高了很多。

可能有一天, 看到一段代码,骂了句「哪个蠢蛋写的烂代码?」 结果git blame一看原来是自己写的。恭喜你,你进阶了!


作者:董伟明

链接:https://zhuanlan.zhihu.com/p/22196816

来源:知乎


著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。


本文转载自异步社区

原文链接:https://www.epubit.com/articleDetails?id=NC7E3EF917D700001A35818AF1515A200

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。