第一篇 - 敏捷学习笔记

作为一个菜鸟中的战斗菜。 我还没有在CSDN写过一篇文章。除了是因为语文功底太差以外，也是因为自己在武学道路上走得时间还太短，领悟太少，见解更谈不上，所以，我决定还是从做点笔记开始吧。

今天翻看了Agile Java 。这是之前一直想看却没有时间看的书。今天当作给自己放假，翻了一翻。

第一章 Geting  Started

软件开发中的一个主要问题是代码维护的高成本。原因之一是匆行动或者纯粹疏忽导致的代码混乱。软件开发的一个主要目的是让软件可以工作。要保证这个目的，需要做的是在编码之前，先编写测试代码来应对挑战。同时，确保代码是干净的。

作者提出了两种机制来实现：

1、保证系统中没有重复代码

2、保证代码是干净且负有表现力，可以清晰地体现程序员的意图。

在您前进时，越是持续雕琢改进您的代码，您遇到需要付出高昂代价才能解决代码错误的可能性就会越来越小。

就书中例子，作者提出了两点：

1、清除不必要的局部变量。

2、清除之前到处出现的字符串。在代码中到处嵌入字符串被视作不良的编程习惯。（原因之一是 如果每个字符串所代表的意义不清晰的话，将很难理解这样的代码。）

3、对之前的字符串采取重构，即 用字符串常量来代替字符串。

开发循环：

1、编写一个小的测试，来断言某些功能正确与否。

2、运行测试，如果结果失败。

3、编写代码，是测试能通过。

4、重构测试和代码，清除重复的概念。确保代码富于表现力。

这样的循环很快会成为一种自然、根深蒂固的开发流程。

文中还提到了 命名约定、驼峰模式，大写驼峰模式。我想起了之前翻看windows程序设计时候的匈牙利命名法。我觉得作者也将命名放在了一个高度，让我了解到了，贯穿第一章的”确保代码富于表现力“。作者说道，”一个设计良好的类，处理一件重要的事情，且仅仅处理一件重要的事情。 类通常不用来处理多个事情。例如，如果有一个类被用来切割支票，打印支票报表，计算不同部门的退款，那么提出一个名字来简介地描述这个类是非常困难的。相反，应该把这个类分开成桑格独立的类：CheckWriter、 PayrollSummaryReport、CheckBackCalculator。“

除此之外，作者还提出了很多观点。比如避免使用下划线、避免缩写等等。

第一章，已经获益良多。