您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 业务知识 > 正文

20年老码农分享20条编程经验,你pick哪些?

发表于:2022-03-30 作者:Alex 来源:量子位

本文经AI新媒体量子位(公众号ID:QbitAI)授权转载,转载请联系出处。

一位20年老程序员分享的编程经验突然火了,在Hacker News上,一天之内就收获了467热度。

这位老哥从1999年就开始编程,从早期的Basic、Pascal、Delphi,到后来的C,C++ ,Javasript等主流语言都用过。

职业生涯上从研究员、架构师一直干到过CTO,另外也当过技术产品经理,技术指导,老师等角色,可谓经验丰富。

其实这篇帖子所包含的观点大都是编程圈子里较常见的概念,但是这些年来有的话题一直很具备争议性。

对他的大多数经验,网友很赞同。比如:代码终究还是给人写的,注释是为了让未来的自己和其他同事能看懂。

不过针对有的观点,大家各执己见。最为突出的是下面这条,网友们对此讨论了60多楼:

要完全搞清楚要解决的问题,否则就先别急着敲代码。

一种有代表性的观点是:

大体上同意,但我发现要真正完全理解一个问题,还是至少要先写一个解决方案。

因为当我把一个问题分解成可编码的组件时,我学到了很多;在实际实现这些部分的过程中,我经常发现边缘情况或未定义的情况;现实情况下,真正的问题是什么,通常在开始并不清楚。

但也有一些网友认为:对于小型的、偏算法的问题,先在纸上或脑海中过一遍,比上来就写代码有效率的多。

emmm……这样讨论下去简直成了“先有鸡还是先有蛋”。

这个问题看来不会有确定的答案了,不过这篇经验分享整体上还有更多有价值的观点。

下面让我们具体来看看吧。

20年浓缩成20条经验

1. 不要与工具作斗争

所谓工具,包括库、语言、平台等。

尽可能多地使用原生的开发方式。这样可以保证程序或软件的数据都存在于本地,能够及时检索,保证程序或软件的合作速度和流畅度。

不要被技术捆绑,也不要被问题捆绑。应该为工作选择合适的工具,而不是为了工具寻找合适的工作。

举个例子:编程实现在一个文件中找到给定单词出现的位置并统计出现次数。

如果用C++写的话需要92行代码,而使用Python的话只用26行代码就可以完成了。

由此可见,对于同一个问题,换一个工具也许可以简化编程,提高效率。

2. 写让人可以看懂的代码

程序员们不是为机器编写代码,而是为了同行们和未来的自己编写代码。写代码的终极目标往往是完成一个项目或给后来者作为参考。

3. 善于合作

任何重要且有价值的软件都是协作的结果,有效沟通和公开合作很重要。能用众智,则无畏于圣人矣。

4. 对各模块分而治之

编写相互联系却又彼此保持独立的单个模块。先分别测试每个部分,然后一起集成测试。既要保证测试接近实际,也要测试边缘实例。

5. 敢于分享自己的原创代码

一个程序员不要成为那位唯一明白某段代码的人。可以对自己的原创代码进行优化,以便人们找到修复Bug的方式,和向代码添加功能的方法。

这样也能使程序员自己轻松点,以早点进入下一个项目或公司。

想要提高水平的话,不要使一段代码仅自己可见。

6. 安全是分层的

分层安全是一种应用多种安全措施的实践,每一层都与前一层和下一层重叠,以创建一个安全控制网络,这些网络可以一起工作以保护技术系统。每一层都需要单独评估,但也需要与整体相关。

风险是一种商业决策,与脆弱性和概率有直接关系。每个产品或组织都有不同的风险偏好,通常这三个关注点会相互冲突:用户体验、安全性和性能。

7. 代码也有生死

要认识到,每段代码都有一个生命周期,并且会最终失效。有时,一段代码甚至还没上线发布就被废弃了。

程序员要学会放手,弄明白4类特征的区别,然后想清楚应该在哪些方面投入时间和精力:

  • 核心:就像汽车的引擎。没有它,产品就没有意义。
  • 必要之处:就像汽车的备用轮子。它很少被使用,但当需要时,它的功能决定了系统的成功。
  • 附加值:就像汽车的杯座。有它很好,但产品没有它也完全可用。
  • 独特卖点:人们应该购买你的产品而不是你的竞争对手的主要原因。

8. 保护好个人信息

程序员不要将个人身份信息附加到代码中,也不要把其他人的身份附加到他们的代码上。

人是独立于他们的工作产出物之外的。不要把别对代码的批评当成是针对个人的,当然也在批评他人的代码时也要谨慎。

9. 尽量规避技术债务

技术债务是开发团队在设计或架构选型时,为了快速地解决问题,而采取的不规范的方案。偶尔的技术债务是可以接受的,但如果长期负债往往会快速地扼杀产品。

10. 可参考以下优先级

为解决方案做决定时,假设其他条件都是一样的,可以按照这个优先级:

安全性 > 可用性(可访问性和用户体验) > 可维护性 > 简单性(开发人员体验/DX)> 简短性(代码长度) > 性能

但是也不要盲目地遵循这个规则,还要考虑到产品的性质。例如,在设计游戏引擎时,性能是最重要的;但在创建银行应用程序时,安全性是最重要的因素。

11. 复制粘贴会带来Bug

有时复制粘贴后,会出现Bug,这个几乎无法避免。为了检查是否有问题,每次都需要搞明白复制过来的内容,并审核导入的内容。

12. 不要只为乐观场景写代码

还要写出好的错误提示,回答其为什么会发生,如何检测到它,以及如何解决它。

13. 尽量不要使用依赖库

若调用一个动态库A时,A需要调用动态库B,则B是A的依赖库。

尽量不要使用依赖库,除非导入、维护、处理边界情况时出现Bug, 或者当代码不满足需求时,重构的成本远远低于你拥有的代码。

14. 不要盲目跟风

可以去了解热炒的新技术,但不要被拽着走,要坚持自己对技术的品位。

15. 坚持学习

16. 最好的代码都有良好的注释

一些人认为,代码写的够好,就不用写注释了。但最优秀的的代码中往往都包含着良好的注释。这样,即使是没有经历过这段代码的调试、测验过程,且暂时不具备写出此代码能力的人都可以使用它。

可以说,未文档化的功能是不存在的功能,不存在的功能不该有代码。

17. 尽量避免重写、继承和隐藏信息

写纯函数(Pure Function)。对于纯函数,相同输入总是会返回相同的输出,执行过程中不产生副作用,且不依赖于外部状态。它们更容易测试和推理。

在执行一个非纯函数时,除了得到函数的返回值以外,还在函数调用时产生了附加的影响,如:修改了全局变量的状态,修改了传入的参数等。

任何非纯函数都应该是类,任何具有不同函数的代码构造都应该具有不同的名称。

18. 弄清楚问题后再开始编程

面对一个问题,首先要弄清解决思路,再开始编程。在编程过程中还需要逐步经历 “编码-测试-改进” 周期,并不断深入探索,直到完成。

19. 不要去解决不存在的问题

不要进行投机性编程。只有在确定代码将来会被扩展时,才去花功夫提高代码的扩展性。

因为当代码要被扩展时,有很大的可能性问题定义已经与代码初次编写时不同了。

20. 巧用社区、积极探讨

合作完成一个程序或软件往往更有趣。许多程序员包括技术大牛们都会在一些专业论坛(如Github、Stackoverflow等)上分享自己的原创代码,供他人参考、提建议以及修复Bug。

除了利用已有的论坛、网站外,还可以为自己的项目创建一个良好的社区。