发表于
字数统计: 1.2k 字数 | 阅读时长 ≈ 4 分钟

之前学习了极客时间上的一个专栏《软件设计之美》，作者对软件设计、编程范式、设计原则与模式、设计方法进行了讲解，内容全面。

专栏里面的一些内容，我也有些接触，但认知还不够深，比如面向对象。而且专栏把这些内容都串联起来，跟着专栏内容总结梳理一下。

软件设计是什么

软件设计：依据需求分析结果转化为软件设计模型与技术文档

Design is there to enable you to keep changing the software easily in the long term –Kent Beck

设计是为了让软件在长期更容易适应变化。

相对于软件设计，现在人好像更喜欢说架构。它们俩有什么区别，是不是本质上是同一件事，只是称呼不同而已？

以前有人总结：从0到1是架构，从表到里是抽象，从粗到细是设计

两者似乎是一样的，只是一个相对宏观，一个相对微观。

架构，之前已经写过很多，可以参考《架构专栏》

架构会关注两点：

一是软件提供功能：作者上升为模型，一个软件之所以是这个软件的核心。

二是架构特征，也就是架构质量：各种约束规范。

软件设计学习的难度，不在于一招一式，而在于融会贯通。

软件设计重要因素？

软件设计为了什么？为了更加容易地扩展软件能力。再深一层，软件开发为了什么？当然是为了解决由需求带来的问题，而解决的结果则是一个可以运行的交付物。

那么什么制约了软件的扩展能力，是现实需求的复杂性。之前总结过复杂性的来源：

如何解决复杂性：分而治之。一是把整体软件分解成粒度大小适合的模块功能；二是分解不同层次的东西，也就是分离关注点。如把技术与业务拆解。

除了分解，还有一个常被忽略的重要因素：可测试性。当一个软件拆分成一个一个的小模块后，如果不尽可能地保证每个小模块的正确性，就没法保证软件整体的正确性。如同盖楼一样，不保证钢筋、水泥、砖土质量合格，却想盖出合格大楼是荒谬的。

软件设计的三个部分

要了解一个软件设计，可以从三个部分入手：模型、接口和实现

模型：这个系统与其它系统有所区别的关键，理解整个软件设计最核心的部分

接口：通过怎么样的方式将模型提供的能力暴露出去，以及我们与这个软件交互的入口

实现：软件提供的模型和接口在内部是如何实现的软件能力得以发挥的根基

编程范式

编程范式：程序的编写模式，意味着主要使用的是什么样的代码结构。

由最经典的结构化编程，限制goto语句，它对程序控制权的直接转移施加约束；再到面向对象编程，限制使用函数指针，它是对程序控制权的间接转移施加了约束；再到最新的函数式编程，限制使用赋值语句，它是对程序中的赋值施加了约束。

每种范式在现代语言都看到它的影子，因此现在像混合格斗，不再是独门独派。我们吸取百家之长，采用面向对象来组织程序中的各个模块，采用函数式编程指导类的接口设计，在具体的实现中使用结构化编程提供的控制结构。

设计原则与模式

这部分内容，在《SOLID系列》中已经总结的差不多了。

当然还有很多原则，我们重要的是如何在各个原则之间追求平衡。

设计方法

这一部分也是我们常讨论的DDD了，详细的可以查看《DDD》专栏

总结

怎么才能做好软件设计，从文中内容推断软件架构师犹如软件体系里面的全能神。

所以难点不在于一招一式，而在于融会贯通。吸百家之精华，大成也！

发表于
字数统计: 1.9k 字数 | 阅读时长 ≈ 6 分钟

在《领域驱动设计》这本书里面，列举了三种可将业务逻辑建模为软件模型的模式，也就是大家常听说的事务脚本、贫血模型、DDD。

之前我还把这三种模式搞混淆了，too young too simple了。

举个简单的示例：

用户转帐，从一个帐户转到另一个帐户

阅读全文 »

发表于
字数统计: 1.5k 字数 | 阅读时长 ≈ 5 分钟

CQRS全称Command Query Responsibility Segregation

在CQRS中，来自客户端的命令通过单独的路径抵达命令模型，而查询操作则采用不同的数据源，这样的好处在于可以优化对查询数据的获取，比如用于展现、用于接口或报告的数据。

