Bright LGM's Blog

前文讨论了敏捷数据工程实践的相关概念。有哪些具体的敏捷数据工程实践呢？本文将分享“基于代码的复用”实践。

应用软件开发中的代码复用

在应用软件开发中，代码复用是一件显而易见的、开发人员几乎每天都在做的事情。良好的代码复用可以有效降低代码重复率，提高效率，并减少潜在的BUG。

前几天，我在跟一位做进口贸易的朋友聊天，发现一个很有意思的事情。

他们做的是国内的高端仪器进口的进口贸易业务。主要帮助销售国外产品的公司完成竞标、合同签订、物流、海关、进口贸易政策符合、维保等等事务。

我很疑惑，为什么会有这样的业务形态存在？为什么这些产品销售公司不自己处理这些事务，反而代理出去让其他公司赚钱呢？

TDD有很多好处，但是广大程序员却总是难以接受。即便在我们ThoughtWorks，有着非常浓厚的TDD氛围的公司里，接受起来也依然不是一件简单的事情。我曾经见过一些在我们公司工作过一年甚至两年的同事，对TDD的理解都还停留在比较粗浅的认识上，平时的实践也难以跟上。

随着微服务和DDD的兴起，领域这个词逐渐成为了一个大家每天讨论中的高频词。对于经验稍欠缺的同学们，刚接触领域这个词，总会感觉有点神秘。到底什么算是一个领域呢？我们经常在谈论领域模型、领域服务、领域事件、领域边界等等，如果对领域概念没有一个清晰的认识，在接受这些相关概念上想必也会遇到阻碍。本文将结合我个人的理解以及一些实践经验来谈谈对这个概念的理解，希望能帮助大家更好的认识领域，进而更好的理解和运用相关的概念，最终更好的指导软件开发实践。

在文章开始之前，我们先回顾一下TDD带来的好处。当我们理解TDD之后我们至少会发现下面这三点：

1. TDD是一种更加自然的编程方式，因为我们总是要先弄清需求再编写代码，而这跟TDD先写测试（通过测试清晰的定义需求）再写实现的顺序是完全一致的。
2. 先写测试还要求我们站在使用者的角度来编写测试，这样我们可以自然的驱动出来更好的设计。
3. 由于TDD天然的特性，测试在编写代码之前就有了，自然我们也就无需担心测试覆盖率不够带来的质量问题了。

TDD给我们编写代码带来的好处多多，我前面有一篇文章主要分析了如何从改善设计的角度理解TDD，相信大家能感受到TDD给改善程序设计带来的好处。这里我想再次分享一个用TDD改善设计的例子，我们将从中看到不用TDD时我们的代码可能会变成什么样，而用了TDD又将变成什么样。

《重构–第二版》在我的书单里面待了好长一段时间了，趁着放假有时间读了一遍。这本书作为我司首席科学家老马的大作，同时又有大熊和林丛羽的翻译加持，值得每个人认真的反复的学习。

重构作为敏捷实践的精髓之一，在我们这个以敏捷为立身之本的公司里应当属于大家信手拈来的基本技能了。虽然说重构的基本思想长期不过时，但是第一版《重构》毕竟已经是20年前的事情了，20年以来软件开发行业兴起了无数新的编程思想、语言、工具、框架等，现在回过头去看第一版，会发现不仅纸质书籍难以买到，而且知识上也总觉得有点脱节。新版本以JavaScript语言作为示例，重新思考并改进了第一版本中的众多重构手法，结合了多年来一些新的观点和思考，带给了我们一套更为丰富完善的重构体系。

通读一遍本书，很多让我产生共鸣的地方，同时本书让我对于我们日常的一些实践有了新的看法，对于我们经常讨论的一些问题也有了新的结论。下面想摘录一些重要的观点，并分享几点我的理解，与大家一起学习。

进门，双手帮你脱下外套，挂起。洗发师双手提起一件深色防水的丝质套衫，你伸手，换上。拿起腰带，穿过你的腰，两圈，拉扯一次，拉扯两次，系紧。抹平套衫肩部，拉住袖口，拉扯一次，拉扯两次，展平。拉住套衫底部，拉扯一次，拉扯两次，拉齐。

将你带到洗头处，你看到一个用于平躺的台面，台面上深色皮质的垫子分为两部分，前面部分可拆卸，上放一块叠起来的深蓝色毛巾，毛巾上面是一朵颜色鲜艳的大荷花。在台面前部放有一个与垫子同样深色皮质的单人凳。

洗发师伸开右手，将你迎向凳子坐下。介绍洗头服务：我是37号洗发师为您服务，本次洗发50分钟，请您稍坐，我去准备毛巾和其他用品。

昨天和项目组的几个小伙伴去爬山。这次爬山坐标深圳梧桐山。从西北门进山，我们沿着蜿蜒的公路一路而上，历时三小时登顶。下山时不想原路返回，故意选了另一条路。从山上往下看，这条路陡峭得很。不过，对于几个血气方刚的男性，这条路正好。因为大家都觉得上山太简单不过瘾，想挑战一下高难度。于是我们一致同意换路而行。我们走的这条路就是凌云道。

说起凌云道这条路，真是名副其实。它不仅几乎呈垂直高度下降，而且台阶较窄仅有半脚宽。路两边树丛虽然茂盛，但是都不高大，山下的情形总是能进入眼帘。我一向有点恐高，在这垂直高度近1千米地方往下看，还真是心里有点慌。刚开始下山，小伙伴们见此山势，纷纷停下脚步拍照。得几张无P图片如下，大家可以感受一下：

作为我们使用最广泛的CI/CD工具Jenkins，它对于Pipeline as Code的支持却并不能算友好。在多个项目中使用之后，我发现它存在的主要问题有：

• Groovy语言的学习成本
• 调试低效
• 灵活性差

Groovy语言相对而言还是比较小众的。其设计为一种动态类型的语言，这给编译器、IDE的类型推断带来了困难，从而导致较弱的自动代码提示。除此之外，由于Groovy可以在没有歧义的情况下省略括号和行尾分号，并且如果最后一个参数是一个闭包则可以将其写在函数调用之后，这就导致了相对比较怪异的语法出现。比如，刚接触Groovy的人可能不太能一下子理解下面这段代码的工作原理：

1
2
3
4

a(1) {
    something(123)
    someother id: 1, message: "test"
}

在当下很多的应用场景中，我们常常会想要应用具有一定的灵活性，以便我们可以在线调整计算逻辑，而不需要重新发布应用。这可能也可以称为以极限的速度发布软件的方式。

AB测试可以说解决了一部分这样的需求，使得我们可以在线的针对部分用户改变应用的行为。但AB测试需要我们预先定义并实现两套逻辑，然后通过线上配置来应用不同的逻辑。显然，在可自定义的程度上，AB测试是非常弱的。如果我们想要更大规模的调整应用的逻辑，AB测试就不够了。