代码质量及软件架构
文章平均质量分 59
包括设计模式、代码整洁之道、重构改善既有代码设计、架构整洁之道
坐飞机的狗
熟悉java技术,熟悉java常用设计模式,熟悉java高并发程序设计,了解jvm调优;熟悉基于spring boot+Mybatis的网站后端开发;了解go web开发,熟悉基于RPC + go 微服务开发;熟悉python常用的数据分析库(pandas\sklearn\tensorflow等)、爬虫框架(scrapy)、django后端开发;熟悉mysql的使用;了解前端HTML+CSS+Javascript;了解常用的机器学习算法;熟悉git常用操作。
展开
-
DDD系列-3
为什么要用Repository实体模型与贫血模型Entiry(实体)-ER模型:用来描述实体之间的关系,而后演变为一个数据模型,在关系数据库中代表了数据存储的方式。许多ORM框架,忽略了Entiry本身行为,导致许多模型仅包含了实体数据(属性),而实体的业务逻辑被分散在多个服务、Controller、Utils工具类中–贫血模型贫血模型特征大量的XxxDo对象:是数据库表结构的映射,里面没有包含(或包含了很少的)业务逻辑服务和Controller里有大量的业务逻辑:校验逻辑、计算逻辑、格式转载 2021-10-05 00:37:46 · 346 阅读 · 0 评论 -
DDD系列-2
架构软件系统中固定不变的代码结构、设计模式、规范和组件间的通信方式。做架构时应实现:独立于框架:架构不依赖具体某个外部的库或者框架独立于UI:底层架构不应该随展示样式发生变化独立于底层数据源:无论使用MySQL、Oracle还是其他独立于外部依赖:无论外部依赖如何变更、升级、业务的核心逻辑不随之变化可测试性:业务逻辑可以快速验证正确性但是在做业务研发时,更多的会去关注一些宏观的架构,比如SOA架构、微服务架构,而忽略了应用内部的架构设计,很容易导致代码逻辑混乱,很难维护,容易产生bu转载 2021-09-29 20:53:35 · 483 阅读 · 1 评论 -
DDD架构-1
Domain PrimitivePrimitive 定义:不从任何其他事物发展而来,初级的形成或生长的早期阶段案例分析1一个新应用在全国通过 地推业务员 做推广,需要做一个用户注册系统,同时希望在用户注册后能够通过用户电话(先假设仅限座机)的地域(区号)对业务员发奖金。public class User { Long userId; String name; String phone; String address; Long repId;}pub转载 2021-09-28 00:07:58 · 102 阅读 · 0 评论 -
架构整洁之道--第四部分(组件原则)
一、组件组件是部署的单元,组件是可被作为系统一部分部署的最小项。例如:java中的jar等。组件可以连接,成为单个可执行文件,或者他们聚合起来,成为一个包。二、组件聚合REP: 复用/发布等效原则CCP: 共同封闭原则CRP: 共同重用原则1. 复用/发布等效原则(REP)细粒度的重用是细粒度的发布复用/发布等效原则(REP)至少字面上看起来很明显,人们想重用软件组件的话,这些组件应当有发布的历史记录,每个记录都有发布号。没法保证所有的可重用组件是相互兼容的发布过程应当生成适原创 2021-08-11 18:02:38 · 611 阅读 · 0 评论 -
重构改善既有代码设计--封装向下转型
封装向下转型动作某个函数返回的对象,需要由函数调用者执行【向下转型】动作将向下转型动作移到函数中动机由于「 计算对象型别」 的动作往往比较麻烦, 你还是常常需要亲自告诉编译器「 对象的确切型别」 。 向下转型在Java 特别盛行, 因为Java 没有template( 模板) 机制, 因此如果你想从群集( collection) 之中取出一个对象, 就必须进行向下转型。【常会在「 返回迭代器( iterator) 或群集( collection) 」 的函数身上发生。 】方法找到【必须对函数调原创 2021-07-16 22:57:24 · 356 阅读 · 0 评论 -
重构改善既有代码设计--以工厂函数取代构造函数
以工厂函数取代构造函数Employee (int type) { _type = type;}=======================>static Employee create (int type) { return new Employee(type);}动机你可能常常需要根据type code 创建相应的对象, 现在, 创建名单中还得加上subclasses, 那些subclasses 也是根据type code 来创建。你也可以令你的factory method 根原创 2021-07-07 23:58:35 · 249 阅读 · 0 评论 -
重构改善既有代码设计--隐藏某个函数
隐藏某个函数有一个函数,从来没有被其他任何class用到,将这个函数修改为private动机重构往往督促修改函数的可见效只有另一个class需要用到某个函数,才有必要提高该函数的可见度。情景:过于丰富、过多行为的接口、只不过做了点简单封装的容器、添加越来越多行为的class对象:取值函数、设置函数隐藏起来作法多检查使用lint-style工具设值函数应该多关注应尽可能降低所有函数的可见性修改后编译测试...原创 2021-07-06 20:23:55 · 189 阅读 · 0 评论 -
重构改善既有代码设计--移除设置函数
移除设置函数你的class中的某个值域,应该在对象初创时设置值,然后就不再改变。动机如果你为某个值域提供了设值函数(setter),这就暗示这个值域值可以被改变.不希望在对象初创之后此值域还有 机会被改变,那就不要为它提供设值函数 (同时并将该值域设为final )做法是否只被构造函数调用,或者被构造函数所调用的另一个函数调用修改构造函数,使其直接访问设值函数所针对的那个变量如果某个subclass 通过设值函数给superclass 的某个private 值域设了值,那么你就不能这原创 2021-07-05 15:01:14 · 125 阅读 · 0 评论 -
重构--引入参数对象
引入参数对象某些参数总是很自然地同时出现。原创 2021-07-03 23:58:05 · 691 阅读 · 0 评论 -
重构改善既有代码设计--以函数取代参数
以函数取代参数对象调用某个函数,并将所得结果作为参数,传递给另一个函数。动机如果函数可以通过其他途径(而非参数列)获得参数值,那么它就不应该通过参数获得该值,过长的参数会增加阅读难道。看看参数接收端是否可以通过与调用端相同的计算来取得参数携带值通过所属对象内部的另一个函数来计算参数,可以将这个计算过程转移到调用端内,从而去掉参数。调用的函数隶属另也给对象,让该对象拥有一个reference指向调用端所属对象。如果参数计算过程依赖调用端某个参数,那么就无法去掉被调用端的那个函数。作原创 2021-07-03 22:18:10 · 287 阅读 · 0 评论 -
重构改善既有代码设计--保持对象完整
保持对象完整动机有时候,你会将来自同一对象的若干项数据作为参数,传递给某个函数存在的问题:万一将来被调用函数需要新 的数据项,你就必须查找并修改对此函数的所有调用。解决办法:把这些数据所属的整个对象传给函数,会提高代码的可读性,降低重复代码。但参数对象和被调用函数所在的对象之间,就有了依存关系。如果被调用函数使用了来自另外一个对象的许多项数据,应该将整个方法移到另外一个对象中。...原创 2021-06-30 21:29:10 · 334 阅读 · 0 评论 -
架构整洁之道--依赖倒置原则
稳定的抽象反之,改变具体实现并不总是,或者非常少会要求他们实现的接口改变。因此接口比实现更加不易变,稳定得软件架构避免依赖易变得具体类,倾向于使用稳定的抽象接口。**被引用异变的具体实现类:**请引用抽象接口类,使用抽象工厂模式创建对象。**别从易变的具体实现类派生:**继承是所有代码依赖关系里最强,最死板的。**别覆盖具体实现的函数:**你覆盖这些函数时,你无法消除这些源码依赖,应该把这个函数声明成抽象的,然后可以写多个实现。别提任何的具体实现和易变类的名字工厂在Java中,我们可原创 2021-06-27 00:13:30 · 166 阅读 · 0 评论 -
架构整洁之道--接口隔离原则
接口隔离原则User1的源码无意义的依赖于op2,op3,即使User1没有调用他们。这里的依赖意味着op2,op3源码的改变将迫使User1重新编译,重新部署,即使这里的改变跟User1没有任何关系。User1的源码得依赖与U1Ops接口,和op1,但不依赖与OPS类了。因此OPS的改变,User1并不关系,也不会造成User1被重新编译,重新部署。ISP和架构大多时候,模块依赖于更多它并需要的东西是很不利的。在源码层面很好解释,你得重新编译,重新部署,但在架构层面上也是很不利的。设想D包原创 2021-06-26 23:46:09 · 77 阅读 · 0 评论 -
架构整洁之道--开闭原则
开闭原则软件工件的行为应该是不必修改工件而可扩展的想法实验有个财务汇总的web页面的系统,假设利益相关者想把这些同样的信息在黑白打印机打印成报告。一个好的软件架构将会把改变得代码总量尽可能降到最低,理论上,一行不变。通过把会由于不同原因变化得事情分割开来(单一职责原则SRP),恰当地组织这些事情得依赖(依赖倒置原则DIP)。1.信息隐藏确保类A用到B的名字,但类B没有用到类A的名字。这样A知道B的存在,但是B就不知道A的存在。2.方向控制所有的函数和类的关系都是单向的。Interac原创 2021-06-26 23:05:14 · 95 阅读 · 0 评论 -
整洁架构之道-设计原则(单一职责)
单一职责原则(SRP)概念:一个模块有且只能由于一种原因被改变,一个模块有且只能对一个角色负责。模块:一组内聚的函数和数据结构症状:意外的重复对某个角色所用到的公用代码进行修改时,会影响其他角色调用该代码的结果。SRP原则讲:分割不同角色依赖的代码。解决方法这问题有很多不同的解决方法,每种都把这些函数移到不同的类中。这种方案的缺点是开发者现在有三个需要实例化和跟踪,可以通过门面模式。一些开发者倾向于把重要的业务规则写得离数据更近。把重要的方法保留到之前的Employee类里,然后用原创 2021-06-26 12:02:04 · 146 阅读 · 0 评论 -
重构 改善既有代码设计(第9章-简化条件表达式)
分解条件式if (data.before(SUMMER_START) || data.after(SUMMER_END)) charge = quantity * _winterRate + _winterServiceCharge;else charge = quantity * _summerRate;========================>if (notSummer(data)) charge = winterCharge(quantity);else charge原创 2021-06-20 22:24:50 · 150 阅读 · 1 评论 -
重构改善既有代码的设计(第三章))
重构的难题数据库绝大多数的商用程序都与其背后的DataBase schema(数据库表格结构)紧密耦合在一起,DataBase schema如此难以修改的原因。数据迁移,常用手段是:系统分层–将DataBase schema和对象模型间的依赖降到最低,但是对数据库表的更改,这可能是一件漫长的工作。在非对象数据库中,解决办法是:在对象模型和数据库模型之间插入一个分隔层,可以隔绝两个模型各自的变化。修改接口对于对象:允许分开修改软件模块的实现(implementation)和接口(inter原创 2021-06-14 20:19:48 · 77 阅读 · 0 评论