CQRS这些年火起来了，常被人挂在嘴边提起。为什么？因为DDD提倡富模型，但从资源库查找所有需要显示的数据是困难的，特别是在需要显示来自不同聚合类型与实例的数据时。领域越复杂，这种困难程度越大。

有没有一种完全不同的方法可以将领域数据映射到界面显示中呢？答案正是CQRS。

在From CRUD to CQRS文章中，作者比对了CRUD模式与CQRS模式

阅读全文 »

发表于
字数统计: 1.3k 字数 | 阅读时长 ≈ 5 分钟

迪米特法则 Law of Demeter

LOD

最早出现于 1987年，由美国东北大学的伊恩·霍兰德（Ian Holland）提出。也叫做“最少知识原则”。

Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.

阅读全文 »

发表于
字数统计: 710 字数 | 阅读时长 ≈ 2 分钟

Twitter上有人发了一个推，说他之前问过一个问题：“你最好的一条职业建议是什么？”，他得到了1300多个答案，最后他整理了12条最好的建议。
🔗 twitter、com/chrishlad/status/1502650707274608644

1、 尽可能为别人减少不确定性

  • Uber解决了打车的不确定性
  • 亚马逊解决了送包裹的不确定性
  • 你也可以通过及时更新项目进展来帮老板解决不确定性

2、 公司比职位更重要

3、 一旦接受了一个任务，无论多小或者多么不起眼，要把它做的特别好，超出别人的预期。这样你就能建立起一个良好的声誉，让别人知道你总能高质量的完成工作。当你建立了这种声誉，你就能得到更多的机会，更大的知名度，以及更大的成功。

4、 如果我不能信任你，你再聪明都没用。

5、 在你的职业生涯中，陪你走到最后的只有你自己。不是你的公司，不是你的经理，不是你的团队，只有你自己。
在做你所有职业生涯的决定时，优先考虑你自己。

6、 影响你职业生涯的三件事：

  • 你做什么？（工作）
  • 你为谁工作？（客户）
  • 和你一起工作的人是谁？（团队）

如果你热爱你的工作、客户和团队，你会非常非常幸运。

7、 和一个聪明的能激励你走向伟大的人结婚。

8、 要么能学东西，要么能赚钱。
否则果断离职，去找一个这两者至少占一样的工作。

9、 如果一个问题你不问，那么答案一定是“不”。

10、 选择你的老板。
你有权选择谁当你的老板，而在找工作的过程中很多人没有考虑到这一点。
一个优秀的老板可以为你的职业发展提供极大的助力。

11、 学会阐明你所做的事情的商业价值，而不仅仅是你的工作头衔或者项目。
不好的例子：“我是一个数据科学家。我创建了3个自服务数据应用”
更好的例子：“我帮助管理层发现了一个可以节约2300万美元成本的机会”

12、 “职业”，本质是一个营销名词，是由那些经营特定类别的梦想的人卖给你的，而他们在贩卖这个梦想时赚了很多钱。
赚钱，承担风险，有冒险精神。
但不要让“职业”来限制自己

发表于
字数统计: 1.2k 字数 | 阅读时长 ≈ 4 分钟

在做程序测试时，常会用到测试替身来协助我们快速完成测试。

有时候被测试系统(system under test(SUT))很难测试，因为在测试环境下依赖的组件不能正常使用。如外部系统。

当在一个不能使用真实依赖组件(depended-on component(DOC))的地方写test时，我们可以使用Test Double。

阅读全文 »

发表于
字数统计: 925 字数 | 阅读时长 ≈ 3 分钟

几乎在每个团队，都至少有一份代码规范，或者代码的check list。然也就仅仅是一份清单。

每次团队复盘时，都会有一条，我们要写好代码，然“好代码”是什么样子，什么标准，全取决于各人的水平。

每个程序员也都知道code review的重要性，然排期很紧张，难得做一次。宁可花时间追查问题，也不做防御性准备。

这些现象，是不是特别平常，虽然很想改变，但又是无力感呢。

程序员对代码的追求态度决定了职业生涯的高度，代码的质量决定了生活质量。

为什么会有上面提到的现象，大概有这两方面的原因：

1、每个人对“好代码”的观念不一样

2、对于“坏味道”缺乏明确的表象判断，也就很难提出明确的改进措施

