《代码整洁之道》—第13章13.7节保持同步区域微小

版权声明 代码整洁之道 Authorized translation from the English language edition, entitled Clean Code: A Handbook of Agile Software Craftsmanship, 9780132350884 by Robert C. Martin, published by Pearson Education, Inc, publishing as Prentice Hall, Copyright 2009

第13章 并发编程代码整洁之道Brett L.Schuchert "对象是过程的抽象.线程是调度的抽象."--James O Coplien[1] 编写整洁的并发程序很难--非常难.编写在单线程中执行的代码简单得多.编写表面上看来不错.深入进去却支离破碎的多线程代码也简单.系统一旦遭受压力,这种代码就扛不住了. 本章将讨论并发编程的需求及其困难之处,并给出一些对付这些难点.编写整洁的并发代码的建议.最后,我们将讨论与测试并发代码有关的问题. 整洁的并发编程是个复杂话题,值得用一整本书来

第1章 整洁代码代码整洁之道 阅读本书有两种原因:第一,你是个程序员:第二,你想成为更好的程序员.很好.我们需要更好的程序员. 这是本有关编写好程序的书.它充斥着代码.我们要从各个方向来考察这些代码.从顶向下,从底往上,从里而外.读完后,就能知道许多关于代码的事了.而且,我们还能说出好代码和糟糕的代码之间的差异.我们将了解到如何写出好代码.我们也会知道,如何将糟糕的代码改成好代码. 1.1 要有代码有人也许会以为,关于代码的书有点儿落后于时代--代码不再是问题:我们应当关注模型和需求.确实,有人

第1章 专业主义 代码整洁之道:程序员的职业素养 "噢,笑吧,科廷,老伙计.这是上帝,或者也可以说是命运或自然,跟我们开的一个玩笑.不过,不管这家伙是谁或是什么,他真幽默!哈哈!" --霍华德,<碧血金沙>这么说,你确实是想成为专业的软件工程师,对吧?你希望能昂首挺胸向世界宣告"我是专业人士",希望人们满怀尊重地看着你,充满敬意地对待你.希望母亲们会指着你告诉自己的孩子要成为像你这样的人.这些都是你想要的,对吧?

前言 代码整洁之道:程序员的职业素养 1986年1月28日,美国东部时间上午11:39,"挑战者"号航天飞机在发射仅73.124秒后,因右侧固体火箭推进器的故障,在1.5万米的高空化成碎片.7名航天勇士魂断苍穹,其中包括高中教师克丽斯塔·麦考利芙.麦考利芙的母亲亲眼目睹女儿在1.5万米高空中不幸罹难,当时她脸上的表情,至今印刻在我的心头无法拂去. 挑战者号之所以解体,是由于高热气体从出现故障的固体火箭推进器的外壳接缝处泄露出来,喷到外部燃料舱体上.主液氢燃料舱底部发生爆炸,液氢被点燃,

前言 代码整洁之道:程序员的职业素养 1986年1月28日,美国东部时间上午11:39,"挑战者"号航天飞机在发射仅73.124秒后,因右侧固体火箭推进器的故障,在1.5万米的高空化成碎片.7名航天勇士魂断苍穹,其中包括高中教师克丽斯塔·麦考利芙.麦考利芙的母亲亲眼目睹女儿在1.5万米高空中不幸罹难,当时她脸上的表情,至今印刻在我的心头无法拂去. 挑战者号之所以解体,是由于高热气体从出现故障的固体火箭推进器的外壳接缝处泄露出来,喷到外部燃料舱体上.主液氢燃料舱底部发生爆炸,液氢被点燃,

现在的软件系统开发难度主要在于其复杂度和规模,客户需求也不再像Winston Royce瀑布模型期望那样在系统编码前完成所有的设计满足用户软件需求.在这个信息爆炸技术日新月异的时代,需求总是在不停的变化,随之在2001年业界17位大牛聚集在美国犹他州的滑雪胜地雪鸟(Snowbird)雪场,提出了"Agile"(敏捷)软件开发价值观,并在他们的努力推动下,开始在业界流行起来.在<代码整洁之道>(Clean Code),提出一种软件质量,可持续开发不仅在于项目架构设计,还与代码

      现在的软件系统开发难度主要在于其复杂度和规模,客户需求也不再像Winston Royce瀑布模型期望那样在系统编码前完成所有的设计满足用户软件需求.在这个信息爆炸技术日新月异的时代,需求总是在不停的变化,随之在2001年业界17位大牛聚集在美国犹他州的滑雪胜地雪鸟(Snowbird)雪场,提出了"Agile"(敏捷)软件开发价值观,并在他们的努力推动下,开始在业界流行起来.在<代码整洁之道>(Clean Code),提出一种软件质量,可持续开发不仅在于项目架构设

13.9 测试线程代码 证明代码的正确性不切实际.测试并不能确保正确性.然而,好的测试却能尽量降低风险.这对于所有单线程解决方案都是对的.当有两个或多个线程使用同一代码段和共享数据,事情就变得非常复杂了. 建议:编写有潜力曝露问题的测试,在不同的编程配置.系统配置和负载条件下频繁运行.如果测试失败,跟踪错误.别因为后来测试通过了后来的运行就忽略失败. 有一大堆问题要考虑.下面是一些精练的建议: 将伪失败看作可能的线程问题: 先使非线程代码可工作: 编写可插拔的线程代码: 编写可调整的线程代码: