首页 > 其他分享> > 《代码精进之路：从码农到工匠》学习笔记

《代码精进之路：从码农到工匠》学习笔记

2022-02-18 12:01:46 作者：互联网

背景

敏捷要求团队更快和更频繁的出产品，两星期一迭代，三个月出产品。架构设计往边靠，先出个 MVP，再迭代，将来再重构.....

当敏捷变成了一种管理工具后，代码架构更加脆弱。

真正的技术 Leader 是能够创建并且演进架构，在架构层面上帮助大家比较容易地写出好代码的人。

命名

变量名

变量名应该是名词。

如果一个变量名需要注释来补充说明，那么很可能说明命名就有问题。

反例

int d; // 表示过去的天数

正例

int elapsedTimeInDays;

类名

对于辅助类，尽量不要使用 Helper、Util 之类的后缀，因为其含义太过笼统，容易破坏 SRP（单一职责原则）。比如对于处理 CSV，可以这样写：

CSVHepler.parse(String)
CSVHepler.create(int[])

建议将 CSVHepler 拆开：

CSVParser.parse(String)
CSVBuilder.create(int[])

异常规范

异常处理

业务系统中设定两个异常，分别是 BizException （业务异常）和 SysException （系统异常），而且这两个异常都应该是 Unchecked Exception。

针对业务异常和系统异常要做统一的异常处理，类似于 AOP，在应用处理请求的切面上进行异常处理收敛，其处理流程如下：

try {
    // 业务处理
    Response res = process(request);
}
catch(BizException e) {
    // 业务异常使用 WARN 级别
    logger.warn("BizException with error code:{}, error message:{}", e.getErrorCode(), e.getErrorMsg());
}
catch(SysException ex) {
    // 系统异常使用 ERROR 级别
    logger.error("System error" + ex.getMessage(), ex);
}
catch(Exception ex) {
    // 兜底
    logger.error("System error" + ex.getMessage(), ex);
}

错误码

显性化错误码

显性化的错误码具有更强的灵活性，适合敏捷开发。例如，可以将错误码定义成3个部分：类型+场景+自定义标识。每个部分之间用下划线连接，内容以大驼峰的方式书写。

对于错误类型，可以做一个约定：

P 代表参数异常（ParamException）
B 代表业务异常（BizException）
S 代表系统异常（SystemException）

错误类型	错误码约定	举例
参数异常	P_XX_XX	P_Customer_NameIsNull：客户姓名不能为空
业务异常	B_XX_XX	B_CUStomer_NameAlreadyExit：客户姓名已存在
系统异常	S_XX_XX	S_Unknow_Error：未知系统错误

函数

函数参数

最理想的参数数量是零(零参数函数)，其次是一(一元函数)，再次是二(二元函数)，应尽量避免三(三元函数)。有足够特殊的理由，才能用3个以上参数(多元函数)。

DDD

领域层的边界

DDD 的架构分层

“核心业务逻辑和技术细节相分离”。可以通过以下两种方式消除 Domain 的依赖问题。

使用依赖倒置，让 Infrastructure 反向依赖 Domain；
将 Repository 上移到 Application 层，也就是把组装 Entity 的责任转移给 Application。

技术 Leader 的修养

代码好坏味道

在我们团队周会中，有一个固定的环节是“代码好坏味道”︰当天的会议主持人（我们的周会是轮值主持的，每个团队成员轮流组织一期）要给大家分享3个代码好味道和3个代码坏味道，这些代码既可以是来自我们工作中的代码，也可以是来自开源软件的源码。

这个活动非常有意义，一方面每个人都会更多地去读他人的代码，另一方面自己在写代码时也会比较注意。因为一不小心，自己写的代码就可能成为反面典型被拿出来“晒”。晒代码不是关键，关键是通过晒代码，我们可以互相分享写好代码的心得和经验，特别是一些来自开源软件的好味道，对我们写好代码有非常重要的指导意义。这样整个团队的技术能力都会提升，当然，也包括Leader自己。

技术分享

分享是倒逼我们去学习和总结的有效手段。在准备分享的过程中,我们要去阅读很多资料,要把原理弄清楚,还要用别人能听得懂的方式表述出
来。最重要的是，通过分享,整个团队都能学到新的知识,分享人和倾听者都会收益颇丰,何乐而不为呢?

