彼之蜜糖,吾之砒霜——聊聊软件开发中的最佳实践

“描述一个事物,唯有一个名词定义它的概念,唯有一个动词揭露它的行为,唯有一个形容词表现它的特征。要做的,就是用心去寻找那个名词、那个动词、那个形容词……”

—— 福楼拜 (Gustave Flaubert)

  我想讲个故事。

  很久很久以前(一般讲故事都是这样开头吧), 两个老工程师在一起聊天,谈各自生涯中最自豪的工程。其中一个先讲述了他的杰作:

  “ 我们建造的桥,横跨一个峡谷,峡谷很宽很深。我们花了两年时间研究地质,选择材料。聘请了最好的工程师团队来设计方案,而这又花了五年时间。 我们签下了最大的工程队,委托他们建造基础结构、塔墩、收费亭,以及用于连接桥梁和高速公路的道路。桥面下层是铁路,我们甚至还修了自行车道。 那座桥花费了我数年的心血。”

  另外一个听完之后,陷入了沉思,过了一会儿,说到:

  “ 有一天晚上,我和一个朋友喝了点伏特加,然后我俩扔了一根绳子,越过一个河谷。呃…… 就是一根绳子,两头系在两颗树上。 河谷两边各有一个村庄,起初,有人加了个滑轮,用来传递包裹。然后,有人拉起了第二根绳子,勉强可以走走,虽然很危险,但小伙子们很喜欢。 后来,一群人重新修建了一下,使得更牢固。于是,女人们也开始从上面走,每天带着她们的农产品过桥。 就这样,在桥的另一边形成了一个市场。因为地方开阔,造了很多房子,慢慢地发展成了一个镇子。 绳索桥被木桥替代,这样就可以走马车了。 后来,镇上的人们修了一座真正的石桥。再然后,人们又把石料改成了钢材。 如今,那座钢构悬索桥依然伫立在那里。”

  前一个工程师沉默良久,说到:“ 有意思。我那座桥建成大约十年后,被拆除了。事实证明我们选错了地点,建好的桥没人用。据说有几个野路子的家伙,在下游几英里处,拉了一根绳子,所有人都从那走。”

金门大桥(旧金山)

  我很喜欢这个故事。故事的出处,在一款消息队列产品—— ZeroMQ 的官方指南第6章里。

  

  说完故事,我想聊聊软件开发中,常常可以听到的一个概念 —— Best Practice :最佳实践。Wikipedia 上对其解释为:

A best practice is a method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things. 

  (最佳实践是一种:因其产生的结果优于其它选择下的结果,或其已经成为一种做事的标准,从而被普遍认可优于任何替代方案的方法或技术。)

  这个概念源于管理学,然后在 IT 界泛滥。简而言之,就是所谓“正确的做法”。

  最佳实践本身是美好的存在,犹如夜空中的一轮明月,照亮黑暗中的方向,指引着摸索前行的凡人。

  但凡事有度,子曰:“过犹不及。”

  

  我今天想说的,就是这月亮的背面。(传说中,月球背面隐藏着…… 嘘~)

