|
《代码大全》可以说是软件开发者的百科全书,这本书部关于某种语言或者技术,而更多的关注的是一种全面认识、学习软件工作的一本书。这篇文章是对《代码大选》第2章“用隐喻来更加充分的理解软件开发”的一些感想和心得。
首先,作者认为使用建造房屋项目来隐喻“构建软件项目”是接近的,比如他们都隶属于工程学科,都分为不同的阶段,都跨越N多个领域,书中的几个例子非常贴切。
1、盖房子的时候,把一堵墙推倒然后移动半尺是很昂贵的(倒不是浪费了多少钉子,而是要付给工人更多的钱),所以,一开始的时候,就要尽量把房屋设计好
2、盖房子的时候,沐浴房可以买别人的,组合橱柜也可以买别人的,不见得什么都需要自己来做,做软件时也一样,可以利用现有的程序库完成很多功能,没必要什么都自己写(当然可以借鉴下别人的沐浴房是怎么做的,所以也有必要学习一下别人的程序库)
3、盖房子的时候需要用到很多工具,推土机、起重机、卡车…写软件的时候也要用到很多工具,有些基本的工具如IDE、编辑器、调试器等要能熟练使用,但没必要对所有用到的工具都精通,你推土机开的再好,房子就肯定能建好吗?
你看,作者真的是使用非常贴切的比喻,来向一个初学者或者新人展示了软件工作中最重要的部分。
到这里,就可以展开我今天的论点,“比喻在我们的工作中非常重要的沟通手段,哪怕这个比喻本身很蠢”。
比如,我们的同事(非研发部门)总是在看到我们写的文档里提及我们使用了Java和JavaScript两门语言,然后会问我,“兄弟,这俩语言啥关系”,我在以前总是会浪费很长时间来解释,其实它俩没有任何的关系,后来,我在知乎上看到这样一个比喻:“Java和JavaScript的关系”, 用中文来比喻是“雷锋和雷峰塔的关系”,用英文来比喻是“Butter和Butterfly的关系”。完美,话题终结。
或者,忽然有一天我亲爱的老婆问我“数据库是什么?”,起因是她要参加一个信息安全的考试,我花了十几几分钟,详细跟她讲解了数据库的定义,市面上数据库的分类,常见的数据库,甚至开始分析各个数据库的应用场景。
在她的眉头越皱越紧的时候,显然开始不愿意忍受我的喋喋不休的视乎,我灵机一动跟她说“就是一个带密码的excel”。然后她开心的去刷下一道题目,还给了我一个眼神,好像是我浪费了十几分钟的时间,向她说了一些毫无重点的信息。
同理,在我买车的时候,我一直很纠结所谓“涡轮增压”是什么鬼?然后一个鬼才销售就这样对我说:“所谓涡轮,就是车屁股上有个T(turbo),说明身上装了涡轮。他的工作就是往发动机里塞进更多的空气,参与燃烧的空气越多,发动机就越有力。反正就是一句话:玩命灌空气!”完美,话题终结。
你看,这是我的第二个论点,“如果别人仅仅是想跟你挑起话题,或者满足自己的好奇心的时候,请直接使用比喻,哪怕这个比喻比较蠢”。
实际上,另外一种论点是“比喻”并没有任何的作用,“比喻”的前提是别人对这个话题有明确的需求,而专业性的东西,并不都是那么容易具象化的,你需要使用大量铺垫,才能逐渐清晰的描述出这个东西。
比如,如何为“拉普拉斯公式”找一个形象的比喻。
然后,比喻的第三个作用,就是借用明确的比喻,大幅度降低沟通的成本。比如说,你会跟你项目组中其他的同事沟通,这里我会没10秒钟发送一个广播,如果你们觉得自己的模块有用,直接用就行了。或者说,这里请用单例模式,因为设备只有一个,所以不管你们有多少模块,请确保你们对于这个设备,对象应该就只有一个。
好的,上面的是我根据《代码大全》第2章,隐喻在我们工作中发散性思考的论点,而下面,则是书中的一些论点。
一种观点认为软件项目是一种写作性的工作。但这种隐喻并不能描述多人跨领域协作的情况。
一种观点认为软件项目是一种耕耘培植的过程,嗯,就像是迭代螺旋这种开发模型,但是作者认为这种比喻不好之处在于农作物生长古城中,主要的影响参数是天气,而天气属于外界因素,这显然有问题。
一种观点认为软件项目是一种牡蛎养殖的过程,依然是一种增量开发模型,但是牡蛎孕育珍珠的不确定性,不符合软件项目管理的基本理论。
一种观点认为软件项目是一种土木工程的建造过程,这当然是目前主流的说法,实际上,我们看任何一本软件工程相关的书籍,总会在开篇就说:“软件工程是一个近代刚产生的工程体系,脱胎于有非常成熟完备体系的土木工程体系”。
作者认为,隐喻是一种可以用来作为启发的工具,是一种思考问题的手段。
以上就是《代码大全》第2章隐喻相关的论点了。
总之,隐喻或者比喻的作用就是一个“启发”,这种启发可能是对别人的,也可能是对自己。而如何适时的做出合适的比喻,却需要我们对生活的积累。
最后举个小栗子,我们在大学或者工作后,总是能够看到或者谈论那25种“设计模式”,我们写过DEMO,看过原理,甚至可以背诵默写,然而25种“设计模式”一定是通过大量的业务场景中抽象出来的,我们知道了25种设计模式,但是有多少人知道这些模式是被从哪些业务场景中抽象出来的么?如果你不知道那些相近的业务场景,你如何知道在什么时候应该使用它们呢?还是仅仅为了使用而使用? |
|