软件开发的 22 条黄金法则

编程本质上是一门手艺活,既然是手艺,里面就会有很多个人技巧和经验。

“破窗理论”,DRY(Don’t repeat yourself),曳光弹,正交性,这些词的意思是什么你还记得么?

《程序员修炼之道》这本书在我看来就是一本师傅写给徒弟的开发哲学指南

里面既讲了一些软件开发的哲学,比如破窗理论,它解释了你的代码为什么很快就会变成“屎山”。也讲了一些有用的技巧和工具,比如如何利用好 shell,提升你的编程效率。

这本书没有复杂的代码,没有晦涩难懂的原理,你完全可以当作一本闲书来看

这本书里提到的看似人人都懂的道理,恰恰是很多码农们平常工作中最不重视,却应该去遵守的理念。

我提炼了一些书中我觉得至今仍然没有过时的观点(毕竟本书有一定的年头了,读起来很有年代感),和大家分享下,这中间也夹杂着一些我的看法和思考

一、开发的哲学

  1. 作为开发,你需要对自己说的话负责。对于不可能做到,风险太大的事情,你有权不去为之负责。

  2. 不要给做不到找借口,在你说做不到的时候,要提供你的想法,告诉大家,做不到的原因是需要重构,还是需要时间做原型,还是需要额外的资源支持。

  3. 破窗理论:一扇破窗户,只要有那么一段时间不修理,就会渐渐给建筑的居民带来废弃感。于是窗户就会一个个破碎,人们开始乱丢垃圾,乱涂乱画。所以不要容忍你的代码有“破窗户”。

  4. 这一点大家肯定也深有感触,在你写代码的项目里一旦看到了一些乱七八糟的结构和设计,你也会不自觉地开始往上面写凑活的代码,慢慢就变成屎山了。

  5. 温水煮青蛙,代码是会慢慢腐烂而不被察觉的。要持续不断的观察你项目的变化,而不要只是专注于自己的那一块代码。

  6. 重视你的”知识“,这是你的资产。既然是资产,就要定期投资(不断学习),多元化地学习。并且要定期的评估你的技术方向,毕竟开发是个动荡的行业,现在吃香的技术过几年就会过时。要不断地调整你的方向。

  7. 在做需求时,要像用户一样去思考需求的合理性,而不是一味完成产品下发的需求。

  8. 做的软件,要温和的超出用户的期望。给他们的东西要比他们的期望多一点,给系统增加特性时,多做一些额外的努力,可以给你带来很大的美誉。

  9. 当你在的开发团队人员庞大时,可以指定每个人负责工作的各个方面。围绕功能,而不是工作职务进行工作的分配。比如有人要讨论日期处理,就去找 Mary,有人要讨论数据存储,就去找 Fred。

二、开发的准则

  1. 不要重复你自己:DRY(Don’t repeat yourself)系统中的每一个组件都要单一,没有歧义,并且权威的表示出来。

  2. 保持项目的系统正交性:不要让系统间互相耦合,非正交的系统意味着你修改这边的系统,会影响到其他的系统。

非正交的一个典型体现是前端的 CSS,网上有很多调侃 CSS 的段子,CSS 的一个修改经常会影响到别的地方,这也是 CSS 很让人痛苦的一个地方。在后端开发里,我们要尽量让系统间不要相互影响,这对系统的伤害是很大的,并且在排查问题时非常痛苦。

  1. 保证代码设计的可撤销性:如果你的想法是这个问题的唯一解,那么这会是一个很危险的事情。用户的需求变化的很快,你的决策很可能只在当下是正确的,不存在最终的决策,或者说,时刻要注意和反思,如果现在这个方法行不通,是不是就没法挽回了。

  2. 做好资源的估算:这里的资源指的是很多代码相关的资源,比如数据库,存储,性能等。在开发前,一定要做好估算,在设计良好的代码结构,保证再未来能够应付变化。

  3. 把文档尽量多的做在代码里,而不是游离于代码之外。否则,过了一段时间后,你这些文档就没有什么作用了。

  4. 你不可能写出完美的软件:作为一个开发,你要有这种自觉,自己也不要相信。所以要对自己可能犯的错误,做防御性的编程。

  5. 异常处理:如果我删掉所有的异常处理代码,这些代码是不是还能运行?如果你的回答是”不能“,那么说明你的异常代码正在被用在非异常的情形中。这样不好。

  6. 利用好元数据:这里的元数据可以理解为配置文件。将抽象放进代码,将细节放进元数据。

我们日常开发中经常使用配置文件和分布式配置中心,把能够放入配置文件的数据尽量放入,这样不仅方便维护和修改,也能够实现不重启应用修改应用行为的功能。代码中应该只有我们对业务的抽象。

  1. 考虑好系统并发:要为并发做好周全的考虑。

这个要求是不是看起来很稀松平常,大家都会?其实很多大型系统,尤其是老的系统,都没有考虑并发问题(去问问传统软件企业做的软件,你就知道了)。并发其实可以算作是互联网公司最常遇到的问题,也是各种技术面试会问的很深的问题,要好好掌握。

  1. 不要靠巧合编程,要弄清楚程序为何能够运行。

我们接触变成初期,经常会有些代码调着调着就跑通了,但是连自己也不知道为什么。这种代码真正用于线上风险很大。毕竟,他也许不是真的能工作,他也许只是看起来能工作!

  1. 什么时候该重构:当你发现这四个事情出现的时候,就是你该重构的时候。

  • 代码违反了 DRY 法则

  • 有非正交的设计

  • 需求变化后代码过时了

  • 性能有很大问题

  1. 重构时的准则:

  • 不要试图在重构的时候同时增加功能。

  • 在开始重构前,确保你拥有良好的测试,这样你才敢放开手脚改动。

  • 采取短小,深思熟虑的步骤。

  1. 在测试的时候,要去做状态覆盖,而不是追求代码覆盖率。

  2. 好好学习 shell:通常我们喜欢用各种带界面的软件,他们的特点是所见即所得。但是也带来了缺点,所见即全部所得(what you see is all you see)。这对于效率的提升是一个瓶颈,有很多 GUI 上面需要很多操作的事情,在 shell 上只需要一行代码。所以尽管它有点难入门,但是学好了,会大幅度提高效率。

关注我

我是一名奋斗在互联网一线的后端开发工程师。

平时主要关注后端开发,数据安全,欢迎交流。

原创文章主要内容:

  • 开发实战

  • 技术面试

  • 算法题解/数据结构/设计模式

  • 程序人生

个人公众号:后端技术漫谈

如果文章对你有帮助,请各位同学 点赞 转发 收藏 三连,你的支持是对我莫大的鼓励~

本文文字及图片出自 InfoQ

本文文字及图片出自

余下全文(1/3)
分享这篇文章:

请关注我们:

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注