团队凝聚力_如何通过高凝聚力消除错误

本文主要是介绍团队凝聚力_如何通过高凝聚力消除错误，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

团队凝聚力

直觉告诉我们，诸如此类的方法具有明显的代码异味：

CompilationTask getTask(Writer out,JavaFileManager fileManager,DiagnosticListener<? super JavaFileObject> diagnosticListener,Iterable<String> options,Iterable<String> classes,Iterable<? extends JavaFileObject> compilationUnits
);

为什么呢？让我们深入研究这种直觉。这是来自JavaCompiler Javadoc的示例：

Iterable<? extends JavaFileObject> compilationUnits1 =fileManager.getJavaFileObjectsFromFiles(Arrays.asList(files1));compiler.getTask(null, fileManager, null, null, null, compilationUnits1).call();

那怎么了我们有很多非常不同类型的参数，这些参数很可能设置为null 。这降低了上述方法的可重用性，或者按照JArchitect专家的说法，我们可能处于“痛苦地带”，因为我们的稳定性较低，抽象度较低。

稳定性低：在JavaCompiler的未来版本中，很有可能需要另一个非常具体的参数，例如，另一个可Iterable的东西。这将导致不兼容的API增强
抽象度低：即使上述方法是一种接口方法，也很难多次实现此方法，因为很难以一种有用的方式来实现上述协定。

避免此问题的一种常见方法是使用Petri Kainulainen很好地描述的构建器模式。

高凝聚力而非“痛苦地带”

也许，对于此编译器API，这可能并不重要。但是，“高内聚力”（即理想的稳定性/抽象性平衡）的最大价值在于您拥有高度可重用的代码。这不仅好，因为您的开发人员花费较少的时间来执行特定任务，这还意味着您的代码具有极强的抗错误能力。例如，从jOOQ的内部检查数据类型转换逻辑：

jOOQ的数据类型转换层次结构

以上只是对调用层次结构的摘录，该调用层次结构导致在整个框架中间接使用的单个数据类型转换API。一切都从那儿开始，所以如果有任何数据类型转换错误，要么是

仅限于上述树表示形式的单个方法/单个叶子
极度全球化

换句话说，任何与数据类型转换有关的错误要么仅仅是表面上的，要么是完全灾难性的。这基本上意味着在该区域几乎没有回归的可能性，因为任何数据类型转换回归都将立即破坏数百个单元和集成测试。这是在代码中具有高度凝聚力的主要好处。

如何获得高凝聚力

很简单：无情地重构。您永远不应仅在本地引入新功能。例如，让我们在这里考虑此修复程序[＃3023] DefaultRecordMapper不会将嵌套的UDT映射到嵌套的POJO上。因此，我们希望将jOOQ RecordMapperProvider功能应用于嵌套记录。为什么？想象一下，我们有一个PERSON表，其中包含ADDRESS和STREET属性的Oracle OBJECT类型。是的，您也可以将这些数据标准化，但是假设我们正在使用UDT：

CREATE TYPE street_type AS OBJECT (street VARCHAR2(100),no VARCHAR2(30)
);CREATE TYPE address_type AS OBJECT (street street_type,zip VARCHAR2(50),city VARCHAR2(50)
);

现在，我们想将这些数据递归映射到定制的嵌套POJO上：

public class Street {public String street;public String number;
}public class Address {public Street street;public String city;public String country;
}public class Person {public String firstName;public String lastName;public Address address;
}

映射应该可以通过以下方式获得：

// The configuration object contains the
// Mapping algorithm implementation
Person person = DSL.using(configuration).selectFrom(PERSON).where(PERSON.ID.eq(1))// We want to make the mapping algorithm recursive
// to automatically map Address and Street as well.fetchOneInto(Person.class);

记录到POJO的映射已经实现，但是递归没有实现。当我们实现递归时，我们希望尊重jOOQ 3.1中引入的现有的，上述的可定制映射SPI 。非常简单，在ConvertAll类型的顶部只有一个实现点 。

在高度凝聚力的代码库中实现这一点意味着：

我们只需实施一次此新功能
与撰写此博客文章相比，实现此新功能花费的精力更少
记录映射和转换的嵌套将一次性适用于所有用例
我们仅增加了一些令人敬畏的新功能，而其复杂性略有增加（错误的风险较低）

你

无法预见完美的设计。它生长缓慢。今天，我们对Java和集合有很多了解，新的Streams API花费了一段时间。没有人会从头开始在JDK 1.2中实现如此出色的新API，尽管从那个角度来看，当时它已经相当不错了。

这主要对您意味着两件事：

对于基本的核心代码，重要的是要使其达到较高的内聚性。如果您是电子银行供应商，则您的付款和经纪业务逻辑应与上面所述完全一样，并具有平衡的稳定性/抽象度比
对于非必需的代码（例如，UI / DB访问），您应该依赖第三方软件，因为其他人将花费更多时间来获得高质量的代码（UI：例如Vaadin ， ZK或DB访问：例如Hibernate ， jOOQ ， Spring Data ，仅举几例）

…并且，如果您要求一个高度凝聚力的框架提供一项新功能，则可能唯一需要做的就是这四行代码。

参考：在JAVA，SQL和JOOQ博客上， JCG合作伙伴 Lukas Eder提供了如何通过高凝聚力消除错误。