架构师之路 — 部署架构 — Overview(架构师之路 沈剑)
1656
2022-05-30
格言一:“All problems in computer science can be solved by another level of indirection”
解读:“计算机科学中的所有问题都可以通过增加一个间接层来解决”,出自David Wheeler(剑桥大学计算机科学教授),这句话实在太顶,影响太深远忍不住放在第一位。不管是软件领域从设计模式到架构设计,还是硬件领域中例如存储系统层次结构都可以见识到这句话的威力。当你遇到任何计算机相关问题感觉没法解决时,首先想到的应该是这句话!
格言二:“Programming is like sex. One mistake and you have to support it for the rest of your life”
解读:“编程就像性,一个错误必须终身承受”,出自Michael Sinz(微软首席架构师),你的程序就像你的孩子,你总是细心呵护,并试图给他最好的,终生不休。但人非圣贤,总会犯错,关键在于从错误中学习提升自我,不放过任何一个从错误中恢复的机会。
格言三:“Simplicity is prerequisite for reliability”
解读:“简单是可靠的前提”,出自Edsger Dijkstra(荷兰计算机科学家),对于复杂性代价的洞察,没有人比荷兰计算机科学先驱迪杰斯特拉更深刻。开始实践写代码的时候,都倾向于搞得很复杂,否则的话会觉得“没水平”,等真正成为有经验的程序员后,蓦然回首,简单才是最可靠的,每个代码构建块都尽可能用最简单的方式表达。
格言四:“It's harder to read code than to write it”
解读:“读代码比写代码困难”,出自Joel Spolsky(StackOverflow合伙创始人)。代码虽然是让机器执行,但要靠人来维护,有经验的程序员都有这样的经历,自己几个月或者半年前些的代码,翻出来的时候完全忘了什么逻辑,如果代码难以阅读,自己掉坑里都爬不起来,何况如果是别人写的难以阅读的代码?这种代码后续维护人员根本不敢对其修改或改进。好的程序员会编写容易理解的代码,只有愚蠢的人才只管机器是否能运行。
格言五:“Don't reapeat yourself. Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”
格言六:“There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.”
解读:“计算机科学两件最难的事情:缓存失效,命名和差一错误”,出自Leon Bambrick。记得某位大牛说过命名大概占据编程1/3时间,本来词汇量就不大,真是活人要被命名憋死。缓存失效和差一错误,有经验的程序员应该很容易体会其中的痛苦,无须赘述。
格言七:“It takes 3 times the effort to find and fix bugs in system test than when done by the developer. It takes 10 times the effort to find and fix bugs in the field than when done in system test. Therefore insist on unit tests by the developer”
解读:“系统测试阶段发现和修复bug需要付出的努力是开发者自己解决的3倍。而上线后付出的努力又是系统测试阶段的10倍,因此,开发者一定要自己做单元测试”,出自Larry Bernstein,测试的重要性是毋庸置疑的,但是开发完了就上线,即使今天在一线大厂也时有发生,可以想象下其他公司这种情况更普遍。这样做的直接后果是本来可以在开发阶段比较容易搞定的问题,最后拖到线上爆发出来,导致工作量成数量级上升,看起来很快的开发节奏其实是最慢的方式,每天996的程序员需要看下是否能对号入座。编程是智力活动,一个人的精力是有限的,不可能一天24小时精力都高度集中,996意味着疲劳状态下开展智力活动,更容易出现bug,对有经验的程序员肯定有这种体会:线上发现的bug如果单拎出来,肯定会骂自己怎么会写出这么白痴的代码,但事实就是你写的!在软件开发的早期阶段尽早发现问题,成本就会越低,更容易把自己打造成高质量软件开发者的人设,所以单元测试尽早测,完备的测,否则你可能要审视下自己到底是在写bug还是写代码?
格言八:“Good code is its own best documentation. As you're about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn't needed?’”
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。