《一次做好一件事》由会员分享，可在线阅读，更多相关《一次做好一件事（24页珍藏版）》请在金锄头文库上搜索。
1、4336第三章一次做好一件事吃大象只有一种方法：一次咬一口。这同时也是写程序的最好方式。每一口干净、简单的 Java 代码都只能有单一的目的。最好的 Java 程序员任何时刻都会疯狂地专注于单一问题上。如果你想要进步，就仿效他们。我是个喜爱白浪泛舟的人。长久以来我都会在面对激流时四处观察。我可以看出怎样才能穿越一个瀑布或者陡降的河面，然而，我无法在脑海中将这些路径拼结在一起，以便让我安全地穿越Little River上的Humpty-Dumpty那一段，或者Arkansas的Pine Creek四分之一英里处的地方。在 Tennessee 的 Watauga River 时突然间灵光乍现，我了
2、解到我是无法在路线中胸有成竹地跳进第四级激流。相反的，我只能在激流中找寻突破点。我学会在水上判读河流并寻找天然成型的休憩处。然后我就能征服一段、重整、再进攻下一段。当我如此解决问题时，反而有意外的收获。写程序对我来说也是这样：把大问题清楚地分段定义会比整个一起定义还要容易。 我们都会倾向于对大问题感 到不知所措，但是对好几个小问题就不会这么不安了。不管在水面上还是键盘背后，我们的大脑就是这么运作的。当事情出错时，若计划是分段的，会比较容易调整和修改。当计划改变时，改变大 型计划会比改变数个小计划要困难的多。你可以让自己远离灾难。在水面上，我会将一次安全计划归为一小段。写程序时，我一定会建立测试
3、用例，用于在每个逻辑段中快速的发掘问题。你能够更好地重用技术与代码。 在水面上， 我学会了可以用在别的地方的技法。 相 对于冲动地划过河段， 我会抽桨回来以避开岩石、 再奋力一划以穿越高速逆流。 写程序时， 我学会了将问题分解成更小更普通的问题。 每个在问题中学到的设计模式抵得上看书得来的 20 个。第三章4437不论你是挑战第五级激流的泛舟人， 还是太空站上的物理学家，还是处理一堆问题的程序员，所用的方法应该都异曲同工。了解问题你必须了解问题才能很好地解决问题。 有效的程序设计方法位于编辑器与调试程序之上。 你必须能够准确地搜集需求， 并控制客户所需要的规模。 没有什么事情比没有问题的答案更
4、糟；那只会产生更多的问题。提取问题的本质大家都说程序设计比较像是门艺术而不是科学。 这在有能力穿越一团迷雾找到问题核心时是显而易见的事实。 你必须分辨出什么是跟你的问题有关， 而什么是你可以另行解决的。通常，少即是多。框架层次化如果你能以每次专注一件事来解决一个困难的问题， 那你一定把框架给层次化了，让每个层次处理一项任务。应用最广、最成功的设计模式能够帮助你构建出有效的、解耦的层次。Model-View-Controller 让你以三层的组件来设计用户接口。表示层能让你构建应用程序的两个主要层次之间的干净接口。 假如你想要研究设计模式，那么，需要弄清楚这种主题出现的频度。周期性地改进你的方法
5、软件会随着时间而黯然失色。 你必须专注于将你的软件重构、 解耦成自给自足的层次。 自动测试将帮你自信地重构， 并在一开始就设计松耦合的程序。 经常从同伴与用户处取得反馈意见，将确保方法能正确地解决问题。在这一章中， 我们会探索这些概念的细节。 你无须全部读完才会有不一样的收获 每个技巧都能各自让你获益。但它们的组合会让你倍加受益。了解问题沟通是程序设计的重点。如果构建对象出错，写再好的Java也不会有什么用处：动手前先了解问题。 在你的程序设计工作生涯更上一层楼时，你会发现有效的沟通在工作中的要求越来越高。需求从何而来并不重要 你的团队领导人、分析员或者客户。在每种情况下， 你的首要任务都是精
6、确地搜集每项需求， 并且让客户专注于你利用现有资源可以合理地成就什么。 别用大量的需求与难懂的设计文档来压倒客户。 如果客户不能理解你的文档，他们就无法专注于真正的问题上。就像你的代码一样，也要保持需求简单与轻捷。45一次做好一件事38如果你不喜欢沟通， 我有件事情要跟你说： 事情在改善之前会变得更糟。 在全球经济下，你得讲究效率。这代表开发者必须处理越来越多的开发过程。 离开学校后我曾经为全球最大的软件公司工作过。我们曾在一个项目上用的测试人员比写程序的人还要多（通常比例为 1 比 3） ，并用一组十个人的规划团队来支援 40 名开发者。全部加起来有 200 多个开发者。 如今相同的项目大约
7、会用到10个开发者和一半的时间。 因为有更好的自动化与单元测试，现代的开发者必须承担更多的测试重任。 写程序的人也有比以前更多的设计与规划工作。然而经验显示， 许多开发者并没有准备好来承担加在他们身上的规划与分析任务。搜集需求如果我们没有谈到有关于从过程角度看待改变这一件事情的话， 那就无法对本书读者做交代。如果你也打算要尝试如何事半功倍，你需要在规划过程中做两件事情：首先，排除对最终项目没有什么贡献的软件需求；其次，消灭支持传统开发但对于整体内容或程序质量没有好处的不必要工作。许多程序员相信他们需要像类图或对象交互图这些面向对象设计文档才能进行开发工作。这种方法的危险性在于你可能会花太多时间
8、维护设计文档， 而没有足够的时间来构建可行代码。最好的设计资源是轻量化的需求清单、可行代码与现场客户。需求文档通常是由比一行多一点点的项所组成，每项都是花比半天至数天还少的时间完成的。通常你不需要正式的项目管理软件。我曾经以昂贵的项目管理工具、文字处理器与电子表格来管理需求。低科技通常比高科技做得还好。控制规模变更一旦搜集到需求，你会想要维持可管理的规模。我通常花很多时间在客户端，以加强沟通与了解。目前为止，我所遇到的最大问题来源于对项目的规模和期望的控制。通常，权力来自预算， 所以对那些有权力的人来说， 增加不管要不要用的功能是很有吸引力的。生产力与变更之间是有弹力的。 许多团队之所以成功是
9、因为它们能够适应迅速改变的需求， 但同样有许多项目失败是因为团队无法恰当地控制规模。 这是软件开发的核心问题。有效地进行软件开发就是要成功地解决这个问题。管理良性变更迭代开发之所以有效，其部分原因是它能让你适应。但不管你使用哪种开发过程，你的客户都必须了解变更的整体成本。 你不能在每次有人要求重大改变时就拿出球棒扁他们第三章4639一顿。你必须接受但要坚持。你的第一回答应该像是： “我们会照办。但先让我来告诉你这要花多少成本。 ”这种反应会立即给你的客户以正面反馈，而且也会让他们知道此变更会对项目的整体成本造成多少影响。客户是谁不重要。 不管这是内部项目还是外包的， 某些事情永远不会改变： 开
10、发是要花财力、 物力和人力的。 一份资源只能做一份事。图 3-1 展示出你对扩大需求的三种反应：1.放弃本次发布尚未实现的相同成本项来降低规模。2.延长项目时间：要求更多的时间与更多的钱。3.增加人力：要求更多的钱，并扩充你的团队。项目新的规模人力时间123图 3-1：应对扩展的需求你也可以将这些选项组合运用。第一个方法是目前最好的。 注意到延长时间是个不切实际的选项。严重逾期代表项目经理在瞎搞。 （越来越多开发者兼职从事项目经理！）严重逾期通常会导致缺陷、错误与懈怠这些成本更高的症状。你也不应该增加人力。除非你真的是人力不足，不然对刚好的团队加人只会牺牲掉效率，甚至会加重项目的延期。进度的冲
11、突也会产生问题。如果你的进度经常落后，你也是在降低对客户的价值，这通常不会是个好主意。现在， 最能接受的只剩下把其他功能放在下一版再说这种交换代价上。如果你经常与客户进行这种有益的讨价还价， 习惯之后他们就会了解什么对他们才是最重要的，而你也不会违背所做过的承诺。47一次做好一件事40减少破坏性变更能够对客户做反应是相当重要的，但并不是每个变更都是良性的。 破坏性的变更会让你一直无法交货， 而还在实验室的代码对客户一点用处都没有。 破坏性的变更有多种形式：未检验的规模变更会很快地让任何项目脱轨。 你必须要有意识地调整规模， 并对你 的团队和进度产生最少破坏。这通常意味着要放弃一些功能。与项目核
12、心目的无关的变更会降低专注。 这类的破坏性变更通常较多用在处理基础 框架与中间件而不是最终应用程序本身。 例如， 我就看过客户将消息系统构建到持久化框架中， 或将业务逻辑构建到用户接口中。 这类短期的折衷方案通常会倒打一耙。在正常发布进度之外的变更会破坏团队， 并且发生在迭代后期的变更 （例如在代码 冻结之后） 特别具有杀伤力。 一般来说， 你会以缩短迭代而不是把不自然的迭代硬塞到进行中的迭代中来提升变更能力。 图3-2展示了开发周期过程中每个步骤上发生改变时的成本。 在迭代性的开发过程中， 变更成本的特征就是锯齿状的样式。 让客户等待下个迭代是比较好的方式。设计编码测试部署设计编码测试部署图
13、 3-2：在每个周期末，尤其是代码冻结期，变更的代价更大一般来说，某几种类型的变更会产生比其他类型更多的混乱：后期变更、巨大变更与转移焦点。实际情况是你遇到变更时，除非你同时具有纪律与好运气，否则你就得处理一些后期的变更。本章与本书接下来的部分都是在讨论适应变更。抽出问题各个专业领域中的大师都有共同的天赋： 他们可以从问题中抽出基本组件。 在物理学上，爱因斯坦发现和掌握了一个简单等式中许多复杂的关系。贝多芬的第五交响曲中由4个音符组成的重复旋律已经赢得了数个世纪的赞叹。程序设计也需要同样的专注。你会分辨出一组需求中的基本元素、排除掉不相关的部分、最后突破并解决问题。第三章4841要提升你的程序
14、设计功力， 你不必隐匿山林研读涵盖各种可能性的设计模式。你不需要知道最新、最热门的框架。你只要专注于正确的问题，抽出基本元素，找到可用的最简单解法就可以了。在这一节中，我会针对一组需求抽出核心，并将其转换成代码。收集需求让我们看个简单的例子。 假设你要构建一个ATM。 你的工作是要支持一个账户。 为了采用敏捷程序设计原则，你决定用表格来保存一组简单的需求。你会记录下需求编号、简短说明、规模（时间） ，并选择一个程序员。因为你的团队很小并且时间很短，所以你认为这样就足够了。表 3-1 展示基本的需求。表 3-1：账户项目的需求编号说明规模（小时）指派给1维护账户与账号2汇报存款不足3使用 6 位
15、数账号4不让用户改变账号5用户再来时要记住余额6让用户存款7让用户取款8显示余额9显示借贷按钮10操作完成后显示余额11保证账户安全12显示银行标志13清爽的配色14让用户打印余额15确定用户输入 4 位数密码16让用户插入银行卡17应该为事务型的（全部完成或全部失败）这些都是你从客户处所取得的典型需求。这离完成还早，但是这很正常。撰写需求文档的工作是要让你在累积需求的同时更好地了解你的应用程序。 此时，你是惟一被赋予这49一次做好一件事项工作的人。稍后你会评估任务规模。这个时候你应该要专注于手上的问题。你的工作是构建出对账户的支持。消掉噪音你的第一项工作是要消除掉噪音。将任何可合并到其他地方
16、的问题推开。 你很快就会发现应该将用户界面与基础账户分离。你也可以明白支持存款意味着账户是持久的。 你将会使用关系数据库。安全性或许不属于账户本身；把它留给框架中的其他层次来处理可能会比较好，或许是表层，但安全性也是个特殊的情况。太多数开发者会将安全性当成后面再处理的事情，它可以在应用程序上洒一点就能做到“安全” 。但是这种魔法配方并不存在；安全层应该和其他的事物同等看待。基本上，你需要构建一个持久账户。与其尝试去写设计文档，不如从写程序开始。这个问题不大，并且你随时可以重构。事实上，你或许会在思考简单化方式与改善设计的过程中重构好几次。最新的一组需求显示在表 3-2 中。表 3-2：消除掉杂音的需求编号说明规模（小时）指派给1维护账户与账号2BT2汇报存款不足1BT3使用 6 位数账号1BT4不让用户改变账号1BT5用户再来时要记住余额4BT6让用户存款1BT7让用户取款1BT17应该为事务型的（全部完成或全部失败）?BT要记住你想完成什么。你不是要抛弃掉其余的任务；你仍然需要安全性和用户界面。相对而言，你首先想要做的是分离出可管理规模的开发。当这些完成并测
