微信号:infoqchina

介绍:有内容的技术社区媒体

技术本身是科学,不只是谋生工具,架构也是如此丨还有送书彩蛋哟!

2017-05-16 08:01 周明耀
写在前面

看到 InfoQ 宣传这本叫《聊聊架构》的书,自己买了一本,同为书作者,我理解写书人的辛苦,买本书以表支持。我每年会从国内外买很多书,其中相当一部分不会最终留在我的书架里(我可没有很多钱买 10 套房子存书),而这本书,一直会有它的位置。写这篇文章,纯粹是出于对于技术的热爱,对技术人员的尊重,对计算机科学的膜拜,不是替人站台。我们今天只谈书、谈架构、谈软件,不谈人。

认识架构

作者花了十一章(第一章至第十一章)讲述这个话题。从生命周期的拆分开始讲起,谈到了生命周期和时间的关系,谈到了人类活动的分工安排,谈到了自然界万千架构场景,也谈到了永恒的对比“建筑架构 VS 软件架构”。

这一部分,有过架构经验、深度思考的人会有所碰撞,正如作者所说:

「一个生命周期里面的活动可以进行拆分,拆分的原则就是形成若干个新的生命周期,每个新的生命周期都有自己的主体。在把一个大的生命周期拆分为多个小的生命周期后,核心生命周期活动的执行都严格地在时间上连续。而非核心生命周期的管理,则围绕着核心生命周期形成了一个树状结构。随着大的生命周期的拆分,树在逐渐地长大。」

我:作者这十一个章节,其实我考虑了十几年,一直没有想好怎么抽象出来。坦白说,作者“浪费”了这么多的纸张,写了这些与技术看似无关的文字,会让很多人觉得虚,对于写书的人来说,这是需要担忧的。既然作者敢于突破,本文中我也不会避讳自己的看法,我会亮出犀利的一面。我觉得,这一部分内容是需要的,尤其在当下这个缺少精神概念的时代。

我认为,无论计算机技术或是软件技术,本身都是科学,不仅仅是谋生手段。既然是科学,必然存在着与其他学科的交叉。当前持不同意见者,可能十年、二十年后,当你们有时间停下来静静思考,不必再忙于奔波赚钱,会有所感悟。正如我微信里一篇文章的读者留言所说“看一帮 50 多岁的俄罗斯程序员写代码,像在看小说”,这是艺术,不是对框架的简单堆叠。

软件架构

作者:软件的目的是把现实生活模拟到计算机中,并且软件是需要在计算机的硬件中运行起来的。要做到这一点需要解决两个问题,分别是业务的问题、计算机的问题。

我:是的。技术管理人所需要具备的能力第一条就是,需要能够做到技术的业务派、业务的技术派,需要能够真正理解业务,为业务部门解决问题,这样你的技术才会在业务部门眼中具有价值,才会持续投入。而对于计算机的问题,我们在开发过程中需要对过程进行拆解,按照软件开发生命周期和软件运行生命周期,这两个周期分别进行管理,不能出现生命周期中某些子生命周期颠倒的情况,例如先编码,后设计或压根没有设计,这实质是软件开发的最大痛点。

作者:软件架构就是通过软件生命周期的拆分,在符合业务架构的前提下,以达到软件本身访问增长目的的方式。这个增长需要软件开发的增长,也需要软件运行的增长,由此达到所支撑业务的增长。

我:电子工业出版社董英老师前不久给我寄送了阿里最新出版的“双十一”技术书,里面有一段谈到了天猫供应商对于阿里技术的要求,大体是“我们不求技术突破,但求系统稳定,因为你们不稳定,我们提前备货的手段就可能造成破产、失业,求求你们了”。没有实质业务的支撑,没有对生命周期的合理拆分、管理,谈不上后续发展。

