相关语录

近年来，我开始研究贝克的简单代码规则，差不多也都琢磨透了。简单代码，依其重要顺序：•能通过所有测试；•没有重复代码；•体现系统中的全部设计理念；•包括尽量少的实体，比如类、方法、函数等。在以上诸项中，我最在意代码重复。如果同一段代码反复出现，就表示某种想法未在代码中得到良好的体现。我尽力去找出到底那是什么，然后再尽力更清晰地表达出来。

借用美国童子军一条简单的军规，应用到我们的专业领域：让营地比你来时更干净。如果每次签入时，代码都比签出时干净，那么代码就不会腐坏。

我们都曾经瞟一眼自己亲手造成的混乱，决定弃之不顾，走向新一天。我们都曾经看到自己的烂代码居然能运行，然后断言能运行的烂程序总比没有强。我们都曾经说过有朝一日再回头清理。当然，那些日子里，我们都没听过LawofLeBlanc：Laterequalsnever

我可以列出我留意到的整洁代码的所有特点，但其中有一条是根本性的。整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的余地。代码作者什么都想到了，如果你企图改进它，总会回到原点，赞叹某人留给你的代码—全心投入的某人留下的代码。

1，并发防御原则（1）单一权责：方法/类/组件应当只有一个修改的理由（2）限制数据作用域（3）使用数据副本避免共享数据（4）线程应尽可能独立2，了解常见的执行模型：生产者-消费者，读者-作者，宴席哲学家3，警惕同步方法之间的依赖4，保持同步区微小5，尽早考虑关闭的代码，注意线程之间的依赖关系6，测试线程代码（1）将伪失败看作可能的线程问题（2）先使非线程代码工作（3）运行多于处理器数量的线程

每次签入时，代码都比签出时干净。

Noisewordsareanothermeaninglessdistinction.ImaginethatyouhaveaProductclass.IfyouhaveanothercalledProductInfoorProductData,youhavemadethenamesdifferentwithoutmakingthemmeananything

以及ExtremeProgrammingAdventuresinC#（中译版《C#极限编程探险》）作者

也不必用m_前缀来标明成员变量。应当把类和函数做的足够小，消除对成员前缀的需要。你应该使用某种可以高亮或用颜色标出成员的编辑环境。此外，人们很快学会无视前缀（或后缀），只看到名称中有意义的部分。代码读得越多，眼中就越没有前缀。最终，前缀变作了不入法眼的废料，变作了旧代码的标志物。

“且慢！”你说。“不听经理的，我就会炒鱿鱼。”多半不会。多数经理想要知道实情，即使他们看起来不喜欢实情。多数经理想要好代码，即便他们总是痴缠于进度。他们会奋力卫护进度和需求；那是他们该干的。你则当以同等的热情卫护代码。再说明白些，假使你是位医生，病人请求你在给他做手术前别洗手，因为那会花太多时间，你会照办吗？本该是病人说了算；但医生却绝对应该拒绝遵从。为什么？因为医生比病人更了解疾病和感染的风险。医生如果按照