关于软件工程:构建之法现代软件工程读书笔记二

请问戴维. 帕纳斯(David Lorge Parnas 软件工程专家) 学生: 您认为未来会有什么令人兴奋的软件工程技术呈现吗？

戴维·帕纳斯: 最有用的技术不在未来，而是曾经呈现好些年了，只不过咱们没好好用。

很多学生学了一些编程语言，读了一些技术博客，个别都豪情万丈。他们做一个我的项目巴不得展示本人平生所学。

再加上前沿技术，做一个轰动的翻新。这诚然值得激励，不过实际表明，这些往往都不能胜利。

咱们来看下胜利的例子, 他们是怎么做的, 例如 Linux 刚开发的时候：

I’m doing a (free) operating system(just a hobby, won’t be big and professional like gnu) for 386(486) AT clones。

我正在为 386(486) AT clones 编写一个操作系统(只是一个业务喜好而已，没有 GNU 那么业余和宏大)。

管理学巨匠彼得·德鲁克 : Those entrepreneurs who start out with the idea that they’ll make it big – can be guaranteed failure.

那些一开始就认为本人会做大的企业家必定会失败。

前言

开始本篇的时候，我想起我的初中，我的初中是在镇上念的，一周回去一次，我总是信念满满的指定了一个指标，回家把我背的书都看一遍，而后每次我都把所有的书都背了回去。然而你晓得小孩子经常抵挡不了引诱，比方睡懒觉，玩游戏。当我睡醒的时候，我的小伙伴就来了，而后咱们就去打游戏。再上学的时候，我就把这些书在背到学校。这种重复性工作应该是继续了我的初中时代。想来那个时候，背回来的书一本没看的理由就是我制订的指标太过宏大，让我感觉很难实现，然而那个时候的我显然没有意识到这一点，每次周末，我将书桌中的书全副装进书包的时候，我都是满心欢喜，空想着本人在家里看书会让家里人开心。

我又想起我上大学的我的项目较量，我的项目组长想做一个美妆社区商城，定位上大抵相等于小红书和淘宝的结合体，介绍一下咱们过后的技术背景: Servlet、JSP、JQuery、MySQL(根本 SQL 语句的编写)，过后刚学完这些，信念爆棚。但过后有没有实现小红书加淘宝的结合体的设计指标呢! 应该是没有实现的，大抵相当于咱们的指标是建一栋楼，最初建了一个风雨飘摇的茅草屋，只等 ” 八月秋高风怒号 ”，就“卷我屋上三重茅”。

我想假使指标太过宏大，总会让人产生莫名的畏惧心理，惯例的做法就是将宏大的指标拆解为若干个看起来容易实现的小指标。

我想解决大问题诚然让人感觉美好，然而把小问题真正解决好，也不容易。

浅谈软件设计准则

人们在实践中碰到的需要是常常变动的，软件设计的许多准则是从实际而来，这些准则正是为了在一直变动的需要中保障程序的可维护性和效率。咱们以两个软件设计准则为例，第一，繁多职责准则 (Single Responsibility Principle，SRP) 指出:

一个模块 (类) 应该是只有一个导致它变动的起因，一个模块应该齐全对某个性能负责。

软件设计的经典著作《麻利软件开发：准则、模式、实际》分下上面的例子:

一个解决正方形的模块有两个性能: ① 计算面积 ② 画出这个正方形。

这个设计让一个模块负责两个不同的职责：进行几何运算（与显示图形无关）和图形界面绘出正方形。如果一个汇合计算的程序须要应用这个模块，那么它就须要同时包含图形显示的局部(因为是在同一个模块中)，这是一种节约，同时引入了不必要的依赖(因为图形显示和图形底层实现相干), 障碍了可移植性。另外，几何计算需要的扭转和图形显示需要的扭转都会导致这个模块产生的变动，减少谬误产生的危险。