作者:很多公司设了软件架构师的职位,主要职责是做出架构设计,也具备一定的影响力,但并不具备调动组织架构的权利。这样的职位往往达不到架构师的效果,有时候还会起反作用。软件架构师必须是一个组织的领导人,有权利调动这个组织的架构,才能够更好地发挥架构师的作用,才能够把软件开发生命周期、软件运行生命周期和业务生命周期的拆分落实执行。软件开发团队的组织领导人其实都是架构师,只是没有这个头衔而已,真正的架构师不一定具备架构师的头衔。一个好的领导,就是一个很好的架构师。在这个架构师的领导下,这个组织一定是健康向上的。

我:我认同作者对于组织领导需要是架构师的观点。一个开发团队的领导,如果你不能在架构方面给出意见,那你就不能在整个设计环节给出自己的观点或者对于团队的指导,你也就会在整个软件开发流程中脱节,进而丢失自己的技术领导力,也就做不成技术管理者。对于一名优秀的技术管理者,技术在前,管理在后,并不是说两者有太大的轻重差异,而是你需要花费 70% 的时间在技术上,只能花 30% 的时间在管理上,但是你需要用这 30% 的时间做完 100% 的管理工作,技术、管理,一样都不能差,架构能力,也是一样。

另一个观点是作者没有提到的,我认为架构师可以由专门的个人或者团队组成,他们承担新技术、框架的调研工作,负责对用户提出的需求进行评估,采用新的技术做出产品原型、技术调研报告,供产品部门在技术选型和技术架构选型时作为参考,这也可以体现架构师的水平和贡献。

作者:技术本身是没有好坏的。比如最早的计算机软件是单机运行的,逐渐发生了架构拆分,形成了 C/S 的架构。随着互联网技术的发展,变成了 B/S。其实是换汤不换药,Browser 还是一个 Client。但是因为 Browser 的普适性,其实就是又做了一个架构拆分,成了一个通用的 Client,做到了很多 C/S 时代做不到的事情。互联网时代的技术人员对 C/S 架构鄙视得一塌糊涂。到了 App 时代,又回到了 C/S 时代的做法,因为 HTML5 响应慢,无法适应手机客户端。所以说,随着人们问题的不断变化,会有不同的技术周期的出现,会有不同的技术周期出现,技术有自己的生命周期。没有永远最好的技术,也没有永远最差的技术,而问题总是在不断发生变化的,对于这一点,架构师要有清醒的认识。

我:其实我不太喜欢面试培训班出来的技术人员,他们可以滔滔不绝地和你描述各种框架的使用,细微到某一个参数,每遇到这种场景,我真想用英语说“I don’t care”。并不是有偏见,而是我真的不在乎你懂不懂参数的配置,我要问的是计算机科学基础知识,聊算法、聊数据结构、聊设计模式、聊你参与过的系统架构设计、聊内存管理机制和垃圾回收机制、聊你对于技术的情怀。框架的选择,实质上是对于技术可行性的选择,这又需要符合当前的业务形态,所以,正如作者所说,没有哪一个技术或者框架是最好的,只有最适合你的产品需求的,才是最好的。

作者:对于开源者来说,开源是把自己的理念介绍给外部的一个手段,和写一本书是一样的。区别之处在于,写一本书是在读者大脑里运行的,而代码是在计算机中运行的。相同之处在于,要想让代码在计算机里运行好,读者仍然需要理解作者遇到困难时,为何这样思考,找到作者解决问题的独特思路。也就是说,代码最终还是要和书一样在读者的大脑里运行起来,才能够把代码所产生的软件运用好。

我:认同作者观点。很多公司都在内部讨论是否应该开源,看看 Google 就知道你的答案了,人家一天到晚在开源,依然保持引领全世界的技术发展,并没有被看懂开源代码的对手超越。这里作者提到了写书,同为作者,我知道其实写书不能赚多少钱,但是我有一个梦想,这一生出版超过 60 本书,一本一本脚踏实地写起来,梦想还是要有的,万一实现了呢。

