Martin

练习1: 创建表以及数据已经给出,按照下列要求进行查询. 表:student 1 CREATE TABLE student( 2 id INT , 3 NAME VARCHAR ( 20 ), 4 chinese FLOAT , 5 english FLOAT , 6 math FLOAT 7 ); 8 9 INSERT INTO student(id,NAME,chinese,english,math) VALUES ( 1 , ' 张小明 ' , 89 , 78 , 90 ); 10 INSERT INTO student(id,NAME,chinese,english,math) VALUES ( 2 , ' 李进 ' , 67 , 53 , 95 ); 11 INSERT INTO student(id,NAME,chinese,english,math) VALUES ( 3 , ' 王五 ' , 87 , 78 , 77 ); 12 INSERT INTO student(id,NAME,chinese,english,math) VALUES ( 4 , ' 李一 ' , 88 , 98 , 92 ); 13 INSERT INTO student(id,NAME,chinese,english,math) VALUES ( 5 , ' 李来财 ' , 82 , 84

第7章 什么是敏捷设计 　　可以使用许多不同的媒介描述设计，但是设计最终体现为源代码。从根本上讲，源代码就是设计。 7.1 设计臭味 　　如果幸运，你会在项目开始时就想到了系统的清晰图像。系统设计是存在你脑中的一幅至关重要的图像。如果幸运一点，在首次发布时，设计依然保持清楚。 　　接着，事情开始变糟。软件像一片坏面包一样开始腐化。随着时间流逝，腐化蔓延、增长。丑陋腐烂的痛处和疖子在代码中积累，使它变得越来越难以维护。最后，仅仅进行最简单的更改，也需要花费巨大的努力，以至于开发人员和一线管理人员强烈要求重新设计。 　　这样的重新设计很少会成功。虽然设计人员开始时的意图是好的，但是他们发现自己正朝一个移动目标设计。老系统不断发展变化，而新的设计必须跟得上这些变化。这样，甚至在第一次发布前，新的设计中就积累了很多瑕疵和弊病。 　　 7.1.1 设计臭味——腐化软件的气味 　　当软件出现下面任何一种气味时，就表明软件正在腐化。 僵化性 脆弱性 顽固性 粘滞性 不必要的复杂性 不必要的重复 晦涩性 　　 7.1.2 僵化性 　　僵化性是指难以对软件进行改动，即使是简单的改动。如果单一的改动会导致有依赖关系的模块中的连锁改动，那么设计就是僵化的。必须要改动的模块越多，设计就越僵化。 　　大部分开发人员都会以这样或那样的方式遇到过这种情况。他们会被要求做一个看起来简单的改动

关于事件流处理，在不同的场景中有不同的概念。有人称之为流处理，有人称之为事件溯源或CQRS，还有人称之为“复杂事件处理（Complex Event Processing）”。不管名称是什么，它们的基本原则都是一样的。Martin Kleppmann是Apache Samza的贡献者。在本文中，我们将跟随他的思路深入理解这些概念，以便帮助我们设计更好的系统。 “流处理（stream processing）”源于LinkedIn构建大规模数据系统的经验，并在开源项目Apache Kafka和Apache Samza中实现。Martin以Google Analytics为例具体介绍了这一概念。Google Analytics是一小段JavaScript代码，可以追踪哪个访问者访问了哪个网页。然后，系统管理员可以研究这些数据，并按照时间段、URL等划分这些数据。为了实现这个目的，每次用户访问一个页面时，就需要记录一个事件来反映这个事实。页面访问事件可能是（图1）这样的结构： （图1） 每个事件都是包含上述信息的一个简单不变的事实。它只简单地记录已发生的事情。然后，我们就可以从这些页面访问事件中生成图形仪表板。通常来说，这些事件可以使用（图2）所示的其中一种方式存储： 选项（a）：在每个事件进来的时候将其存储，并把它们全部转存到一个大型的数据库、数据仓库或Hadoop集群中。在需要时

目录 前言 一、spring cloud 和 Dubbo 技术上选谁呢？ 选择spring cloud 选择Dubbo 小结 二、spring cloud 和 Dubbo 社区的活跃度 小结 三、spring cloud 和 Dubbo 架构完整度 小结 四、Round 4：文档质量 小结 五、但如果我选，我会用springcloud。 从公司整体规划 从程序员招聘难度 从系统结构简易程序 从性能 从开发难易度 从后续改进 从配套措施 从技术实力层面 总结 前言 简而言之，Dubbo确实类似于Spring Cloud的一个子集，Dubbo功能和文档完善，在国内有很多的成熟用户，然而鉴于Dubbo的社区现状（曾经长期停止维护，2017年7月31日团队又宣布重点维护），使用起来还是有一定的门槛。 Dubbo具有调度、发现、监控、治理等功能， 支持相当丰富的服务治理能力 。Dubbo架构下，注册中心对等集群，并会缓存服务列表已被数据库失效时继续提供发现功能，本身的服务发现结构有很强的 可用性与健壮性 ，足够支持高访问量的网站。 一、spring cloud 和 Dubbo 技术上选谁呢？ 选择spring cloud 一定要选Spring Cloud全家桶：社区支持强大，更新非常快，所以开发效率高。 速度慢不是缺点，扩展性不强也不是缺点。 大/中/小型公司总是担心

~ 在资源受限的国家进行战略合作，以构建和推广以公民为中心的企业架构，进而实现公共服务创新和转型 ~ 伦敦--(美国商业资讯)--独立于供应商的技术联盟 The Open Group 和联合国信息通信技术(ICT)机构 国际电信联盟 (ITU)今日宣布开展一项合作，以加快公共服务创新和转型，进而改善公民成果，并最有效地利用ICT基础设施。 The Open Group和ITU将通过合作致力于在全球促进、指导和建立数字政府战略和以公民为中心的企业架构(EA)方面的能力。 ITU秘书长赵厚麟表示：“数字公共服务从未对全世界公民的生活产生如此深远的影响。通过此次与The Open Group建立合作关系，国际电信联盟将加大力度，帮助世界各地的政府加快部署和扩展有影响力的、以公民为中心的数字解决方案，以支持经济复苏及联合国可持续发展目标(SDG)。” 借助必要的指导和资料，资源受限的国家将能够更好地将数字战略转化为可实施的大规模系统。因此，ITU与The Open Group之间建立的战略联盟将填补为实现可持续发展目标而进行的数字投资与最佳实践架构方法之间的空白。 ITU电信发展局(BDT)主任Doreen Bogdan-Martin表示：“将数字解决方案和技术用于高端数字公共服务，对于支持对COVID-19疫情的响应和从中恢复至关重要。在设计、实施和大规模推出数字公共服务时

有幸参与了一些领域驱动的项目，读了一些文章，也见识了一些不伦不类的架构，感觉对领域驱动有了更进一步的认识。所以今天跟大伙探讨一下领域驱动设计，同时也对一些想要实践领域驱动设计却又无处下手，或者一些正在实践却又说不上领域驱动设计到底好在哪的朋友一些指引方向。当然对于”领域驱动设计”这个主题而言从来不乏争论，所以大家可以在畅所欲言。 为什么要使用领域驱动设计？ 从Eric Evans的《 领域驱动设计：软件核心复杂性应对之道 》一书的书名就可以看出这一方法论是为了解决软件核心复杂性的。也就是说软件业务越来越复杂了，领域驱动设计可以让事情变得简单。而实际情况是：领域驱动设计的门槛很高，没有很深厚的面向对象编码能力几乎不可能实践成功。 这一说法是否自相矛盾呢？Martin Fowler在 PoEAA 一书中给了一个有力的解释： 我们把三层架构等除了领域驱动之外的架构方式都可以归纳为以数据为中心的架构方式，在图中是黑色的粗实线； 领域驱动设计在图中是绿色的粗实线。 当软件在开发初期，以数据驱动的架构方式非常容易上手，但是随着业务的增长和项目的推进，软件开发和维护难度急剧升高。 领域驱动设计则在项目初期就处在一个比较难以上手的位置，但是随着业务的增长和项目的推进，软件开发和维护难度平滑上升。 这幅图形象的解释了领域驱动设计和传统的软件架构模式两者在软件开发过程中解决复杂性之间的差异。

许多组织在迁移到云期间发现了大量的技术债务。但是什么是技术债务呢？DevOps如何帮助我们去解决技术债务呢？在这篇文章中，我们将讨论使用DevOps将您的技术债务负担减少的方式！ 什么是技术债务？ 技术债务是指在整个应用程序生命周期内做出的 次优技术决策 的累积。最终，改变事物变得越来越困难，使IT计划陷入停顿。 例如，应用程序中不良的状态管理可能会使水平缩放策略难以实施。在执行您真正想做的事情（横向扩展应用程序，以便应对日益增长的流量）之前，您需要重新编写代码的状态管理部分。 “先做需要做的事，然后再做想做的事”的工作就是技术债务 。 值得指出的是，技术债务不仅会发生在开发中，还可能发生在运营中。例如：仍在运行不再受支持的过时的操作系统（Windows Server 2008或Ubuntu 11.04）。不保持服务器的修补程序更新和最新状态，会使您容易受到网络攻击和勒索软件的攻击。这些都是技术债务。 为什么会存在技术债务？ 马丁·福勒（Martin Fowler）的技术债务象限指出，有时技术债务是无意的。您不知道的内容，但是现在您知道了，因此可以对其进行修复。 谨慎，刻意的技术债务是精益创业公司 Eric Ries的“构建-度量-学习”周期的核心。有时，了解您是否拥有可行产品的唯一方法是 发布产品并将其掌握在客户手中 。这可能意味着您“偷工减料”，从而招致技术债务。

关于技术债务，做开发的同学对如下场景应该不陌生： 为了敢项目进度，详细设计、单元测试等过程就不写了，以后补 需求变化万千，原本架构设计无法满足新的需求，可是又不想动架构，于是绕过架构设计新增代码 旧的系统，没有文档、没有注释，维护困难 如上问题，我们如果不及时去修正，欠下的债务会越来越多，从而会导致代码臃肿、系统效率低下，我们可以用技术债务这个词来形容上面出现的系统的质量问题。 那什么是技术债务呢？行程的原因又是什么？如何去管理技术债务？ 我们在项目管理学习时知道表示软件质量的三角形图，时间、成本和范围，如下图： 为什么质量要放在三角形中间呢？因为质量是其他三个因素平衡后结果的体现。比方说范围不减、成本不增加，又想节约时间走捷径，很显然，会影响到质量，这个质量，不止是产品质量，还有架构质量和代码质量。我们队这种质量的透支，就是一种债务，而技术债务，就是软件项目中对架构质量和代码质量的透支。 所以技术债务是有利息的，债务的利息，就是后续对软件进行新增修改的时候，需要额外的时间成本。当然，技术债务不一定是坏的，软件项目中，经常会刻意的欠一些技术债务，提升短期的开发速度，让软件快速推出，从而抢占市场；还有像快速开发模型，通过欠技术债务的方式快速验证，即使验证不可行，这笔技术债务也无需偿还。 技术债务产生的原因在重构一书中作者Martin Fowler把技术债务产生的原因分成了两个维度：

martin fowler老爷子的《企业应用架构模式》一书在江湖上流传已久，在十几年前就企业应用中的典型场景及设计模式进行了思考和总结，可以看到书中提及的常用模式在如今流行的企业应用框架中已经落地。近日拜读，受益不少，将一些感悟和共鸣记录下来，整理下，不全面也不深入，只便于后续乱翻书。 写在前面 行文知其思维，martin老爷子的书写起来条理清晰，层次分明，易于理解，非常值得称道，本文借鉴martin先生的行文模式，每一种模式均包含如下几部分：模式概要、我的理解、项目实践。希望通过后面两部分的介入，尝试将对应要点落地。 知识概要 该书第一部分“表述”对书中提及的各种模式及知识要点做了概括性介绍。主要从抽象层面介绍了企业应用中遇到的架构问题及常见的解决思路。涉及到：分层架构思想、领域逻辑组织、orm、web表现层、并发、会话状态及管理、分布式相关等。 企业应用 企业应用时将计算机技术这一生产力作用于现实世界的表现形式。一个企业应用的设计需要考虑清楚该应用的业务目标、受众人群等。企业应用一般有如下特点： 需要持久化数据。 采用何种持久化介质？如何持久化？ 涉及大量数据。 数据存取的高效性？数据容量？存储介质如何支持数据的快速增长？ 多人同时访问数据。 并发问题？服务可用性？用户会话管理？ 大量用户交互。 交互方式？服务可用性？ 同其他企业应用之间的集成。 系统集成形式？如何降低耦合

导读：关于代码覆盖率的话题，在之前我分别翻译了四篇相关的文章（详见下面链接），不过每一篇都没有达到自己心中的要求。作为对细节要求有“洁癖”的我，还是愿意再花时间去好好的梳理和总结，希望带给读者非常清晰和富有逻辑的文章，这就是这篇文章的意义所在。 相关阅读： 代码覆盖率和测试覆盖率到底是不是一回事？ 用测试覆盖率度量代码质量真的靠谱？ 不要被100%的代码覆盖率所欺骗 测试覆盖率必须100%吗？听老马怎么说 01 什么是代码覆盖率 在单元测试中，代码覆盖率主要用来衡量代码质量好坏的指标，代码覆盖率表示测试用例通过手动测试和使用自动化测试所覆盖的代码百分比。计算公式如下： （A）你正在测试的软件的总代码行数 （B）所有测试用例当前执行的代码行数 （B除以A）乘以100，这将是您的代码覆盖率%。 例如，如果系统组件中的代码行总数为1000，并且所有现有测试用例中实际执行的行数为650，那么您的代码覆盖率为: (650 / 1000) * 100 = 65% 02 代码覆盖率与测试覆盖率不同 除了代码覆盖率之外，我们常常还听到另一个概念叫测试覆盖率。很多人认为代码覆盖率和测试覆盖率是一回事，所以经常这两个概念混用，但其实两者之间是有差别的。 代码覆盖率和测试覆盖率度量的对象是完全不同的。 代码覆盖率是通过测试执行期间覆盖的代码百分比来度量的，是 度量多少代码被执行；