![](https://img-blog.csdnimg.cn/20201014180756916.png?x-oss-process=image/resize,m_fixed,h_224,w_224)
97个程序员该知道的事
尝试翻译经典资料《97 Things Every Programmer Should Know》,并加入一点自己的理解。
elegent Developer
每周一篇博文^_^
展开
-
97-things-every-programmer-should-know-34: 依靠开源项目实现理想
很有可能工作中无法开发出自己理想中的软件。 也许你正在一家大型保险公司开发业务系统,其实你更想去google, Apple, Microsoft之类的科技公司,但硬实力不允许啊。幸运的是,解决这个问题的最佳答案是:参与开源项目。 当前有数以千计的开源项目,大多数很活跃,能提供你想要的各种类型的开发经验。如果你很想开发操作系统,数十个操作系统开源项目可供你选择。如果你想开发音乐软件,动画,机器人,PC单机游戏,大型在线游戏,手机端等,你都至少能找到一个你感兴趣的开源项目。当然,天下没有免费的午餐,你不得不原创 2021-12-30 10:55:06 · 79 阅读 · 0 评论 -
97-things-every-programmer-should-know-32: 封装行为,而不仅仅是状态
在系统论中,控制 是处理大型复杂系统最有用的方式之一。在软件开发行业,控制或封装的价值很容易理解。可通过编程语言的子程序,函数,模块,包,类等进行控制。模块和包用于解决更大规模的封装需求,而类,函数等用于解决更细粒度的封装需求。**过去这些年我意识到类层次的封装似乎成为了开发者最难封装的结构。**找出一个类中main方法包含3000行代码的类并不常见,或一个类仅有属性和对应的get/set方法。这些示例证明开发者并没有完全理解面向对象思想,在利用面向对象建模方面是失败的。一个对象既要封装状态,也要封装行翻译 2021-08-17 12:04:13 · 86 阅读 · 0 评论 -
97-things-every-programmer-should-know-30:DRY(Don‘t Repeat Yourself)
在所有的编程准则中,DRY也许是其中最基础的一个了。该准则是从《程序员修炼之道》中首次提出。它是其他许多已知的软件开发实践和设计模式的基石。一个能够识别重复代码并且知道通过适当的练习和合适的抽象来解决问题的开发者能开发出更清晰的代码,相比而言给应用增加不必要的重复性的开发者会持续污染应用。重复意味着浪费每一行写进应用的代码最后都需要维护,也就意味着是未来bug的潜在来源。重复造成了不必要的代码库膨胀。导致更多机会出现bug,并增加了系统的偶然复杂性。更多重复性代码也会导致应用开发者无法全面的理解整个应用翻译 2021-08-06 15:19:55 · 94 阅读 · 0 评论 -
97-things-every-programmer-should-know-29: 不要依赖“魔法”的发生
如果你从足够远的地方观察任意的活动,进程或学科,你会感觉看上去挺简单的。无开发经验的管理者会认为程序员干的事挺简单的。 而无管理经验的程序员也会觉得管理者干的事没难度。编程这件事是一些人花一部分时间做。但难点的部分是思考 - 它是最不可见且不容易被外行所观察到的。过去的几十年人们做过很多尝试,试图去除有技术含量的思考。其中一个最早且让人印象深刻的努力是使得一个编程语言不再变得神秘,一些人预测这将消除对专业程序员的需求。结果… 这门编程语言(Cobol)这些年来却贡献了许许多多专业程序员的收入。软件开发行原创 2021-06-17 15:05:14 · 57 阅读 · 0 评论 -
97-things-every-programmer-should-know-27: 不要只是学一门新语言,而要理解它的文化
在经典书籍《The Pragmatic Programmer》,中文译《程序员修炼之道》中,作者建议我们每年学习一门新语言,我试着采纳他们的建议,数年之后我拥有了使用多种编程语言编程的经验。从我学习多语言编程的经历,让我意识到不仅仅是要学习它的语法,更重要的是学习它的文化。 你可以使用任何语言写Fortran,但真正学会一门语言需要拥抱它的思想。如不要在C#中写一个很长的Main方法,并且使用static方式调用静态方法,而是要理解类的优点。如果花了很长时间还是未能理解函数式语言中的lambda,不要觉得不原创 2021-06-14 14:29:36 · 1329 阅读 · 3 评论 -
97-things-every-programmer-should-know-26: 不要忽略错误
1原创 2021-05-29 14:45:37 · 87 阅读 · 1 评论 -
97-things-every-programmer-should-know-24: 不要怕做错事
每个有开发经验的人都有过基于不稳定代码库开发项目的经历。系统写的不好,想改一个功能,另一个不相干的功能可能也会弄坏。每增加一个功能,开发人员都小心翼翼,尽量做最小的改动,一直屏住呼吸,随时都在危险的边缘徘徊,直到版本顺利发布上线。做一点变动就如此紧张的原因是系统处于不健康的状态,它急需救治,否则会变得更糟糕。 你或许已经知道系统的问题点在哪里,但你畏首畏尾,害怕做错事。一位有经验的外科医生及时做切割手术,因为它知道伤痛是暂时的,为了后面的健康这么做是值得的,病人能恢复到比手术之前更好的状态。不要畏惧修改原创 2021-05-21 22:12:30 · 91 阅读 · 0 评论 -
97-things-every-programmer-should-know-22: 刻意练习
刻意练习不仅仅是完成一个任务。如果你问自己:“我为什么要做这个任务?”,并且你回答“为了完成这个任务”,那你就不是在做刻意练习。你刻意练习的目的就是为了提高完成任务的能力。它是关于技能和技术。...原创 2021-05-15 16:08:59 · 137 阅读 · 0 评论 -
97-things-every-programmer-should-know-21: 区分业务异常和技术异常
1原创 2021-05-13 17:19:34 · 207 阅读 · 0 评论 -
97-things-every-programmer-should-know-20: 持续部署
调试部署环境和执行部署经常会推迟到项目的末期。在一些项目中编写安装工具/脚本被委托给部署工程师。这样审查和演示常常会在一个手动搭建的环境中进行,以提前确保一切运行正常。这样就导致开发团队对部署过程无经验,或发现部署环境有问题时已经太晚了。一个简单的安装/部署过程是确保有一个可靠(至少易于调试)的生产环境,其中部署的软件是客户即将要使用的。通过验证部署环境是否正确,你会发现并提出问题需要客户及时解决。同时开发进程中一直关注着部署进程会避免代码只适应开发/测试环境,可更早的去生产环境试。将部署过程留到最后意原创 2021-05-12 12:00:39 · 57 阅读 · 0 评论 -
97-things-every-programmer-should-know-19: 设计API不能只注重方便
关于设计一个好API的重要性和挑战性已经说过很多次了,首次设计API就正确很难,更难的是后期要持续更改它,就像抚养小孩一样。大多数有经验的程序员已经意识到一个好的API需要遵循一致的抽象层次,表现出一致性和对称性,但需要意识到指导原则不会自动转化为正确的结果。避免空谈,我选择一个特定的API设计策略: 一个反复遇到的问题-参数的便利性。通常有以下见解:如果另一个方法跟当前方法几乎相同为什么要新建一个方法?直接加个开关即可。如果第二个参数是以".txt"结尾,这个方法自动判断第一个参数是文件名,所以不原创 2021-05-11 19:29:15 · 47 阅读 · 0 评论 -
97-things-every-programmer-should-know-18: 持续学习
我们生在一个有趣的时代。随着开发工作在全球分布,你很快就会意识到有无数的人都能胜任你当前的工作。你需要一直学习以保持市场竞争力,否则你会变得跟恐龙一样,陷入同一个工作直到某天你的工作变得无用或者被廉价的外包资源替代。所以应该怎么应对呢?一些老板比较慷慨,会为员工提供技术培训以提高员工工作技能。而其余大部分的老板可能抽不出时间和...原创 2021-05-08 14:40:39 · 93 阅读 · 0 评论 -
97-things-every-programmer-should-know-17: 仅注释代码不能自解释的部分
在理论上,写代码注释听上去非常有价值:给读者提供足够详细的信息,对程序进行解释。但在实践中,注释常常会变得有害。跟其他任何内容的写作一样,写出好的注释也需要一定的技巧。其中很多技巧是知道什么时候不该写。当代码语法错误时,编译器,连接器等会及时发现,如果代码是某些功能不正确,代码审查,静态代码分析,单体测试以及日复一日的使用中也能发现。但如果注释不当,很难及时纠正。如果注释不当它的价值为零甚至是负值。如果注释本身没有技术上的错误,但对理解代码没有价值呢?这些注释即是噪音。仅仅是模仿代码的注释对读者没有任何原创 2021-05-07 16:22:09 · 86 阅读 · 0 评论 -
97-things-every-programmer-should-know-16: 代码注释
仅仅让程序实现功能是远远不够的,编码的核心是要让下一个读你代码的人能顺利理解你的代码。代码注释不是无用的,他们和编码中基本的分支,循环等一样重要。大多数的现代开发语言都有类似javadoc的工具,能自动解析注释并生成API文档。这是一个好的开始,但还不够。在代码的内部需要解释代码做了什么。 一个关于编码的古老格言:“如果代码难写,那一定难读”。另一方面,也不能走另一个极端,即做了过多的注释。**确保注释能澄清代码而不是造成混淆。**代码头部的注释应该能让读它的人足够理解代码块的意图而不需要读取具体的代码原创 2021-05-07 11:43:10 · 81 阅读 · 0 评论 -
97-things-every-programmer-should-know-15: 合理编码
试图通过人工以正式的方式证明软件的正确性远比通过读代码的方式时间要长,并且大概率判断出错的可能性也大于后者。最好使用自动化工具,但也不总是能奏效。许多好的编码实践会让通过读代码分析软件的正确性更容易,如下:避免goto语句,避免让不相干的部分相互依赖。避免使用可修改的全局变量,这样会让所有使用该变量的代码相互依赖。每个变量尽可能的保持在最小使用范围,如一个局部变量应该定义在首次使用它的上一行。使用空格使得代码可读性更佳,包括横向和纵向。如让相关联代码块对齐,并且用空行隔开不同的代码块。为变量名原创 2021-05-07 10:30:09 · 71 阅读 · 0 评论 -
97-things-every-programmer-should-know-11: 使用领域语言开发
两段代码进行比较:if (portfolioIdsByTraderId.get(trader.getId()) .containsKey(portfolio.getId())) {...}和if (trader.canView(portfolio)) {...}很明显看第一段代码你需要进行思考,理解代码的意图,而第二段一眼就能看出代码的意图。不需要深度去理解内部的业务逻辑实现。从前,我们仅有非常基础的数据结构:二进制位,字节和字符(本质也是字节,我们假装他们是字母和符号),基于十进制的浮点原创 2021-05-06 15:01:17 · 76 阅读 · 1 评论 -
97-things-every-programmer-should-know-14: 代码审查
你应当做代码审查,原因是可以提高代码质量和降低缺陷率。很多人他们之前可能在代码审查上体验不太好,导致不喜欢代码审查。一些单位要求所有代码部署到生产环境之前都要通过正式评审。通常是架构师或项目组长做,即执行架构师需要评审一切的活动。有些是公司在软件开发规范手册中有硬性规定,因此开发者必须遵守。也许有些单位需要这些严格和正式的过程,但绝大多数应当不需要,在大多数单位中实践这种强制且正式的方式会适得其反。被审查者会觉得像是在接受审判,同时审查者既需要时间来阅读代码,也需要时间来理解系统的所有细节。审查者很快会原创 2021-05-06 19:28:00 · 52 阅读 · 0 评论 -
97-things-every-programmer-should-know-13: 代码布局问题
有研究表明我们花在找代码,阅读代码的时间要远远大于实际编写的代码,所以这是我们尝试优化的点:易于浏览。 人类擅长可视化模式匹配。如果代码行为相同看起来也相似,那感官系统能帮助分辨不同的地方。这也是为什么遵守如何在类中进行布局:常量,字段,公共方法,私有方法。富有表现力的布局。 我们已经发现良好的变量命名会让代码自解释,增强可读性,这远远比代码只是步骤的罗列要强。压缩格式。 能在屏幕上看到的越多,就越能在不破坏上下文的情况下滚动或切换文件。小结好的代码看着像一首诗。真正好的代码都有一原创 2021-05-06 16:44:14 · 81 阅读 · 0 评论 -
97-things-every-programmer-should-know-12: 编码即设计
想象明早醒来后,发现建筑业取得重大进展。数以百万计的廉价,极快的机器人能凭空制造材料,接近零成本的能源消耗,并能自我修复。并且它能进化的更好了:给到明确的建筑蓝图,机器人就能在无人工干预的情况下以微不足道的代价自动建造。可以想象对建筑业产生的深远影响,但它的上游会发生什么?如果建筑成本可以忽略不计会对建筑设计师产生什么影响?如今在建筑真正建造之前,物理和计算机模型都要经过严格的构建和测试。如果建筑成本没有还会这样吗?如果一个设计失败了,找到原因,让机器人再重造一个就是了。我们预测时间线的能力将逐渐散失。原创 2021-05-06 16:03:08 · 70 阅读 · 0 评论 -
97-things-every-programmer-should-know-10: 小心选择工具
现代应用系统极少从0开始构建,基本都会使用现有工具,如组件,库和框架,有以下原因:应用的规模,复杂度和成熟度都在上升,而要求的开发时间却在持续减少。使得需要开发者的时间和精力都要专注到业务逻辑上,而不是基础设施上。广泛使用的组件和框架非常可靠,比自己现造一个轮子要经济。网上有很多免费的高质量软件可用,采用它意味着更低的开发成本和更容易找到熟悉该技术的开发人员。软件开发和维护是人工密集型工作,所以购买或许比自己开发划算。所以为自己的应用选择合适的工具需要深思熟虑,在技术选型的时候以下事项需要纳入原创 2021-05-06 13:33:41 · 88 阅读 · 0 评论 -
97-things-every-programmer-should-know-9:责怪他人之前先检查自己的代码
所有开发者都有一样的通病:即不承认是自己的代码出了问题, 会从其他地方找原因。而事实上,编译器,OS,中间件,数据库等造成代码出现bug的可能性极小。如果这些工具,系统被大规模使用,被应用到各种技术栈,几乎无理由怀疑其质量。当然,如果是早期预览版或应用群体范围小,或下载量少,或者是alpha版本有理由怀疑其质量。考虑到编译器,中间件,数据库等错误非常罕见,当出现bug时最好将精力放在自己的代码上,做好问题隔离,做全单体测试;检查调用约定,共享库和版本号;检查栈调用异常和变量类型是否匹配;在不同的机器上编原创 2021-05-06 11:28:29 · 64 阅读 · 0 评论 -
97-things-every-programmer-should-know-8: 童子军规则
规则是:总是让营地比你发现时更干净。如果我们在写代码时也留下类似规格,那就是:当checkin代码时总是比checkout时更干净。不管源作者是谁,不管功能模块多么小,一直能做一些提高,最后的结果会如何?如果所有人都遵循该简单规则,我们的软件系统将会越来越好。不需要每次checkin做到完善,只要做一点点改善即可。这意味着新增的代码必须clean, 可能优化了变量名,重构了函数将大的函数切割为小函数,解决了循环依赖。###### 总结总是保持checkin的代码比checkout时更干净应该原创 2021-04-30 19:06:01 · 65 阅读 · 2 评论 -
97-things-every-programmer-should-know-7: 小心共享
在大学中重用一直被认为是高质量软件工程的缩影。但却忽略了重要因素:背景。事实上系统中两个完全不同的部分以相同的方式执行某些业务逻辑,这种场景比想象中要少。当未提炼出公共库之前,这些原本不相干能根据自己的场景独立演化。出现相似代码仅是偶然。我自己创建的共享库将不相关的部分连在一起。这些独立函数的维护代价原本可以忽略不计,但公共库需要更多数量级的测试。虽然减少了单个项目代码的绝对数量,但却引入了更多的依赖。###### 总结想当然的...原创 2021-04-30 18:47:11 · 52 阅读 · 1 评论 -
97-things-every-programmer-should-know-6: 在重构之前
每个程序员在某些时候需要重构现有代码,在真正做之前,以下事情值得先考虑:###### 重构的最佳实践是评估现有的代码库和针对现有代码的测试用例这有助于理解现有代码的优点和缺点。###### 避免想重写一切的诱惑要尽可能的重用现有代码。不管现有代码多糟糕,起码已被审查,测试。直接丢弃旧代码,特别是生产代码,意味着丢弃了数月已被测试的代码,且可能已包含你不了解功能和bug。###### 许多渐进式的小改进优于一个大的变更渐进式的小改动有助于通过反馈更容易的评估对系统的影...原创 2021-04-30 16:05:14 · 147 阅读 · 4 评论 -
97-things-every-programmer-should-know-5: 简洁就是美
有若干事情是我们写代码一直所追求的:1. 可读性好2. 可维护性好3. 开发效率高4. 无法描述的美这些因素都跟代码简洁相关。当你学习业内专家写的代码时,你会发现一个共性,你认为好的和优美的代码都是简洁的。无论多么复杂的应用或系统,拆分出的每个部分都保持简单。具有单一职责的简单对象,包含具有描述性名称的简单方法。 一些人认为5~10行代码组成的方法是一个理想目标。###### 总结漂亮的代码一定是简洁的代码。每个独立的部分保持简单,单一职责,跟系统的其他部分关系简单。只.原创 2021-04-30 15:20:23 · 126 阅读 · 1 评论 -
97-things-every-programmer-should-know-4: 自动化编码规范
你可能也经历过,在项目的初期大家定好了一些列的规范,很多都落实到了文档上,关于编码就是编码规范,在启动会上,leader强调大家要遵守规范,大家也举手赞成,但一旦项目启动,这些规范就被抛到了脑后。项目结束后,面对一团糟的代码,大家都不知道为什么会变成这样。为什么会发展成这样?可能启动会时一些人没注意,一些人没理解要点,甚至一些人反对规范的要点,盘算着用自己的规范。最后,一些想遵守规范的人当面临项目进度压力时,也抛弃了规范。当客户需要更多功能时格式优秀的代码并不能加分。如果不能自动化编码规范,遵守起来比较枯原创 2021-04-30 15:02:45 · 79 阅读 · 0 评论 -
97-things-every-programmer-should-know-3: 询问用户会做什么?
我们总是会倾向于其他人的想法跟自己一样。事实却不是。心理学家称之为“错误的共识偏见”。但发现别人跟自己的想法不一样时,潜意识会有偏见,觉得对方某方面有缺陷。这种偏见解释了为什么程序员很难站在用户的立场思考。用户不会有程序员思维,研究电脑少,对计算机运行原理也不关心。这意味着它们不能利用程序员们熟悉的解决问题的思路。了解用户想法的最好方法是去观察他们。多问问为什么他这么做而不是那样做。用户做核心事务的顺序都类似,犯错的地方也类似。你需要围绕核心行为做设计。这跟设计需求会很不同,那大部分是猜想,会导致复杂原创 2021-04-30 14:21:47 · 68 阅读 · 0 评论 -
97-things-every-programmer-should-know-2: 使用函数式编程
函数式编程重新受到主流社区的关注。部分原因是因为功能范式的新特性能够很好地应对我们的行业向多元化转变。但不是最主要的原因。应用函数式编程能极大提高编码质量。如果你真正深入理解了函数式编程范式,你的设计将在参考透明度(referential transparency )上上升到更高的层次。参考透明度是一个非常理想的特性:无论任何时候任何位置,函数对同样的输入总是输出相同的结果。命令式编程的主要缺陷是可变变量。函数式编程通常缺陷更少,且易于调试,因为定位引入错误值的位置比其他方式去推导错误赋值的特定上下文原创 2021-04-30 13:56:48 · 86 阅读 · 0 评论 -
97-things-every-programmer-should-know-1: 谨慎行事
无论做任何事情,都要考虑后果和谨慎行事原创 2021-04-30 13:14:19 · 152 阅读 · 0 评论