为了回答你的一般问题,我说“温和”。 强调可检测性当然是一件大事。 但是,这并不是因为排除可读代码或符合逻辑的APIC而发生的。

贸易和发展会议做得很好,能够改善可读性。 贸易和发展会议做得不好,没有考虑其他重要原则,就可以减少可读性。

在90年代中期,我与我合作,说“你总是能够通过增加一层间接感使制度更加灵活。 你们总是可以通过消除间接层来简化制度。 灵活性和简单性都是系统的重要品质。 这两项原则往往和谐共处,但往往相互对立。 如果你对一个极端或另一个极端走得太远,那么你就偏离了这两个原则所存在的理想。

TDD部分涉及测试,部分涉及设计。 贸易和发展会议做得不好,可能过于倾向于灵活或简单。 它可以推动过于灵活。 这些物体更容易测试,而且往往更简单,但随之而来的域问题本身的复杂性被从物体中推向物体的相互作用。 我们获得了灵活性,而且从冷静的眼看,它能够看一看,因为我们的目标更为简单。 然而,复杂性仍然存在。 它从物体移出,进入物体互动,难以控制。 这里有可用作红色旗帜的密码钟——一个拥有数百个小物体、没有较大物体的系统,许多只使用一线方法的物体是另一个系统。

贸易和发展会议做得不够,也难以朝着另一个方向发展,即过于简单化。 因此,我们首先撰写考试,但对我们的设计几乎没有影响。 我们仍然有很长的方法,有巨大的目标,这些是能够重新解决这一问题的法典。

如今,只要应用得当,TDD就不会因为其性质而使你在这两种方向上脱节。 利用其他做法使你走上正轨。 例如,在你做事之前,介绍你重新做什么。 显然,并非全部时间。 有些事情太简单了。 某些图片值得挽救,有些只是帮助我们视而不见,而我们以不同程度多数是视力学习者。 如果你能够了解问题,你不会理解。

如何帮助TDD? 这将有助于使系统远离简单方面,保持灵活性。 如果你想一想,那就是一个红旗。 有时,这是必要的,但往往在你了解情况时,你会很快看到可以简化的内容。 解决办法变得更加合理和简化,更加容易维持,而且更适于工作。 如果你能够掌握或赢得你的系统图象,你就会错失这个机会,使你的软件更加坚固、更加leg、更加美好、更加美好、更加容易维护。

经验丰富,一些法典家永远不会理解良好平衡所提供的价值。 没有任何衡量标准可以告诉你,你回到正确的位置。 如果有人给你一条达到这一和谐点的固定方法,他会lying你们。 更为重要的是,他可能不实现这一点就lying。

因此,我对你的回答是:检验一切,而不忘记其他良好原则。

Any good practice will throw you off-course if it s not balanced with other good practices.

“did I miss?”

是的。

The thing works, does it not?

更重要的是,你可以证明它行之有效。

较之其实际运作情况,而且你可以证明它实际运作,因此,可检测性所增加的相对复杂程度并不令人感兴趣。 此外,你可以作出改变,并表明你确实没有打破这种变化。

The alternatives (may or may not work, no possibility of demonstrating if it works, can t make a change without breaking it) reduces the value of the software to zero.

<><>Edit>/strong>

"Complexity" is a slippery concept. There are objective measures of complexity. What s more important is the value created by an increase in complexity. Increasing complexity gives you testability, configurability, late binding, flexibility, and adaptability.

此外,复杂程度的客观衡量通常侧重于在一种方法中进行编码,而不是不同类别和物体之间关系的更大复杂性。 复杂性似乎是客观的,但在软件结构的所有层面都界定了。

“可试验性”也是一种缺陷。 可能有客观的可检测性措施。 然而,大多数情况下,这些都是为了测试覆盖面。 测试覆盖率没有非常有意义的衡量标准。 生产坠毁的可能性如何因测试覆盖面而有所不同? 页: 1

你们可以把复杂性归咎于注重可检验性。 你可以把复杂性归咎于很多事情。 如果你仔细研究高度可测试的法典,你就会发现,它也非常灵活、可预见和适应。

指出“可测试性”是“复杂性”的根源,这一点已经改变。

问题是,有许多相互关联的质量因素。 “它发挥作用”是总结最重要的办法。 其他不太重要的方面包括适应性、灵活性、可维持性。 这些额外的因素通常与可检测性相联,它们也可以被负面描述为“复杂性”。

我亲眼见过一些网站通过了所有单元测试、自动化接口测试、负载测试，几乎通过了每一个测试，但很明显，在人类的视角下存在问题。

这导致进行编码分析,发现记忆泄露、海滩问题、坏代码和设计缺陷。 当采用不止一种检测方法并且通过所有测试时,情况如何? 没有一个“单位”的记忆漏漏或ach问题,只是整个系统。

我个人认为,这是因为所有东西都是书面的,旨在通过测试,而不是在设计上是leg、简单和灵活的。 测试有许多价值。 但是,仅仅因为密码经过测试,就意味着它具有良好的法典。 它是指其“书状”法,而不是“直接智能”法。

我认为,鉴于软件相当庞大或重要,增加一些改进可检测性的复杂性是值得的。 此外,在我的经验中,复杂性难以理解的地方是,在围绕其本身固有的无法检测的法典(如封闭式框架类别)补充了抽象的层。 如果从可检测性这一首要原则的角度拟订守则,我就认为,实际上,该守则很容易阅读,而且比必要的更为复杂。

在我可以避免的情况下,我实际上对增加复杂性表示抵制。 例如,我尚未转向DI/IoC框架,更倾向于仅在需要测试时才使用手套。 另一方面,在我最后采取“增加”复杂性的做法——如模拟框架——时,我发现,复杂程度实际上低于我所担心,而且比我想象的多。 也许,我最终认为,对DI/IoC框架也是这样,但是,在我有一个足够小的项目,毫不拖延地通过学习新的 st子来进行试验之前,我可能没有成功。

(这完全是从方案者的角度撰写的。) 关于更方便客户的回答,我建议迈克尔·博尔顿作出答复。

如果你是书写的;10条代码线,那么,是的,增加试验会大大增加复杂性。 你们可以通过信息技术,对信息技术进行手工测试,并且很可能被罚款。 在100条线路上,而不是如此多的1 000条线路、10 000条线路、100 000条线路等。

第二个轴是变化。 这一共同基础是: 有多少? 该法典将越演越烈,就越有价值检验。

因此,如果是,150-Line-of-code app,即是一种从来不会改变的按批量方式进行的转成形文字,那么重型单位测试可能致命。

通常，在大型应用程序中，我发现改变代码以使其可测试可以提高设计和API的质量。因此，如果您正在编写更大的内容或进行迭代开发，并且认为（自动化）单元测试成本高/价值低，那么我会认真考虑为什么您认为是这种情况。

一种解释是,你的 b有吸毒的规律。 另一种可能是,你认为模式和测试是“是”的,而不是“全心全意”的讨论。 第三是,该法典已经写成,它使你可以重新测试。 如果出现这种情况,我建议采用外科手术方法——重点进行几处高香味的、迅速增加价值的检测。 随着《守则》的进展,你试样的步伐缓慢。 如果你看到价值和简单性——而不是复杂性,则服从模式。

这种办法的好处将回馈到IF。 增长幅度将足够大。 否则,它只是浪费时间。 有时甚至拖拉机、空投和沿SmartUI模式也足够了。

从描述来看,它像“YANGI”项目失去轨道,发展大型结构,以便在必要时进行测试。

在TDD中,一切理由都是通过测试证明的,因此,要求您具备所有这一国际oC、DI、AOP作为使现有试验得以通过的最简单解决办法,或者(更有可能)采用过于强制性的解决办法,使守则得以验证。

我所看到的导致这种复杂性的一个错误是,希望测试遵循设计,而不是相反。 可能发生的情况是,保持某种难以测试的设计的愿望导致采用各种工作办法开放APIC,而不是开发更简单、更容易测试APIC。

更好或更糟糕的是,TDD帮助我把我的申请分解成更可管理的构成部分,因为我能够孤立地测试项目,迫使我保持简明扼要。 在我向我的法典介绍其他内容时,这些测试也成为很好的文件来源。 通过测试可以很好地审查申请的工作情况,在这些情况下,事情被充分孤立,以便你能够围绕职能部分总结你的头脑。 另一种产品是,当你在申请中使用设计模式时,这些试验与其他应用相似,如果你使用了这种模式。

尽管如此,如果你知道这只剩下两条职能,那么执行指挥模式确实是sil笑的。 现在,你用书写了一套试验。 取得了哪些成就? 你们总是能够测试公共方法,但是,如果存在一种模式,你会处理复杂问题,并且与你必须维持的所有其他考验发生技术债务。

另一个需要考虑的因素,是你的团队能够支持的层次结构。 是否所有团队成员都对TDD有相同的认识,或者是否有少数能够理解这些测试的人? 看到一个 mo物体会使人眼,,单单是不会及时完成维修的令人望而却步的因素吗?

最后,申请范围也需要驱动设计。 “纯洁”的复杂性不是很好的判断。 贸易和发展会议并不造成这种情况;相反,缺乏经验可能。

我对你所暗示的几乎是可以读到的东西没有任何想法,因为即使使用《反歧视法》和《移民法》,每一部分都应容易理解。 由于这些技术,了解整体可能更为复杂,但更需要能够用模型或文字解释应用是如何运作的。

我目前正在处理一项申请,因为没有单一单位测试,因此,我现在开始介绍DI,以帮助使测试更加简单,但这将使其他开发商更难以理解这一系统,因为不同的具体班子可能会陷入困境,而且你们知道,在你看一看一看一看一看一看一看一看一盘子之前,那是谁。

这可能导致他们认为该守则是无法理解的,因为他们可以很容易地从一个职能层面流向另一个职能层面,但必须进行旁观,以了解哪一个具体类别可以使用。

但是，从长远来看，这将是一个更灵活和稳定的系统，所以我认为值得做一些培训。 :)

你可能只是需要看到如何为申请建立一个更好的系统模式,以了解如何把所有事项联系在一起。