作者:很多软件工程师学了大量的算法和计算机基础,然而在工作中发现派不上用场。这是非常正常的,因为这些内容是为了在科学领域做研究准备的。而在业务领域,大多是如何把现有的业务在软件中模拟出来的问题,并没有太多高深的数学问题。并且现在的计算机硬件,比如 CPU、内存、存储等都非常便宜,也不需要斤斤计较地去扣时间和空间复杂度。这些都导致所学不能致用。反而如何能够高效地把业务用软件表达出来,并能够随着业务的增长,让软件也快速地长大,则变成了一个更重要的问题。这一点可能是当前计算机软件教育需要思考的问题。

我:Absolutely。

作者:单元指的是代码调用的最小单位,实际上指的是一个功能块或者方法。所以单元测试指的就是对这些代码调用单元的测试。单元测试是一种白盒测试,相对而言,集成测试基本都是黑盒测试。有人会问,如果方法就是单元,一个软件包含那么多方法,那单元测试会成倍数增加程序员工作量,这个问题确实存在,但是有了单元测试,每天能够看到自己的单元测试运行结果全部是绿色,或者正在逐渐把红色的变成绿色,心理的成就感是非常强的。由于形成了代码编写的反馈环,所写的每个代码都能够快速的从单元测试中看到变化,软件工程师会对写代码保持极大的兴趣,每天都能够有强大的动力去修改代码,而且心理也会感到更安全。在与人沟通时,心里也会更有底气。

我:作者对于单元测试这一章节的描述,采用的篇幅较大,解释较为完整了。我认同作者的判断。单元测试需要对单元的代码细节很清楚才能做好,单元测试的代码编写和执行也是需要由开发人员自己完成。集成测试主要由测试人员根据软件的功能手册进行测试,需要有专门的测试环境、测试数据配合。判断一个方式是否天生是可单元测试的办法是,看这个方法能否用一个 main 函数直接运行,如果可以的话就是可单元测试的代码。

另外一种办法就是该方法单元的参数,是否可以自由模拟,而不需要依赖外部环境。如果代码里有逻辑,不可以单元测试的话,我们是需要做代码改造的。改造的办法是把代码的执行顺序,就是单元的执行生命周期,做架构的拆分。有人说开发团队不应该配测试人员,应该给开发人员设置 KPI,写的代码直接上生产环境,出了问题就扣奖金,这是屁股决定脑袋的想法,制定规则的人一定没有写过代码或者不是真正搞技术的人。

软件架构的应用

这一部分作者以企业的交易业务为例,探讨了企业软件中的业务架构和软件架构,以及应该如何思考和应用业务架构的软件架构。在这一部分,作者分别对交易、产品、用户、订单、交易系统、事务,这些最容易落地和体现业务架构价值的领域进行了解释,这一切都需要你对于实际项目或产品的了解,才能够更好地理解作者的语言。

企业通过对生产的生命周期分工,雇佣员工,组织他们并行工作,可以得到更大的产能,这就是企业的组织架构。前几天有网友问我如何处理绩效不好的员工,我的想法是毕竟企业投入资金是需要有产出的,而个人绩效不好会最终影响到整个团队的绩效,所以需要做出相应的判断。当然,首先要正确地评估员工的能力,是否使用不当、是否他有其他的优点,也要综合考虑当前项目组情况,做出最有利于团队的决定。此外,作为技术管理者,你有责任把一群不怎么好的人,带领他们成为一支优秀的团队。

我所认识的软件架构

软件技术学习到一定水平后,我们会发现软件架构是一个门槛。这个问题已经存在很久了,在软件行业,对什么是架构存在很多的争论。看看市面上讲架构的书就知道了,卖的最好的往往是对于框架堆叠后如何使用的介绍,而不是真正从核心思想解释为什么需要这样架构,因为貌似前一类书最能直接解决问题,短期内也不会出现什么问题。对我来说,SSH 或 SHS 或 HSS,本身没有区别,我所关心的是为什么会有 SSH 的出现,他们分别解决了什么问题,他们还存在哪些问题,未来可能会出现怎么样的变化。