潮汐锁定导致月球永远以同一面朝向地球

  首先,最佳实践容易带来思想包袱,让人无法专注于解决问题本身。

  总是希望采用最好的技术方法,不愿意在不正确的做法上浪费时间,导致瞻前顾后,甚至裹足不前。此时的最佳实践,已然成为了一种毒药,一旦偏离了问题本身这个出发点,就会不知不觉走进“宏大构想”的思维陷阱。把简单的问题复杂化,阻碍了迈出第一步,直到能规划出“包罗万象”的解决方案后才肯动手,拖延症就这样来了,时间却走了。

  你想好了未来每一天怎么过吗…… 没想好? 那……不活了?

  其次,对最佳实践的执念容易让人钻牛角尖,将目标的重心带偏。

  过度关注实施过程是否符合标准化,忽视了项目中其它重要的东西,比如用户体验,比如实际需求。就像故事里讲的那样:第一座大桥,几乎是教科书般的标准化路数,可产品落地后和客户需求却差了好几英里;第二个看上去很野路子,但精准地解决了痛点,从始自终都是紧紧围绕实际需求迭代,每一次的进步都可以产生效用,这才叫杀手级应用。

  这让我想起了 Plan-9 的传说。

  你听说过 Plan-9 OS 吗? 一款由贝尔实验室的极客们打造的用于完善 UNIX 不足的操作系统。什么不足?在 UNIX 的哲学中,有一条叫做 “一切皆文件” ,但实际上UNIX本身并没有严格遵从这一条。于是,Plan-9 OS 完美实现了这一点。然后呢……? 没有然后了。它从没进过市场,所以如果你没听说过它,一点也不奇怪。Plan-9 OS 没有解决任何现实问题,没人在乎 “一切皆不皆文件”。

  这种执念的另一种表现就是工程师思维,沉迷于奇技淫巧中无法自拔,程序员尤其容易中招。

  比如性能优化。“优秀的程序员应该榨干每一字节内存”,听起来很熟悉,不是吗?但经济学上来讲,边际效应决定了一次项目中,越优化性价比越低。有一个很容易被忽略的事实:硬件其实比程序员要便宜

  再比如对设计模式的崇拜。设计模式当然是好东西,但如果像强迫症一样使用它们,坚持用上它们才是正确的编程,就会导致按图索骥,强行让问题去适应设计模式,而不是让解决方案针对问题,这就本末倒置了。

  我有个基友,C++ 极客。毕业后入了腾讯,积累了巨额财富后,自己创业了。当然,当老板可比写 C++ 难多了,于是现在又去积累巨额财富了。想当年和那厮聊天,言必出设计模式,没事侃正则,再没事就研究 GC 策略 (好像玩 C++ 的普遍这德性) 。前不久看他代码,差点没认出来,这家伙画风一转,现在连接口都懒得多用(估计看到这,某些狂热分子肯定在破口大骂:你什么意思,你说你没用面向接口编程?)那位兄台甚至都懒得多聊,轻描淡写来一句,“没心思,以后有需要再加。”

  顺便扯一句,那哥们最近负责开发一款手游,他跟老板汇报的时候,预估的研发周期要12个月,然后老板跟他说:“好,12月出公测。” (哈~ 估计他肯定舌头打结把“12个月”说成了“12月”)。看到这的你,是否回忆起了你的老板?

  这也是我接下来想说的关于最佳实践的另一个问题:项目实施。

  工作数年,大小项目经历若干,慢慢体会到,一个项目的开发顺利与否,并不在于技术选型是否为最佳实践,更多的时候,取决于开发方案和技术储备之间的平衡。做项目毕竟是要讲方案落地的,如果最佳实践中的技术成本,超出了开发者的落实能力,那就是坑,这时盲从最佳实践无异于挖坟。如果是一个人的项目,抽时间恶补一通,兴许能填填坑,这取决于IQ。但要是一个团队,那就不是什么 IQ,EQ,QQ 的问题了,这中间产生的学习成本,集体培训成本,反复沟通成本,大量的初级错误,千奇百怪的代码,互相冲突引发的焦躁情绪,等等。这些负面的东西如果不能妥善的处理,足以抵消掉最佳实践带来的好处。别忘了,deadline 正在迫近。

  我自己曾经在一个项目组里,强行推行 Git 做源代码管理,当时组里共9人,有7人只会 SVN,但我坚持 Git 是 “最佳实践”。要不说年少无知少不更事呢,罢了,后来的事情我不想回忆了…… 那次项目之后,我再也不在一群只会 SVN 的队伍里提 Git 了。

  

  一个人做软件已经很难,比这更难的,是一群人做软件。

  当尘埃落定,蓦然回首,最佳实践很可能没你想象中那么重要。它更多的是一种精神层面的求道,并非物质世界的必要。

  扎克伯格 ( Mark Zuckerberg ) 于2004年在哈佛柯克兰公寓 ( Kirkland House ) 里写出TheFacebook 的时候 ( 次年更名为Facebook ) ,用的是 “世界上最好的编程语言” PHP。这门可能是业界被吐槽次数最多的语言一直支撑着FB帝国的诞生,直到席卷全球。Stack Overflow 的联合创始人 Jeff Atwood 曾公开揶揄 Facebook 是一家 “召集全球顶级程序员在 Windows XP 上写 PHP ” 的公司。但这无所谓,24年前的马克也不纠结。一直等到需要的时候 (2010年),Facebook自己动手研发了一个编程语言 —— Hack,来解决 PHP 带来的危机。