另一个例子形容了一个调制解调器的 API 界面：

 Interface Modem{public void dial(String pno); // pho means port number  dial 拨号
    public void hangup();  // hangup 挂断
    public void send(char c); // send 发送
    public void recv(); // recv 接管信息}

调制解调器这个词有点生僻，然而调制解调器是 Modem 的义译名，它的音译名大家可能更为相熟—猫. Modem，其实是 Modulator（调制器）与 Demodulator(解调器)的合成词。调制是将数字信号转成模拟信号，解调是将模拟信号转成数字信号。

我在看到这个例子的时候，将 Interface 了解为接口了，我在写的时候，还在后面加上了 public，如果是接口中的话，上下文就不通顺，因为下面说的是 ” 形容了一个调制解调器的 API 界面 ”，Modem 是调制解调器的意思，Interface 如是了解为接口的，那么这说不通。

所以 ” 调制解调器的 API 界面 ” 应该是这么了解的，Interface 是界面，Modem 是调制解调器。花括号中的是 API(Application Programing Interface). 接着又说道:

这个界面做了两类严密相干的事件，连贯治理 (dial,hangup) 和数据通信(send,recv), 他们是两类职责，还是一类?

论断是: 依据具体情况剖析，要看需要的变动是否导致这些操作同时变动。

后半局部讲的，我的了解是这个繁多职责没有广泛的断定准则，要依据需要来去断定。那 ” 这个界面做了两类严密相干的事件 ” 该怎么了解呢？我了解的界面是上面这样:

然而下面不是讲的是模块吗？这怎么又讲到界面了呢？“ 这个界面做了两类密切相关的事件 ”，该怎么了解这句话？

我翻阅了《麻利软件开发: 准则、模式与实际》, 发现我可能适度了解了，这是《构建之法—古代软件工程》作者的笔误，下面的那个 Modem 的例子在《麻利软件开发: 准则、模式与实际》就是 Java 中的接口。

那么连贯治理和数据通信应该算两种职责，还是算一种？换种说法，拿吃饭这件事来说，操纵筷子和将食物放到嘴里，从吃饭的角度来说，这两类严密相干的事件应该是划分到一个模块中。这种天经地义的划分来源于咱们对吃饭这件事的精确了解，然而对于其余方向的需要呢？仿佛没有相对的说法，要依据具体情况剖析，要看需要的变动是否总是导致这些操作同时变动。

写到这里忽然想起微服务，起初的软件比较简单，代码量比拟少，业务比较简单，用户量比拟少，所以起初的软件大多前后端一体。随着硬件的疾速倒退，互联网的一直遍及，软件逐渐的再向简单的凑近的同时，代码量也在一直的收缩，软件开发实现又不是一锤子买卖，不像房子卖出去之后，跟开发商就关系不大了。软件开发之后还要思考保护，这一方面软件的开发建设很像是城市建设，如果城市建设涌入了大量的人口，许多人认为这里在这里可能赚到钱，城市的执政者就会着手对城市进行扩建以适应以后城市的倒退。也像是社会的倒退，过来的封建社会的县令类比到当初的话是无奈类比的，过来的县令身上汇合了很多职位，这兴许跟过来县的人口比拟少有关系，随着人类社会的不断进步，原先集中在县令身上的职位被合成。这也就是对应到了微服务架构上，咱们将本来集中在一个服务的利用进行拆解，将其拆解为若干个微服务，每个服务贯彻繁多职责，对外提供的服务尽量不存在反复，这也就印证了本文结尾援用的戴维. 帕纳斯那句话:

最又用的技术不再未来，而是曾经呈现好些年了，只不过咱们没有好好用。

我想起刚学 Spring Boot 的我，我是在 B 站看的颜群老师的视频: SpringBoot 视频教程（入门篇)), 在视频的结尾就讲到了微服务，说这是目前风行的软件架构，我过后还颇感到离奇，兴许是过后并没有开发过大一点的工程，开发过的工程代码量都比拟少。过后的想法是微服务架构比拟适宜大型项目，便于扩容和保护，然而这几年微服务仿佛正在成为一种新常态，当初的论断还是正确的吗？以我目前的认识是，微服务架构正在下沉，目前业界是看重微服务架构的扩容和易保护吗？仿佛并不全是，我集体的认识是看重服务的重用能力，比方认证服务，开发一次，再次开发新我的项目的时候就不用再开发了，重用之前的服务就好。