事实上,架构在软件发明前就已经存在很久了。我们应该多向大自然、艺术界、建筑界学习架构,因为软件并不是虚无缥缈的事物,它和我们的现实生活是紧密相关的,它的实质是来源于生活,最终又通过软件服务回到生活的一个全过程实践。

企业软件架构的设计不仅仅要注重于某一个系统功能,更需要给企业一个可进化的、可持续发展的、不断创新的平台,这和国家的整体发展也是类似的,只顾经济发展指标,不管不顾任何的环境污染,甚至于某水务局副局长说“经济越发达的地区,水越黑!”,一派胡言、其心可诛,急于求成,急于靠 GDP 让自己升职,才是这些人内心的写照。

万丈高楼平地起,地基是多么重要已经不用反复重复了。我女儿学习舞蹈过程中承受了一些痛苦,但我相信,只有能够承受这些,才能够真正地学会坚持的意义。

写在最后

坦白说,《聊聊架构》这本书不适合急于求成的工程师,也不适合完全没有架构经验或者思维的读者。它不是架构领域的武林速成秘籍,不像主流架构书那样对流行框架的公式般的简单或复杂堆叠。它带来的是对于计算机科学本身的尊重、对于架构的深入理解、对于未来的思考。这本书,是本好书,适合泡杯茶,坐在西湖边,慢慢品味。

读初中时我玩乒乓球,直板快攻球风酷似萨姆索诺夫。今天读《聊聊架构》,它杂文式的叙述方式也是我所欢喜的。这本书文风貌似柔弱,但柔中有刚,这是我模仿不来的,我有我的风格,希望未来我能出一本架构书,《聊聊架构 _ 萨姆索诺夫版》。

读《聊聊架构》,迎面而来的是一阵盛夏的凉风。

作者介绍

周明耀,2004 年毕业于浙江大学,工学硕士,国外投资银行 12 年工作经验,4 年分布式系统、物联网工作经验,10 年技术团队管理经验,已提交分布式计算领域发明专利 15 项。业余时间担任 IBM 开发者论坛专家作者、InfoQ 专栏作者,九三学社社员。著有《大话 java 性能优化》、《深入理解 JVM & G1 GC》,即将出版《技术领导力—如何带领一支软件开发团队》。微信号 michael_tec。

《聊聊架构》送书福利!

自《聊聊架构》上架以来,受到了读者们的广泛好评。

为回馈读者们的喜爱,小 Q 自作主张要来了一个读者回馈的粉丝福利。

《聊聊架构》金句赏析活动

如果你是已经收到书了的老读者,摘抄下《聊聊架构》里的金句加以自己的阐释,即可参与。

如果你是还没看过本书的新用户,写下你对本书最大的期待,你对架构的理解与想象,也可参与。

点赞数最高的前 20 条精选评论,将获得由 InfoQ 送出的《聊聊架构》修订版一本。

活动截止时间:本周三 18 点

活动解释权归 InfoQ 所有。

等不及活动结束的同学,也可以扫码下单,修订版新鲜上架,京东物流急速发货!

我们渴望一个爱读书的你!

 
InfoQ 更多文章 AI的未来是Cortana?微软AI负责人沈向洋:AI当前水平、技术难点、微软AI之路及如何面对人才挑战 扎根IT圈25年,他是怎么看云计算的? Q新闻丨微软Build大会:VS for Mac发布,首日主角AI、Azure;Java 9&nb 关于架构,都有什么可以聊的? 技术漫谈:为何KPI毁了索尼,而OKR却成就了谷歌?
猜您喜欢 陈斌:探索技术领导力的最佳实践 | GTLC精华演讲 10万积分免费送啦!人人都有机会哦~ 飞跃式发展的后现代Python世界 仅180人的“屌丝公司”为什么做到年收150亿? 数据库自动运维系统