Coder_Chang的博客

注释不恰当的信息注释只应该描述有关代码和设计的技术性信息废弃的注释如果发现废弃的注释，最好尽快更新或删除，废弃的注释会远离它们曾经描述的代码，变成代码中无关和误导读者的浮岛。冗余注释如果注释描述的是某种充分自我描述了的东西，那么注释就是多余的糟糕的注释字斟句酌使用正确的语法和拼写，别闲扯，别画蛇添足，保持简洁注释掉的代码删除它！别担心源代码控制系统还会记得它。环境构建系统应该是单步...

编程是一种技艺甚于科学的东西，要编写整洁的代码，必须先写肮脏代码，然后再清理它。小学老师就曾告诉我们写作文要先打草稿，再逐步改进。多数新手程序员并没有认真遵循这个建议，他们相信，首要任务就是写出能工作的代码，只要能工作，就转移到下一个任务上。而那个能工作的程序就留在了最后那个能工作的状态。多数有经验的程序员都知道，这是一种自毁行为。混乱是逐渐产生的，希望你看到一段乱七八糟的代码时，第一反应是不会就此罢手，而是不希望下一个人看到这段代码时，代码还是这个状态。毁坏程序最好的方法之一就是以改进之名大动

为什么要并发？并发是一种解耦策略，它帮助我们把做什么（目的）和何时做（时机）分解开。解耦目的与时机能明显的改进应用程序的吞吐量和结构。从结构的角度看，应用程序看起来更像是许多台协同工作的计算机，而不是一个大循环。系统因此会更被易于理解。关于编写并发软件的中肯说法并发会在性能和编写额外代码上增加一些开销 正确的并发是复杂的，几遍对于简单的问题也是如此 并发缺陷并非总能重现，所以常被看做偶发事件而忽略 并发常常需要对设计策略做根本性修改并发防御原则单一权责 限制数据作用域两

遵循标准的java类，应该从一组变量列表开始，吐过有公共静态常量，应该先出现，然后是私有静态变量，以及私有实体变量。很少有公共变量。类的第一条规则是应该短小，类的名称应当描述其全责。类名越含糊，该类越有可能拥有过多的全责。单一权责原则认为，类或模块应该有且只有一套加以修改的理由。系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装成一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为。类应该只有少数实体变量，类中的每个方法都应该操作一个或多个这种变量，通常而言，方法操作的

什么是单元测试极限编程(Extreme Programming,或简称XP)讲究TDD（test-driven development），即测试驱动开发，先编写测试代码，再进行开发。有一套运行通过的测试，我会确保任何需要用到代码的人都能方便的使用这些测试，并且确保测试代码一起签入同一个代码包。TDD三定律第一定律 在编写不能通过的单元测试前，不可编写生产代码第二定律 只可编写刚好无法通过的单元测试，不能编译也算不通过第三定律 只可编写刚好足以通过当前失败测试的生产代码保持

在接口提供者和使用者之间，存在与生俱来的矛盾。第三方程序包和框架提供者追求普适性，这样就能再多种环境中工作，从而吸引广泛的用户。而使用者则想要得到集中满足特定需求的接口。这种矛盾会导致系统边界上出现问题。学习性测试为要使用的第三方代码编写测试，可能是最符合开发者的利益。学习第三方代码很难，整合第三方代码也很难，同时做这两件事难上加难。但是我们可以尝试不同的做法，比如不要在生产代码中实验新东西，而是编写测试来浏览和理解第三方代码。Jim Newkirk把这种叫做学习性测试。在学习性测试中，我们就想

不会java，先将书中的重点摘抄一下。错误处理很重要，但如果它搞乱了代码逻辑，就是错误的做法。异常的妙处之一是，它们在程序中定义了范围。try-catch-finally语句中try部分的代码时，你是在表明可以随时取消执行，并在catch语句中接续。如果你在编写一套关键词代码库，则已检异常有时也会有用：你必须捕获异常。但对于一般的应用开发，其依赖成本要高于收益。你抛出的每个异常，都应当提供足够的环境说明，以便判断错误的来源和位置。对于代码的某个特定区域，单一异常类通常可行。伴随异常发