这种繁多职责也能够从 Web 软件工程师的分工能够一见端倪，咱们晓得许多计算机的硬件能力大抵以每两年进步一倍的速度倒退。然而软件开发的流程却没有这样的提速过程，开发成本也没有降落，本来前端、后端、运维、DBA 集一体的 Web 工程师被拆成四个职业:

• 前端工程师
• 后端工程师(也有称之为后端工程师)

• 运维

  以后的 Web 开发畛域，DevOps 非常风行，DevOps 是一个合成词，是 Developers(开发者)和 Operators 的联合，即开发和运维团队一体化。本来从后端仔身上划走的运维，又从新回到了后端仔身上。

• DBA

这是一种拿着锤子看全世界都是钉子的想法吗？仿佛是，又仿佛不是。拆分与分工再人类世界能够随处见到，当你开始守业，起初只是小买卖，你大能够不用请会计注册公司，就像农村的小饭店一样，你能够是老板也能够是厨师，同时还能够是服务员和会计、保洁。然而你没想到你的厨艺很不错，好吃不贵，价格实惠，很快你的饭店就吸引了很多人来，缓缓的你发现，一人身兼多职让你撑持不住，人切实太多了，为了不让你父母受累，你开始招人，将你身上的保洁和服务员的职责调配进来，你依然不想请会计，你感觉的你的生意还没有那么大，慢慢的你发现一个厨子仿佛有点支撑不了以后的用户量，你每天依然被累的半死，于是你开始推敲着请厨子、招学徒，让他们负责炒菜，你负责进菜，然而仿佛还是要招洗菜的，让厨子洗菜又做菜，厨子不看堪重负，厨子提出了抗议。

于是你开始招洗菜的，很快你就想开分店，你想扩充你生意的规模，然而每天的帐让你有点头疼，你不想将本人的精力太过集中在算账上。所以你请了个账房，这个故事还会倒退上来，你会请更多的人，来承接你身上的工作，然而你在调配工作的时候，两个人之间的工作会尽量不呈现重合，你不会想让一个人既做厨子又做账房，你心愿这个人尽可能的业余。

另一个重要的软件设计准则时凋谢—关闭准则(Open-Closed Principle,OCP)

软件实体应该是能够扩大的，同时是不可批改的。

具体的说:

• 容许扩大(Open for extension)。当利用的需要产生扭转时，咱们能够对模块进行扩大，从而扭转模块的性能
• 不容许批改(Closed for modification)。对模块行为进行扩大时，不用扭转的自身

那什么时候该应用这些准则呢?《麻利软件开发: 准则、模式与实际》一书也同时指出:

变动的轴线仅当变动理论产生时才具备真正的意义。如果没有征兆，那么去利用 SRP，或者其余准则都是不明智的。

遵循 OCP 的代价也是低廉的 ….., 显然，咱们心愿把 OCP 的利用限定在可能会产生的变动上。…… 最终，咱们会始终等到变动产生时才采取行动。

我的了解是这些准则应答的是变动，开发者依据本人的教训进行了预测认为这里会发生变化，这须要设计人员具备一些从教训中取得的预测能力，有教训的设计人员心愿本人对用户和利用很了解，可能以此来判断各种变动的可能性。而后，他能够设计对于最有可能产生的变动遵循 OCP 准则。

要预测精确这一点很不容易做到，因为它意味着要依据教训猜想那些应用程序在成长历程中有可能蒙受的变动。如果开发人员猜想正确，他们就获得成功。如果他们猜想谬误，他们会蒙受失败。并且在大多数状况下，他们都会猜想谬误。

咱们该如何遵循 OCP 呢？咱们来看上面一个例子，以这个例子来阐明 OCP:

这个例子同样来源于《麻利软件开发: 准则、模式与实际》，书上用的是 C ++ 来形容 OCP，这里我改装成了 Java。咱们能够很容易的看出，如果咱们再减少一种形态，Shape 类中的 drawAllShapes 办法不必改变，就能画出新的形态。图中打印能够了解为绘制对应图形的行为。

这种设计是合乎 OCP 的，无需改变本来的代码，咱们就实现了扩大，还不会引发连锁改变。这让我想起了工厂模式，不懂什么是工厂模式的，能够参看我的文章: 欢迎光临 Spring 时代 - 绪论](https://juejin.cn/post/692755…

假如再减少了一种 Excel 类型，这个 WorkBookFactory 还须要改变，我想并不能这么说，我想是 POI 的开发者认为 Excel 的变动不会那么强吧，不会每年都减少一种文件格式，这来源于 POI 的设计者对 Excel 的理解，这是一种预测，同时也是在缩小开发者应用 POI 的心智累赘，适度的设计导致软件趋于简单，减少保护和应用老本。

下面的 Shape 是完满的合乎开闭准则的吗？仿佛并不全是，咱们齐全能够提出一个需要，让 drawAllShapes 办法不得不批改，《麻利软件开发: 准则、模式与实际》给出的变动是要求所有的圆必须在正方形之前绘制，在这种状况下，DrawAllShapes 仿佛无奈不对这种变动做到关闭，如果你说你能够在传入 List 参数的时候，将圆放入正方形之前，不就能够了吗？那我这里就再提出一个需要，要求将正方形和圆形绘制在一起。除非你是穿梭过去的，那么总有你没有预测到的状况，无论模块你做的是如许的 ” 关闭 ”，都会存在一些无奈对之关闭的变动，没有一种模型能够应答所有的变动。

既然无奈做到相对关闭，那么就必须做到有策略地看待这个问题。也就是说，设计人员必须对于他设计的模块应该对那种变动做出抉择。

开发者必须先猜测出哪种变动是最有可能的，而后结构形象来隔离那些变动。

这让我想起了设计模式，大家认为这个很有用，国内的面试也很看重，这在某种程度上导致了设计模式的滥用，开发者在未对具体的业务比拟相熟之前，就开始开展了预测，开始利用设计模式，这很容易造成我的项目种的设计模式满天飞，我想起我前公司的资深架构师对我说的话，那天他看见我在看设计模式，便对我说，对于我这种水平的人来说，设计模式无助于我代码功力的晋升，他这么多年的开发，也没用过几次。

总结一下

对业务要相熟，这能够让你洞悉变动，预测变动，构建形象应答变动，能够防止改变产生连锁反应，你总不心愿，之前开发实现的货色，再改一遍 Bug 吧。对于开闭准则我之前的了解是，如果这个局部的代码曾经上线安稳运行了，那么就尽可能的不要去改变他，那么这里又补充了 一下开闭准则，即依据教训预测变动，而后构建形象，应答变动。然而该当审慎的引入，这回减少浏览老本和保护老本，然而我经常收到的反驳意见是，我引入又不会出什么事，又怎么啦。

繁多职责我之前的了解是不便重用，如果一个办法实现了 A 和 B 这两件事，我假如因为某种须要须要用到 A，不须要用到 B，那么这个办法我就永不了，同时也让浏览变得简略，其实我当初的想法是能够涵盖在变动中，我预测未来我会用到 A，我做出的应答策略是将办法做的尽量效一点。

打算与预计

当你可能度量你所说的，并且可能用数字表白它时，就示意你理解它，若你不能度量它，不能用数字去表白它，那阐明你的常识时匮乏的、不能令人满意的。—开尔文勋爵(英国物理学家)

做我的项目是会有工期的，经常会让开发者去预计工时，这是让我颇为头疼的一个问题，我项目经理让我预计的时候，我的脑袋是一片空白，我过后的想法是这要预计少了要加班，预计多了项目经理又不称心，于是我就求教过后公司中的前辈，我把我的放心如实说了，前辈示意没事，工夫不够再要。然而我还是想预计一下，我想对本人的开发能有一个掂量。

“ 预计 ” 这一技术看似容易，其实大有学识，当约翰·巴克斯启动 FORTRAN 我的项目后，他的下属会定期询问实现日期，他总是给出同样的回答:” 六个月 ”。但实际上，我的项目一共花了近三年的工夫。

再开始预计之前，咱们须要弄清楚几个概念：指标、预计和信心。独自拎进去这三个词，咱们是不会混同的，然而在理论利用中，咱们却很容易混同这三个词。

• 指标: 表明一个心愿达到的状态。比方你心愿追上一个女孩子，但你应该分明这是一个指标，不肯定能实现。

• 预计: 以以后理解的状况和把握的资源，要花费多少人力物力实际能力实现某事。

  留神前半句以以后理解的状况和把握的资源，我想起我上初中的时候，比拟喜爱看网络小说，印象很深的一部小说是《斗破天穹》，吞噬异火的把握，这也是一种预计。我过后很想学会这种预计，比方咱们上初中的时候，有一次是初中周四放假了，

  下周我就满怀冀望的也心愿周四也放假，我过后的预计是过后的天气，就像模像样的预计了一个八成概率。然而最初还是没有放假。

• 信心: 保障某个工夫之前实现预先规定的性能和品质。如果下的信心没有做好预计，那么大概率是实现不了的。

这种状况在软件我的项目中也能够看到，软件我的项目中的提早更是亘古未有—为什么咱们预计得不准呢？因为难么？为什么软件预计这么难呢? 其实所有的预计都难，如果你只是瞎预计，没有找出预计前面的假如的话。不信的话，咱们做一些预计的练习，不必搜索引擎，你预计一下上面的数目(数量级正确就行)

• 中国的海洋边界长度
• 非洲人口密度
• 长江一年的流量
• 2013 年亚洲货币流通的总量

怎么样？你的预计和理论状况差几个数量级? 然而如果你把你做出预计的根据，也就是假如列出来，那这是不是会让你对本人的判断更加自信呢。软件工程专家 Paul Rook 说: 咱们其实并不是不会预计，咱们真正不会的，是把预计前面藏着的假如全副列举进去。咱们平时的预计还有一个维度就是参考前人的教训。软件工程师在长期的实际中，也摸索出一套教训公式：理论工夫破费次要取决于两个因素—对某件事的预计工夫 X，以及他做过相似开发的次数 N。

Y = X ± X ➗N // Y 是理论工夫破费、两头的±示意加上或减去。

例如刚毕业的你被分派到了一个用户治理模块的工作，你预计须要三天，然而你素来没有做过用户治理模块，所以 N 就是 0，高中数学通知咱们，0 不能当除数，然而大学数学通知咱们极限状况下就能够，所以你破费的工夫是 3 + 无穷大？也就是说在我的项目给定的工夫内根本无法实现，或者是 3 - 无穷大？岂但没有实现工作，还写了很多 bug 来，让团队花更多的工夫来解决，把我的项目拖垮。

留神这是个教训公式，所以跟理论破费工夫存在误差是十分失常的事件，这也就须要你在实现需要之后，剖析起因，以便缩小误差，如果始终做雷同的我的项目，估计值会越来越精确，因为越来越纯熟。然而也不会有人始终违心做反复的是事件，这会让人厌倦。

写在最初

写到最初的时候忽然感觉本文不齐全像是《构建之法—古代软件工程》的读书笔记了，在写软件设计准则的时候，参考了一下《麻利软件开发: 准则、模式与实际》，这在《构建之法—古代软件工程》种只花了两页来介绍，然而次要内容还是来自于它，也糅合了本人的若干感悟，心愿会对诸君有所帮忙。封面是在海南度假的时候，他人拍的，感觉很漂亮。

参考资料

• 《构建之法—古代软件工程》第三版 邹欣著
• 调制解调器的性能是实现
• 为什么大厂肯定要用 DevOps？
• 【译文】聊聊凋谢关闭准则 (Open/Closed Principle))
• 《麻利软件开发: 准则、模式与实际》Robert C. Martin 著