《代码整洁之道》—第1章1.6节童子军军规

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

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

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

版权声明 代码整洁之道 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

前言 代码整洁之道:程序员的职业素养 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),提出一种软件质量,可持续开发不仅在于项目架构设

1.3 混乱的代价只要你干过两三年编程,就有可能曾被某人的糟糕的代码绊倒过.如果你编程不止两三年,也有可能被这种代码拖过后腿.进度延缓的程度会很严重.有些团队在项目初期进展迅速,但有那么一两年的时间却慢如蜗行.对代码的每次修改都影响到其他两三处代码.修改无小事.每次添加或修改代码,都得对那堆扭纹柴了然于心,这样才能往上扔更多的扭纹柴.这团乱麻越来越大,再也无法理清,最后束手无策. 随着混乱的增加,团队生产力也持续下降,趋向于零.当生产力下降时,管理层就只有一件事可做了:增加更多人手到项目中,期望