好代码

什么样的才是好代码，耳朵听出老茧的那句话“高内聚，低耦合”，可是这句话，太抽象了，类似之前总结的SOLID原则，需要更具体的特征。这也类似于要先把书读厚的原因。

怎么培养对代码的审美高度？

首先需要大量阅读好代码，可以去阅读很多开源项目。

其次找个导师，让自己的代码多被审视。

坏味道

如果说好是没有标准的，那坏是有限的。

对象健身操

这是Thoughtworks文集中，有一套对象健身操。保持9条规则。

1、 方法只使用一级缩进

2、 拒绝使用else关键字

3、 封装所有原生类型和字符串

4、 一行代码只有一个“.”运算符

5、 不要使用缩写

6、 保持实体对象简单清晰

7、 任何类中的实例变量都不要超过两个

8、 使用一流的集合

9、 不要使用任何Getter/Setter/Property

重构

经典书籍《重构》、《Clean Code》都是让代码质量提升的优秀教材。它们都是工具书，时时拿出来对照书本检查代码。

在《重构》中，明确列出了多项“坏味道”，并给出了重构方法：

1、 Duplicated Code（重复的代码）

2、 Long Method（过长函数）

3、 Large Class（过大类）

4、 Long Parameter List（过长参数列）

5、 Divergent Change（发散式变化）

6、 Shotgun Surgery（霰弹式修改）

7、 Feature Envy（依恋情绪）

8、 Data Clumps（数据泥团）

9、 Primitive Obsession（基本型别偏执）

10、 Switch Statements（switch惊悚现身）

11、 Parallel Inheritance（平行继承体系）

12、 Lazy Class（冗赘类）

13、 Speculative Generality（夸夸其谈未来性）

14、 Temporary Field（令人迷惑的暂时值域）

15、 Message Chains（过度耦合的消息链）

16、 Middle Man（中间转手人）

17、 Inappropriate Intimacy（狎昵关系）

18、 Alternative Classes with Different Interfaces（异曲同工的类）

19、 Incomplete Library Class（不完整的程序库类）

20、 Data Class（单纯的数据类）

21、 Refused Bequest（被拒绝的遗赠）

22、 Comments（过多的注释）

当然，实际工作中，不能消除所有坏味道，但只要能做到命名合理、没有重复、各个代码单元(类、函数)体量适当、各个代码单元有明确且单一的职责、各个代码单元之间有恰当的交互，就已经是质量相当高的代码了。

我会按上面的内容结合实际工作，出一份Clean Code系列，早日让代码摆脱坏味道。

发表于
字数统计: 1.1k 字数 | 阅读时长 ≈ 4 分钟

先看一段简单的代码：

1
2
3
4
5
6
7
8
package com.zhuxingsheng.adapter

@PostMapping("/login")
public LoginResponse login(LoginRequest loginRequest) {

    return loginService.login(loginReqeust);

}

从代码中，可以明显看出这是一段处理登陆请求的方法。在大多数项目中，这种代码很常见。

它有什么坏味道呢？

分层穿透了，LoginRequest类本应该属于入口层，结果穿透到了service层。

细细追究，需要明确的问题：

1、LoginRequest到底属于哪一层，是resource层，还是service层？

2、没有达到DDD防腐层的意义，resource是隔离外部与核心业务的，但却变成了透传。

阅读全文 »

发表于
字数统计: 1.8k 字数 | 阅读时长 ≈ 6 分钟

“学而优则仕”的传统文化渗透在各行各业。

那么”码而优则仕”则是这种文化的延伸，自然而然的结果。

当然很多程序员对做管理不感兴趣，想很纯粹的研究技术，成为一名技术专家。人各有志，但客观讲，技术专家与技术管理相比较，成为技术专家比技术管理难度大得多，只有做到在一个区域，一个行业屈指可数的顶尖专家，才有更加广阔的前景。尤其在国内的环境大多数都是业务型公司，技术本身没有直接价值，没有太高的壁垒，有太多能取代你位置的人。

当然，技术管理也有难度，尤其对于程序员群体。但只要做到一个团队内的最佳，则拿到了敲门砖，随时准备幸运之神的降临。跨越技术纯粹性的舒适性，技术管理之路就开启了。

阅读全文 »