![](https://img-blog.csdnimg.cn/20201014180756930.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
软件架构
ascetictor
简单,自信,不沾因果,不求名利。
展开
-
清汤的重要启示
作者:埃本·休伊特(EbenHewitt)清汤(consomme)(译注1)是一种非常清澈的的肉汤,通常以牛肉或小牛肉烹制而成,极其鲜美精妙。上品清汤非常清澈。烹制清汤公认颇具挑战性,而且耗时长久,因为要去除会弄浑清汤的脂肪和其他固态物,获得绝对澄澈之上品,只有一个方法:依靠简单的、不断重复的精炼浓缩。一遍又一遍地浓缩,精益求精,最终烹出上品美味。品尝清汤,就仿佛在吸啜精华。事实上,这正是此道原创 2015-08-13 23:13:09 · 373 阅读 · 0 评论 -
现在走捷径,将来付利息
作者:斯科特·麦克菲(ScotMcphee)长远看来,系统维护将比项目初期的开发消耗更多的资源。进行系统架构设计时,牢记这点非常重要。在项目开发初期走捷径,可能会以日后付出高昂的维护费用为代价。例如,你可能觉得单元测试并不直接产生价值,于是就让开发人员跳过这些严格的测试工作。这将导致所交付的系统在未来更难修改,而且在修改时信息不足。即使只做了一些修改,也需要对系统做出大量的手动测试,这将导原创 2015-08-30 10:39:31 · 382 阅读 · 0 评论 -
一切软件系统都是遗留系统
作者:戴夫·安德森(DaveAnderson)即使系统十分前沿,采用了最新的技术开发而成,但对接手它的下一个人而言,它也会是遗留系统。必须应对这种情况!在今天,软件很快便会过时,这己经成为软件的天然属性。如果系统能够作为产品存活下来,哪怕只是数月时间,都必须承认一点:负责维护工作的开发人员肯定要对软件进行缺陷修复,这是不可避免的,这引出如下几个问题。清晰性(clarity):各个组原创 2015-08-29 15:33:36 · 2054 阅读 · 0 评论 -
故障终究会发生
作者:迈克尔·尼加德(MichaelNygard)硬件会出错,于是我们增加冗余资源来增加系统的可靠性。这样做虽然可以避免由于单点故障引起的系统错误,但同时也增加了至少一台设备出错的概率。软件会出错,由软件构成的应用程序自然也会出错,于是我们增加额外的监控程序,好在应用失效时报警,但是监控程序也是软件,一样会出错。人无完人,我们也会犯错,所以我们把操作、诊断和处理都变成自动化。可是自动化原创 2015-08-15 12:42:01 · 501 阅读 · 0 评论 -
偿还技术债务
作者:伯克哈特·赫夫纳盖尔对任何己投入实用的项目(也就是说,有客户在使用其产品),无论要修复缺陷,还是要添加新功能,总是必须修改产品的时候。在那点上,会面临两个可能选择:花合适时间“一次做对”或者取巧走“捷径(shortcut)”,争取尽快推出修改后的产品。一般来说,业务相关人员(销售/市场部门和客户)希望这些修改越快越好,而开发人员和测试人员更期望能够花合适时间进行设计,实现和测试后,再原创 2015-08-12 09:53:53 · 480 阅读 · 0 评论 -
我们常常忽略了自己在谈判
作者:迈克尔·尼加德(Michael Nygard)我们都面临过消减预算的要求,如果资金运转捉襟见肘,技术方案只能委典求全。比如下面的情景:“我们真的需要这东西吗?”项目投资人发难道。要知道“这东西”可能是系统运行必不可少的条件,比如:软件许可证、冗余服务器、离站备份系统,甚至供电设备,更可气的是,投资人总是一副教训的口吻,仿佛只有他懂得钱要花在刀刃上,我们都是毛头小子,就会浪费钱买漫原创 2015-08-15 13:27:56 · 411 阅读 · 0 评论 -
不存在放之四海皆准的解决方案
作者:兰迪·斯塔福特(RandyStafford)架构师应该坚持培训“情境意识”(contextual sense)——因为我们遇到地问题千差万别,不存在放之四海皆准的解决方案。“情境意识”这个贴切的说法,最早由埃贝哈特·雷克廷(EberhardtRechtin)在《Systems Architecting:Creating & Building Complex Systems》(Pren原创 2015-08-15 20:17:19 · 1090 阅读 · 0 评论 -
架构设计要平衡兼顾多方需求
作者:兰迪·斯塔福德(RandyStafford)平衡兼顾各方的要求和项目的技术需求Balance Stakeholders' Interests withTechnical Requirements提到软件架构,我们脑海里首先浮现的是传统的技术工作,比如系统建模、定义接口、划分功能模块,套用模式,以及性能优化等。此外架构师还要考虑系统的安全性、易用性(usability)、产原创 2015-08-16 09:29:23 · 665 阅读 · 0 评论 -
草率提交任务是不负责任地行为
作者:尼克拉斯·尼尔森(NiclasNilsson)傍晚时候,团队正忙于完成本次迭代的收尾工作,一切按部就班、有条不紊。只有约翰赶着赴约有些急躁,他仓促写完自己的代码,编译、检入、然后匆匆离开。几分种后红灯亮起,构建失败。约翰没来得及执行自动测试就草率地提交了任务,连累大家无法继续工作。正常的工作秩序打乱了。大家清楚,如果现在从版本控制系统中获取更新,得到的将是有缺陷的代码,产品演示迫在眉睫,原创 2015-08-16 10:17:09 · 422 阅读 · 0 评论 -
持续集成
作者:大卫·巴特利(David Bartlert)构建应用程序作为重大项目事件的日子己经一去不复返了。架构师(无论是应用架构师还是企业架构师)都应该在项目中鼓励推广持续集成的方法和工具。持续集成的说法最早是由马丁·福勒(MartinFowler)在设计模式中提出来的。它指一套频繁对应用程序进行自动化测试和构建的实践方法,以及确保测试和构建自动执行的相关工具。持续集成通常在一台专门配置的集成原创 2015-08-16 17:51:34 · 523 阅读 · 0 评论 -
取舍的艺术
作者:马克·理查兹(MarkRichards)架构师应该明白鱼和熊掌不可兼得的道理。世上不存在十全十美的设计——既具有高性能,又具有高可用性;既高度安全,又高度抽象。有一个真实的历史事件,软件架构师应该烂熟于心,在与客户或同事沟通时能派上用场。这就是瓦萨号(Vasa)战舰的故事。17世纪20年代,瑞典和波兰之间爆发战争。瑞典国王迫于战争经费的压力,急欲速战速决,他下令建造一艘名为瓦萨号的战原创 2015-08-17 11:29:16 · 336 阅读 · 0 评论 -
关键问题可能不是出在技术上
作者:马克·兰姆(Mark Ramm)简单的项目(比如工资管理系统)也会翻船,而且这不是个别情况。为什以?难道是因为我们用错了技术了吗?因为错选了Ruby而不是Jave,错选了Python而不是Smalltalk?或者选择了Postgres而不是Oracle?还是本该用Linux时,错选了Windows?一旦项目失败,技术往往沦为替罪羊。但是有多少问题真的是Java无法胜任的呢,这种可能性原创 2015-08-15 07:57:36 · 395 阅读 · 0 评论 -
量化需求
作者:基思·布雷思韦特(KeithBraithwaite)“速度快”不能算作需求,“响应灵敏”和“可扩展”也不能算需求,因为我们无法客观的判断是否满足了这样的条件。但是这些又确实是用户想要的。架构师的工作在很大程度上是平衡这些需求之间的不可避免的冲突和矛盾,同时又使系统尽可能的满足他们。如果缺乏客观的规律,架构师就只能任凭挑剔的用户和偏执的程序员摆布(“还不够快,我拒绝接受”和“还不够快,我不原创 2015-08-15 17:43:49 · 1969 阅读 · 0 评论 -
你不能不了解硬件
作者:卡迈尔·威克拉玛纳亚克(KamalWickramamayake)对于许多软件架构师,硬件容量规划问题是一个超出其舒适区的主题,但它的确是架构师工作的重要组成部分。软件架构师常常无法正确考虑硬件因素,有多种原因,但大多和缺乏对硬件的了解及需求不清楚脱不了干系。之所以忽视对硬件的考虑,其首要原因是,架构师把全部精力都花在软件上,所以往往就忽略了硬件上的要求了。除此之外,由于使用高级语言和原创 2015-08-30 10:15:55 · 442 阅读 · 0 评论 -
理解变化的影响
作者:道格·克劳福德(DougGrawford)好的架构师能够将复杂性降低到最低限度,他在解决方案中给出的抽象,应该能够为更高的层次提供坚实基础,同时,还应该能足够务实地应付未来的变化。优秀的架构师能够深刻理解变化带来的影响,这种影响不仅限于彼此隔离的软件模块之间,而且包括人与人之间,以及系统与系统之间。变化有多种不同的表现形式:功能需求的变化。可扩展性需求的演进。系统接口原创 2015-08-30 09:25:12 · 405 阅读 · 0 评论 -
以沟通为中心,坚持简明清晰的表达方式和开明的领导风格
作者:马克·理查兹(MarkRichards)软件架构师普遍喜欢坐在象牙塔里,命令开发人员执行他的命令和技术决策。这很容易引发大家的抵触情绪,造成团队不和,甚至导致产品与最初的需求相去甚远。软件架构师应该想办法提高自己的沟通技巧,帮助大家理解项目的目标。关键在于明确有效的沟通和开明的领导风格。沟通必须简明清晰。没有人愿意阅读冗长的架构决策文档,架构师言简意赅地表达观点是项目成功的必要条件。原创 2015-08-15 08:28:31 · 745 阅读 · 0 评论 -
架构决定性能
作者:兰迪·斯塔福德架构决定应用的性能,似乎是大家都明白的道理,但是事实并非如此。有些架构师认为简单地更换底层软件架构(Software infrestructure)就足以解决应用的性能问题。他们很可能轻信了“经测试产品性能超出竞争对手25%”一类的商业噱头。假设某产品完成特定操作耗时3毫秒,竞争对手需要4毫秒,这1毫秒(25%)的优势如果放到一个性能效率极底的架构里,几乎可以忽略不计。架构原创 2015-08-15 09:34:20 · 584 阅读 · 0 评论 -
客户需求重于个人简历
作者:尼廷·博万卡(Nitin Borwankar)作为工程师,我们常常要向客户推存技术、手段,甚至方法论来解决问题。但有时我们心里不是想寻求解决问题的最佳方案,而是希望借此丰富自己的简历。这样做很可能得不偿失。积累一批满意的客户,选择切合实际的技术解决他们的难题,让他们乐于推荐你,才是最好的履历。信誉远胜过时髦的编程技巧和流行的范式。掌握最新的技术趋势,与时俱进固然重要,但不能让客户为此原创 2015-08-14 11:23:22 · 353 阅读 · 0 评论 -
分析客户需求背后的意义
作者:埃纳尔·兰德雷(EinarLandre)顾客和最终用户通常提出的解决方案,只是他们心目中可行的解决方案,并不是问题唯一的解决途径。F-16“战隼”(战斗机)的设计师哈里·希拉克尔(HarryHillaker)曾就此给出过一个经典的案例。军方最初对F-16的设计需求是:飞机速度在2~2.5马赫(译注1)之间的低成本轻型战斗机。要知道飞行速度由1倍音速变为2倍音速时,空气阻力会增至原来的4倍原创 2015-08-15 10:37:55 · 5584 阅读 · 0 评论 -
确保简单问题有简单的解
作者:查德·拉·瓦因(Chad LaVigne)软件架构师解决了很多非常困难的问题,但是也会去解决一些相对容易的问题,对于简单的问题,不要使用复杂的解决方案。这个建议听上去显而易见,但是遵循却不容易。软件设计者都是聪明人,真的很聪明,但是出于炫技心理,很容易陷入“杀鸡用牛刀”的误区(simple problem-complex solution trap)。如果发现自己正在设计一个非常聪明的解原创 2015-08-29 11:25:43 · 417 阅读 · 0 评论 -
根据投资回报率(ROI)进行决策
作者:乔治·马拉米迪斯(GeorgeMalamidis)我们对项目所做的每一个决策——无论是与技术、过程,还是与人相关——都可以看作一种投资形式。投资是和成本联系在一起的,成本并非单纯只有货币一种形式。之所以进行投资,是相信它们最终能带来回报。老板发员工薪水,是期望此项投资将会对他们的事业产生积极的影响。开发团队决定遵循某种专门的开发方法学,是期望它能够给团队带来更高的生产力。选择投入一个月的原创 2015-08-29 13:37:36 · 2537 阅读 · 0 评论 -
不仅仅只控制代码,也要控制数据
作者:查德·拉·瓦因源代码控制和持续集成,是管理应用程序构建过程和部署过程的优秀工具。数据方案(schema)和数据内容通常会随着源代码的变化而变化,它们也是这一过程的重要组成部分,因此也需要对之进行类似的控制。如果构建和部署过程的详细步骤列表中包含要进行数据更新的操作时,一定要明白这点。你一定碰到过这样的过程列表,看起来大致像是下面这样的:创建脚本列表,这些脚本要按照一定次序运行原创 2015-08-12 09:06:20 · 379 阅读 · 0 评论 -
起立发言
作者:乌迪·大汉(Udi Dahan)许多架构师都是从技术岗位上成长起来的,他们擅长与机器打交道。然而架构师更需要与人打交道,无论是劝说开发人员接受具体的设计模式,还是向管理人员解释购买中间件的利弊,沟通都是达到目标的核心技能。虽然架构师对项目的影响是很难界定的,但是有一点是清楚的:无论架构师的建议多么正确,如果开发人员和管理层都不买账,架构师就无法取得事业上的成功。有经验的架构师都很重视原创 2015-08-15 11:20:55 · 422 阅读 · 0 评论 -
提前关注性能问题
作者:丽贝卡·帕森斯(RebeccaParsons)商业用户的需求主要表现为对功能的要求。系统的非功能特性则由架构师负责,包括:性能表现、灵活性、持续正常工作时间、技术支持资源等。但是,对非功能性的初始测试往往被拖到开发周期的最后阶段,有时还由开发团队来操刀,这样的错误屡见不鲜。造成这种现象的原因有很多,有人觉得在还没有实现客户要求的功能之前,考虑系统的响应速度与灵活性无异于纸上谈兵;或者原创 2015-08-16 08:49:25 · 299 阅读 · 0 评论 -
避免进度调整失误
作者:诺曼·卡诺瓦利导致项目失败的原因很多,最常见的是中途临时调整进度。要保证调整后的进度,只能靠大伙加班加点。当然,调整也可能指延长项目期限,或者增加项目资源,那就没有什么好操心的了。最怕的是时间不变,任务量增加;或者任务不变,截止日期提前。一般人有一种错误的观念,认为加快进度可以降低成本,提高交付速度。为了缩短交付时间,开发人员常常被要求加班,甚至放弃“不太重要的计划任务”(例如单元测原创 2015-08-16 23:56:22 · 302 阅读 · 0 评论 -
一行代码比五百行架构说明更有价值
作者:艾利森·兰德尔(AllisonRandal)设计拥有无穷的魅力。我们运用系统的方法,详细的描述问题空间(problem space),审视解决方案,找出缺陷和可以完美的部分,获得的效果有时候令人拍案叫绝。架构说明书(specifications)很重要,因为它描述了构建系统的模式。但是静下心来全面彻底地理解架构——既从宏观上把握组件之间的交互,又着眼于组件内部的代码细节——也很重要。原创 2015-08-15 18:41:12 · 510 阅读 · 0 评论 -
时间改变一切
作者:菲利普·尼尔森(PhilipNelson)我喜欢随着时间的流逝观察哪些事物会被淘汰,哪些能保存下来。自诩聪明的人们曾经怀着激情提出过那么多的模式、框架、范式转换(paradigm changes)和算法,哪一个不是声称可能一劳永逸地解决所有己知问题?结果都不过是昙花一现。为什么会这样?历史向我们昭示什么?选择值得投入精力的工作Pick a Worthy Chalienge原创 2015-08-19 20:32:38 · 484 阅读 · 0 评论 -
先尝试后决策
作者:埃里克·多伦伯格创建一个应用需要作出很多决策。有些决策涉及挑选框架和函数库,而另一些则需要选择特定的设计模式。不管哪种决策都需要架构师拿主意。平庸的架构师可能会收集手边的信息,斟酌酝酿一番,然后从象后塔里颁布解决方案让开发人员实现。无疑,还有比这更好的方法。玛丽·波彭代克(MaryPoppendieck)和汤姆·波彭代克(TomPoppendieck)夫妇俩(译注1)在著作中描述了一原创 2015-08-18 22:50:43 · 362 阅读 · 0 评论 -
掌握业务领域知识
作者:马克·理查兹(MarkRichards)高水平的软件架构师不仅要懂技术,还要掌握问题空间(problem space)对应的业务领域知识。缺乏业务领域知识的架构师不能顺利的理解业务问题,无法把握业务目标和业务需求,也就难以设计有效的架构来满足需求。架构师的角色任务在于理解业务问题、业务目标、业务需求,并设计技术架构来满足它们。掌握业务领域知识将有助于架构师选择合适的架构模式,更好的制原创 2015-08-19 13:35:23 · 1993 阅读 · 0 评论 -
设立软件架构专业为时尚早
作者:巴里·霍金斯(BarryHawkins)软件开发行业近来出现了一种令人不安的趋势:有人急于将软件架构的设计工作专业化,与传统的建筑学专业平起平坐。起因似乎是某些软件架构师不满足于同事和老板的肯定,希望自己的成就获得更正式的认可。要知道建筑学专业直到19世纪末才确立,在此之前建筑这个行当己经存在了几千年。两相比较,这些软件架构师未免太心急了。设计软件架构是一门手艺(craft),从业者原创 2015-08-21 13:38:19 · 313 阅读 · 0 评论 -
摩天大厦不可伸缩
作者:迈克尔·尼加德(MichaelNygard)大家经常把软件工程比喻成建造摩天大厦、水坝和公路,这种比喻在某些方面确实有道理。土木工程不仅是设计建筑对象这么简单,真正的难题在于规划整个施工过程,确保建筑物拔地而起,包括从奠基到竣工的所有工作。在竣工之前,建筑工人必须各施所长,让建筑框架一直竖立着。其中的有些经验很值得我们借鉴,尤其是对于布署大型集成化软件系统(包括所有的企业应用和Web原创 2015-08-22 00:36:44 · 325 阅读 · 0 评论 -
控制项目规模
作者:大卫·奎克(Dave Quick)规模指的是软件项目的大小。完成项目需要多长时间、多少人工和资源?要实现哪些功能?质量上有什么要求?难度如何?风险有多大?要遵守哪些约束条件?这些问题的答案界定了项目的规模。软件架构师都喜欢挑战复杂的大型项目。由于回报非常诱人,甚至有人搞“形象工程”,故意夸大规模。殊不知规模越大,项目失败的可能性越大,这一点常让人始料不及。规模扩大一倍,失败的可能性往往会原创 2015-08-21 21:32:33 · 608 阅读 · 0 评论 -
架构师不是演员,是管家
作者:巴里·霍金斯(BarryHawkins)架构师接手新项目,都渴望证明自己的价值,这是人之常情。公司除了要求架构师具备无可争议的技术领导能力,也希望他怀揣证明自己能力的迫切愿望。遗憾的是,有些架构师误解了“证明自己价值”的含义,以为是炫耀技术才华,甚至是刁难开发团队。炫耀和作秀是市场营销的重要手段,可能吸引顾客,却与指挥开发项目背道而驰。架构师必须扎实地掌握技术和业务领域的知识,以严谨原创 2015-08-21 22:01:00 · 261 阅读 · 0 评论 -
软件架构的道德责任
作者:迈克尔尼加德(Michael Nygard)软件世界的道德范畴边界不清晰。尽管有些行为无疑是不道德的,比如侵犯他人的公民权利、窃取他人身份信息、使用流氓软件等,但还有些行为的道德意义却不容易察觉。流行的软件产品可以影响成千上万的用户,影响可以是正面的,也可能是负面的——好软件节省时间,糟糕的则反之——即使这种影响不过几分钟。软件架构师的每项决策(例如设置必填项和规定流程),都限制了用原创 2015-08-21 22:41:33 · 473 阅读 · 0 评论 -
混合时代的开发己经来临
作者:爱德华加森(Edward Garson)随着计算机技术的“自然进化”,架构师用来构建软件系统的工具发生了重大的变化。这种变化再次激起了人们对混合编程(polyglot programming)的兴趣。混合编程是指在同一套软件系统中同时采用多种核心编程语言。混合编程不是新的概念,以前就出现过,比如大家曾经熟悉的一种架构:前端采用Visual Basic开发客户端,后端采用C++的COM原创 2015-08-22 15:29:29 · 353 阅读 · 0 评论 -
性能至上
作者:克雷格·罗素(CraigRussell)假设有这样一款轿车,空间宽敞、乘坐舒适,不但省油,而且价格低廉,89%的配件都是可循环利用的,你会动心吗?当然了,这样的车人人想要。如果最高车速只有10里/小时(6英里/小时),你还会动心吗?这个例子可以说明性能和其他指标一样重要。有些设计师把性能问题放在最后考虑。他们觉得与人比起来,计算机的工作速度己经够快了,用户肯定可以接受系统的工作速度,原创 2015-08-23 01:08:24 · 324 阅读 · 0 评论 -
让开发人员自己做主
作者:菲利普·尼尔森(PhilipNelson)多数架构师都是从开发人员干起的。架构师在决定如何构建系统的工作中肩负着新的责任,也拥有更大的权力。刚上任的架构师会发现很难沿用以往的工作方式开展新工作,总是迫切地觉得自己还需要大量的练习才能胜任管理开发人员的工作,让大家实现设计。应该给予团队成员足够的自主权,让他们发挥自己的创意和能力,这对你和团队来说都是件好事。以前作开发人员,你很少有机会原创 2015-08-19 19:40:40 · 334 阅读 · 0 评论 -
程序设计是一种设计
作者:埃纳尔·兰德雷(Einar Landre)发明面向对象程序设计方法和Simula程序设计语言的克利斯滕·尼高(Kristen Nygaard)博士曾经说过,程序设计是学习的过程。将程序设计——或者更准确地说,软件开发——看作发现和学习的过程,而不是生产和建造的过程。这种观点从根本上促进了软件实践方法的发展。传统的生产和建造理念不适合运用于软件开发。30多年来,软件行业的思想先驱不断就此发原创 2015-08-19 16:32:53 · 467 阅读 · 0 评论 -
先确保解决方案简单可用,再考虑通用性和复用性
作者:凯佛林·享尼(KevlinHenney)许多用来实现基础设施的代码,包括组件框架、类库、基础服务(fundation services),普遍存在一个问题,它们的设计一味强调通用性而不考虑具体应用,导致出现许多令人困惑的可选项和不确定因素,这些功能常常不是被闲置,就是被误用,甚至毫无价值。多数开发者开发的是专用系统,无限制的通用性对他们的帮助不大。寻求通用性最好的办法是研究现有的具体案例原创 2015-08-16 13:49:34 · 872 阅读 · 0 评论 -
架构师应该亲力亲为
作者:约翰·戴维斯称职的架构师应该通过示范领导团队。他能胜任团队的所有工作,从网络布线到配置构建流程,从编写单元测试到担任测试工作。对技术缺乏全面理解的架构师,充其量只是个项目经理。团队成员通常具备深厚的专业知识,很难想像不懂技术的架构师如何赢得大家的信任。众所周知,架构师是业务团队与技术团队之间的接口人,他必须理解各种技术问题,无须频繁求助他人,才能代表技术团队发言。同样,架构师还要懂得业务原创 2015-08-16 17:06:12 · 281 阅读 · 0 评论