例如,所在团队的近几次技术分享分别是关于Service Mesh、FaaS和Cloud Native。这些概念虽然很重要,但是日常工作中
暂时还没有使用场景,没有必要每个人都去研究-遍,因此分享学习是一种非常经济的团队学习模式。一个人学,然后整个团队都能有了解和认知。
期间大家还可以有讨论和碰撞,这样既学到了东西,又增加了团队成员之间的连接,其作用不亚于一次团建。

技术规划

技术规划是一个大命题。对待这种大问题,我们要分而治之,将其分解成几个不同层次的、相对较小的问题来看。如图所示,我们可以从时间和重要性的维度,将其拆解成当前问题、技术领域、业务领域和团队特色4个层次的问题,然后分别定义问题、制定策略,这样就会清晰很
多。

1 当前问题

第一层问题解决是最直接的，主要看团队中现在有什么迫切、紧急的问题需要解决,有哪些坑要去填。例如,业务增长比较快、当前架构缺乏弹性、要做服务化拆分、加入分布式缓存、分表分库等。又如,因为代码质量(可读性、可维护性)差,要建立一个代码审查机制,提升代码质量。

2 技术领域

技术领域要做的是在这些常规领域中,根据业务情况和团队情况选择一些领域和命题(比如稳定、性能、效率等) , 并在这些命题和方向中根据优先级做判断。比如,完善监控体系提升系统稳定性、使用CDN提升性能、通过测试自动化提升研发效率等。

3 业务领域

让业务先赢是技术的首要使命，即使我们身处技术团队，也要充分理解业务、关注业务，要分析业务数据和发展趋势，和业务同事充分交流，总结和抽象出业务的发展对技术会提出什么诉求，需要技术做什么布局和建设以应对业务发展的需求。

4 团队特色

作为技术团队，我们要对比团队内外技术的异同，最终圈定一个差异化区域。这块区域是团队的特色技术，是团队借外力之外要修内功的部分，是不依赖别人而主要靠自己突破的部分，是团队相比外面的差异化竞争力。这一层很重要，对团队的口碑、影响力和稳定性都有较大的影响；同时这一层有事最难的，很多技术团队在这一层次是空白的。

Leader 和 Manager 的区别

Manager 是管理事务，是控制和权威；而 Leader 是领导人心，是引领和激发。Leader 要做一些 Manager 的管理事务，但是管理绝对不是 Leader 工作的全部。

整洁架构

软件架构

应用架构：由应用架构师负责，他需要根据业务场景的需要，设计应用的拓扑结构，制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速地支撑业务发展的同时，确保系统的可用性和可维护性。

六边形架构

六边形架构也是一种分层架构，只不过不是上下，而是内部和外部。

六边形架构又称端口-适配器架构，这个名字更容易立即。六边形架构将系统分为内部（内部六边形）和外部，内部代码应用的业务逻辑，外部代表应用的驱动逻辑、基础设施或其他应用。内部通过端口和外部系统通信，端口代表了一定协议，以API呈现。一个端口可能对应多个外部系统，不同的外部系统需要使用不同的适配器，适配器负责对协议进行转换。这样就使得应用程序能够以一致的方式被用户、程序、自动化测试、批处理脚本所驱动，并且可以在实际运行的设备和数据库相隔离的情况下进行开发和测试。

一个端口对应多个适配器，是对一类外部系统的归纳，它体现了对外部的抽象。应用通过端口为外界提供服务，这些端口需要良好地设计和测试。内部不关心外部如何使用端口，从一开始就要假定外部使用者是可替换的。

DDD

DDD 不是架构，而是一种开发思想，就像敏捷不是Scrum，而是一种思想一样。之所以将 DDD 归类为典型架构，是因为它是我们很多架构的思想来源。比如洋葱架构，其内层（核心业务逻辑）就应该是领域层。

另外，DDD 带来的最大改变是让我得以从“数据驱动”转向“领域驱动”，让我们知道领域是应用的核心，其他都是技术细节，随时可以被替换。

标签：精进,架构,农到,从码,代码,业务,技术,团队,异常
来源： https://www.cnblogs.com/incheng/p/15908044.html