先描述一个现象：我们将变量设置为私有（private）有一个理由，不想让外界依赖这些变量。那么为什么还有程序员给该对象添加赋值器(setter)和取值器(getter)呢？将私有变量公之于众，如同他们是公共变量一般。事实上，即使变量都是私有的，但我们也通过变量取值器和赋值器使用变量，其实现也被暴露了。然后我们来看两份代码，他们实现了相同的功能，但在扩展时会有不同的问题：过程式代码 1对象式代码 2如果给代码1的Geometry类添加一个新的函数，其形状类完全不受影响。另一方面，.

目的原始代码修改之后很久，其代码风格和可读性仍会影响代码的可维护性和扩展性。好的代码如同报纸上的文章，你从上到下阅读，在顶部你期望有个头条，告诉你故事的主题，好让你决定是否读下去。第一段是整个故事的大纲，给出粗线条概述，但隐藏了故事细节。接着读下去，细节渐次增加，直至你了解了所有的日期、名字、引语、说法和其他细节。团队应该一致同意采用一套简单的格式规则，所有成员都要遵从这套规则。垂直维度对于java源代码来说，如JUnit、FitNesse和Time and Money都由相对较小的文件

为什么要写注释？什么也比不上防止良好的注释来的有用，什么也不会比乱七八糟的注释更有本事搞乱一个模块，什么也不会比陈旧、提供错误信息的注释更有破坏性。所以良好的注释是提高代码质量重要的一环。注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败，如果发现自己需要写注释，就再想想看是否有办法用代码来表达。注释存在时间越久，离其所描述的代码就越远，就越来越变得全然错误，原因是程序员没有坚持维护注释。程序员应当负责将注释保持在可维护、有关联、精确的高度。注意：注释不能梅花糟糕的代码，与其花时间

函数最重要的规则是短小，20行封顶为最佳。每个函数只做一件事，每个函数依序把你带到下一个函数。if、else、while语句等， 其中的代码应该只占一行，改行大抵应该是一个函数的调用语句。函数不应该达到足以容纳嵌套结构。编写函数是为了把比较大的概念拆分为另一抽象层上的一系列步骤。如果函数只做了该函数名下同一抽象层上的步骤，则该函数还是只做了一件事。函数中的语句要在同一抽象层级上。使用具有描述性的名称，且命名方式保持一致。参数不易阅读，它们带有太多的概念性，所以尽量使用少的参数。最理想

一个好的命名应遵循如下几条规则：一旦发现了有更好的名称，就替换掉旧的。 名称应该告诉读者，它为什么会存在，它做什么事，应该怎么用，如果名称需要注释来补充，那就不算是名副其实。 避免使用专有名词，或与本意相悖的词。 提防使用外形相似度较高的名称。 做有意义的区分，以数字命名是其对立面（如a1,a2,a3,...）。 避免出现同义词（如product,productInfo,productData）。 使用读得出来的名称，而不是各种单词的一系列缩写。 使用可搜索的名称，便于后续维护。 避免使

不管是刚入行不到一年的新手程序员，还是工作三年以上的老鸟，一定碰到过“祖传代码”，并为之头疼。对代码的每次修改都影响其他两三处的代码，每次添加或修改代码，都得对那堆扭纹柴了然于心，这样才能往上扔更多的扭纹柴，随着这团乱麻越来越大，再也无法清理，最后束手无策。宁愿自己重新写这个功能，也不愿碰它。很久之前，这种能跑就行的代码被开发出来，并说有朝一日再回头整理，最终“稍后等于永不”，堆叠成一个个谜题，等到后面接手的人去解答。被祖传代码拖了后腿，开发者又背负deadline压力，只好继续堆叠混乱。而事实