《社交网络》

  最佳实践,关键在时机(Timing)。

  如果说用 Facebook 这个 “根本不存在” 的网站来举例,纯属虚构的话,那我们来说点真实的例子,Web 技术的基石——HTML。由20世纪最重要的100人之一的 Tim Berners-Lee 创造的 HTML,其发明之伟大,足以单独开篇博文来赞美了,这里就不赘述了。

  这样一个造福全人类的神作,本身的设计结构绝非完美,甚至可以用混乱不堪来形容。没有严格统一的约束,形同虚设的规范,标准化进程的难产。以至于在很长一段时间内,连自身元素的定义,都可以向浏览器厂商妥协。但是,种种被人诟病的存在,丝毫不影响 HTML 改变世界的脚步。你我今天能相会于园,皆仰赖它的诞生。

  同样的例子还发生在 Web 世界另一个巨擎上——JavaScript。当今世界,Web 前端技术已经水银泻地般肆虐整个开发界,前端框架百花齐放、JS 衍生品鳞次栉比。所有这一切的背后,全都源于上世纪90年代横空出世的 JavaScript。

  那么,JavaScript是最佳实践吗?

  别逗了,如果有什么语言可以和刚才说到的 PHP 竞争一下谁被骂的次数更多,那非 JavaScript 莫属。这个仅花了十天设计出来的语言,打一出身就被贴上了怪胎的标签。混乱的标准,多样的实现,安全漏洞,语法随意,反人类…… 总之,JavaScript 和最佳实践半毛钱关系都扯不上。但它却是撑起当今互联网半壁江山的擎天柱。

  所以,用最接地气地话来说,不管黑猫白猫,逮着耗子就是最佳实践猫。

  彼之蜜糖,吾之砒霜。所谓最佳实践,其定义本身往往也是分歧的源头。什么是最佳?这个最佳是独一无二的吗?世界上有很多很多现实问题,可能根本就没有所谓的最佳实践。

  请听题,世界上最好的编程语言是哪个?

  第二题,世界上最好的文本编辑器是哪个?

  朋友,这天还聊得下去吗……

  

  最后,说一个我自己的故事。

  很久很久以前,为了找一款满意的文本编辑器,我干了一件可能是前无古人,后不知道有没有来者的蠢事 —— 我打开 Wikipedia,搜索 “ text editor ” ,然后转到一个叫做 “ List of text editors ” 的页面,接下来的一个月,我几乎把当时那个页面上,所有我能下载安装的文本编辑器,全部试用了一遍……

  嗯?你问我为什么这么做?呵呵,不把全世界的文本编辑器遍历一遍,我怎么知道哪个是最好的?

  这事细节我不想再提了,我也不想回忆了。要不说年少无知少不更事呢,时至今日,我想不出比这更愚蠢的事了。WTF~~

这个页面上的表格行数逐年增多

  如今,再有人问我最好的编程语言或者最好的文本编辑器的问题的话,我会说: 

 

  “朋友,要打架吗?”  

  这两个问题的最佳实践,唯有暴力。

原文:https://www.cnblogs.com/sherrywasp/p/9436623.html

原文地址:https://www.cnblogs.com/yanglang/p/9461659.html

时间: 2024-10-06 04:11:13

彼之蜜糖,吾之砒霜——聊聊软件开发中的最佳实践的相关文章

对软件开发中uml建模的理解和图形整理(一)

由于uml(统一建模语言)在开发中经常会用到,特别是在软件开发中的OOAD阶段,因此要理解和使用uml显得尤为重要.在uml开始之前,咱先回顾一个OOAD.OOP的主要特征. OOAD:根据面向对象的方法学来对软件系统进行分析和设计的过程.它包括OOA 分析阶段和OOD设计阶段.其中分析阶段主要解决"What to do?"的问题,而设计阶段主要解决"How to do?"的问题.具体来说就是:在OOA分析阶段咱要做的主要工作就是建立对业务问题域的视图(建立模型).

对于软件开发中开发人员与测试人员关系的理解

在软件开发中都会有开发人员(以下简称开发)和测试人员(以下简称测试),在一些小型公司可能并没有测试,仅仅是开发兼任测试.在这里我仅针对于有专业的测试和专业的开发的项目. 每个公司应该都有考核机制,对于开发和测试的考核实际上很难量化,通常来讲大的方向就是开发所负责模块的bug数,对于测试来讲就是测出来的bug数,但这真的有效吗?这也许对开发有约束力,理论上开发是能够自己控制bug数的,如果从产生的bug数来评判开发的绩效还算有效,这样开发自然就会把代码写得更加认真.但如果根据测试测出来的bug数来

软件开发中几个基本概念

