India Database

CCD：模具等级一目了然然后，在每次签入和每次代码审查期间都会积极考虑这些原则。这样，一旦违反原则，committer 和 reviewer 之间就会启动讨论。

在此，我想再次向大家澄清原则和硬性规则之间的区别：硬性规则没有给你自己决定的余地，也不能做到一视同仁，但CCD框架内的做法和原则是旨在促进更多的个人主动性和自我责任感。您不需要使用设计模式。相反，您有责任选择正确的设计模式来满足 CCD 的原则。此外，您当然有责任在原则似乎相互矛盾的情况下找到任务的最佳解决方案。

瑞士 adesso 的手术流程
我们越来越依赖各个团队中开发人员的个人责任。我们在 adesso Switzerland 使用的一种简单但有效的方法是在团队监视器上显示 CCD 等级的颜色 - 例如作为背景颜色。在一定的间隔内，CCD等级的颜色会交替显示，从而引起开发人员的注意。与个人方法类似，每个开发人员都有责任遵守原则和实践。此外，团队监视器上的跨团队和跨项目显示确保了通用方法。重要的是，无论选择何种呈现方法，一个或多个团队的所有开发人员都可以看到成绩。目的是让所有团队成员每天都清楚每个开发人员所处的级别以及个人特别关注哪些原则和实践。如果有多个团队，这种方法还具有以下优点：不同项目的团队可以就各自当前级别的原则和实践交换想法。

除了这种方法之外，您还可以举办信息活动（棕色袋子）。所谓的编码 律师电子邮件列表 道场——意味着思想和解决方案方法的透明开发和交流——也在这种背景下建立。这些措施的目的是让高质量发展意识内化到各个客户项目中。最终，您的客户尤其应该从软件开发的质量意识和专业精神中受益。举个例子，我将假设下面有一个项目，其代码库已经开发了几年。例如，该项目的开发人员首次体验了 Guava，并且该库中的一些选项已经集成到类中。此外，我们的示例项目基于一个服务层，该服务层在其接口中提供并期望可选选项。到目前为止，一切都很好。然而，您很快就会意识到有一个类不仅包含 Guava，还包含 Java 可选值。这个类虽然大大简化了，但可能如下所示：


冗余使用第二个可选类

当谈到使用这两类选项时，有些人可能会感到脖子后面的汗毛都竖起来了。难道你不能通过可选来减少代码吗？然而，由于多种原因，说起来容易做起来难：

更改方法签名和替换接口中的类可能会导致该接口的使用者进行重大自定义。
并非所有导入都可以轻松地从 Guava 更改为 Java，因为这两个类具有不同的方法，并且必须相应地调整代码。
服务层的接口由于依赖于其他项目，不能轻易更改。
通常开发人员根本没有时间来实现它。
在我的项目示例中，我假设服务层中的方法无法更改，并且更改最初应尽可能小且有限。作为一名开发人员，在决定是否只想在可用时间内替换该类的选项，或者是否要在转换中包含该类的其他使用者时，您可以从自己的经验中受益。但是，当您调用服务层时，您必须相应地映射这两个选项。为了不必一次又一次地重写此映射，您需要适当的方法来双向转换选项。