软件开发中几个基本概念 Peixu.Zhu 自己真的深切理解那些经常挂在嘴边的概念么? 抽象 Abstract 抽象的特点是仅存在于思想和理论之中,而非物理或者具体的存在.(不是指C++中的抽象类) 抽象是永存的,不会随着时空而发生变化. 具体 Concrete 具体的特点是物化的或者是具备物理形态,是真实存在的. 具体不是永存的,是随着时空而发生变化的,仅存于具体的时空之中. 具体和抽象的最大区别是是否随着时空而发生变化,即是否存在于我们的四维空间. 实体 Entity 实体是单独的个体事物(

软件开发中,什么是模块化开发?

软件产品可以被看作是由一系列具有特定功能的组件组成,作为一个完整的系统也可以被分解成一系列功能模块,这些模块之间的相互作用就形成了系统的所有功能. 所谓模块是指可组成系统的.具有某种确定独立功能的半自律性的子系统,可以通过标准的界面和其他同样的子系统按照一定的规则相互联系而构成的更加复杂的系统.每个模块的研发和改进都独立于其他模块的研发和改进,每个模块所特有的信息处理过程都被包含在模块的内部,如同一个"黑箱",但是有一个或数个通用的标准界面与系统或其他模块相互连接. 在软件的模块化开发

软件开发中的自测及C代码示例

在软件开发中,程序自测是一个永远都绕不开的话题.很多开发人员以写出有难度的代码为荣,但却不重视对自己编写的代码进行测试,这导致了最终到达客户手中的产品质量不高,bug频发,损害了公司的形象.对于一个开发人员来说,我们应该将开发和自测置于同等重要的地位,我们花在自测上的时间要不比开发少.能否对自己编写的代码进行充分的自测也是检验一个开发人员水平高低的标准之一. 自测方法 根据所编写的程序的特点,自测方法大致有如下几种: 第一种,利用模拟工具进行自测.这种方法适用于需要其他模块(尚不具备)发过来的消

基于git的软件开发中并行工程管理以及版本控制系统概要

并行工程师什么,这里就不再解释(不懂请百度),实际上,在软件开发过程中,涉及到多人合作的以项目小组形式完成开发的软件(这里指广义上)或多或少都使用了并行工程的概念,在正式的项目开发中,项目小组成员总是分工合作每人完成一部分,然后再合并起来,而且,在实际应用中,尽管使用的是瀑布模型完成开发,但总是所有项目小组成员同时开始完成自己的部分,这,其实已经是并行工程了,我们可以自豪的宣布:我们在开发过程中使用了并行 工程这种高大上的玩意来提高开发速度,所以,老板你得给我们涨工资! 很简单吧,看起来好简单的

软件开发中的流程图

在软件开发中必须经历五个阶段,当然这仅是我个人的看法,我只是个初学者,步骤如下: 1.需求分析 2.算法设计极其分析 3.编写代码 4.测试代码 5.软件维护 对于初学者来说,第5步,可以暂时不用管,当然我们的需要任务就是学好第一步,需求分析,有时候一个软件的开发花费的大量时间并不在于编写代码上,而真正花费时间的是第一步,我们软件开发人员开发的软件并不是为了我们,而是为了客户,因此我们要想开发一个成功的软件,了解客户的需求是非常必须的,客户并不是真正的开发人员,他们的要求没有编程人员的想法严密,

软件开发中 常见英文文档 缩写(转)

软件开发中常见英文缩写和各类软件开发文档的英文缩写: 英文简写 文档名称 MRD market requirement document (市场需求文档) PRD product requirement document (产品需求文档) SOW 工作任务说明书 PHB Process Handbook (项目过程手册) EST Estimation Sheet (估计记录) PPL Project Plan (项目计划) CMP Software Management Plan( 配置管理计划

Atitit 软件开发中 瓦哈比派的核心含义以及修行方法以及对我们生活与工作中的指导意义

Atitit 软件开发中 瓦哈比派的核心含义以及修行方法以及对我们生活与工作中的指导意义 首先我们指明,任何一种行动以及教派修行方法都有他的多元化,只看到某一方面,就不能很好的评估利弊,适不适合自己使用,犹如盲人摸象,虽然都对,但是并不完整 1. 瓦哈比教派的核心思想1 1.1. 归一化,反对多神..反对邪教与不良的 修炼方式1 1.2. 规范化,标准化最佳实践 圣训立国,依法治国1 1.3. 主张整肃社会风尚,净化人们的"心灵1 1.4. 倡导团结,团队建设1 1.5. 回归传统,轻量化1 2