【读书笔记】高效程序员的45个习惯——第四章交付用户想要的软件

本文链接：https://blog.csdn.net/SMonkeyKing/article/details/89819086

10、让客户做决定

在设计阶段，做决定的时候必须有开发者的参与。但是，在一个项目中，他们不应该做所有的决定，特别是业务方面的决定。

开发者（及项目经理）能做的一个重要决定是：判断哪些是自己决定不了的，应该让企业主来做决定。你不需要自己给业务上的关键问题做决定。毕竟，那不是你的事情。如果遇到一个文图，会影响到系统的行为或者如何使用系统，把这个问题告诉业务负责人。如果项目领导或经理试图全权负责这些问题，要委婉得劝说他们，这些问题最好还是和真正的业务负责人或者客户商议。

当你和客户讨论的时候，备好几种可选择的方案。不是从技术的角度，而是从业务的角度，介绍每种方案的优缺点，及潜在的成本的利益。和他们讨论每个选择对时间和预算的影响，以及如何权衡。无论他们作出什么决定，他们必须接受它，所以最好让他们了解一切后再做决定。如果事后他们又想要其他的东西，可以公正的就成本和时间重新谈判。毕竟，这是他们的决定。

记录客户做出的决定，并注明原因。好记性不如烂笔头。可以使用工程师的工作日记或日志、wiki、邮件记录或者问题跟踪数据库。但是要注意，你选择的记录方法不能太笨重或者繁琐。
不要用过于具体和没有价值的问题打扰繁忙的工作人员。如果问题对他们的业务没有影响，就应该是没有价值的。

11、让设计指导而不是操纵开发

设计满足实现即可，不必过于详细

设计可分为两层：战略和战术
前期的设计属于战略，通常只有在没有深入理解需求的时候需要这样的设计。它只描述总体战略，不应该深入具体细节
良好的战略设计应该扮演地图的角色，指引你向正确的方向前进。任何设计仅是一个起跑点，它像你的代码一样，在项目生命周期中，会不停地进一步发展和提炼。

战术设计的重点是集中在单个的方法和数据类型上。在战术设计时讨论如何设计类的职责。
使用CRC（类-职责-协作）卡片设计方法，每个类用下面术语描述
类名
职责：它应该做什么？
协作者：要完成工作它要和其他什么对象一起工作？

好设计是一张地图，它也会进化。**好的设计应该是正确的，而不是精确的。**它描述的一切必须是正确的。不应该涉及不确定或者可能发生变化的细节。它是目标，不是具体的处方。

不要在前期做大量的设计，并不是说不要设计。只是说在没有经过真正的代码验证之前，不要陷入太多的设计任务。当对设计一无所知的时候，投入编码也是很危险的。如果深入编码只是为了学习或者创造原型，只要你随后能把这些代码扔掉，那也可以。

12、合理地使用技术

盲目地为项目选择技术框架，就好比为了少交税而生孩子

在考虑引入新技术或者框架之前，先要搞清楚你要解决的问题。你的表达方式不同，会让结果有很大差异。如果你说：“我们需要xx技术，是因为…”，那就不太靠谱，你应该这样说：“…太难了”或者“…花费的时间太长了”或者类似的句子。

找到了需要解决的问题，接下来要考虑：

这个框架真的能解决这个问题吗？
你确定它真的解决这个问题吗？你是如何评估这项技术的？是通过市场宣传还是道听途说？
你将会被他拴住吗？
有些技术像贼船，会被套牢。缺乏可取消行性。
维护成本是多少？
会不会随着时间的推移，它的维护成本会非常昂贵？
不要开发你能下载到的东西。虽然优势需要从最基础开发所有你需要的东西，但那是相当危险和昂贵的。

根据需要选择你的技术。首先决定什么是你需要的，接着为这些具体的问题评估使用技术。对任何要使用的技术，多问一些挑剔的问题，并如实的回答。

新技术就应该像是新的工具，可以帮助你更好地工作，它自己不应该成为你的工作。

13、保持可以发布

任何时候只要你没有准备好，那就是敌人进攻你的最佳时机。
已提交的代码应该可以随时行动

在团队里工作，修改一些东西的时候必须很谨慎，你要时刻警惕，每次改动都会影响系统的状态和整个团队的工作效率。

下面是一个简单的工作流程，可以防止你提交破坏系统的代码
**在本地进行测试。**先保证你完成的代码可以测试，并且能通过所有的单元测试，接着确保系统中的其他测试也可以通过
检出最新的代码。从版本控制系统中更新代码到最新版本，再编译和运行测试。这个过程中可能会出现其他人提交的代码和你的代码发生冲突，要解决冲突。
**提交代码。**现在是最新的代码了，并且通过了编译和测试，你可以提交了。

以上这个过程应该要有一个持续集成系统，可以自动集成并报告集成结果。

14、提早集成，频繁集成

绝不做大爆炸式的集成
代码集成式主要的风险来源。要想规避这个风险，只有提早集成，持续而有规律地进行集成。
平均每天5-10次，甚至更多。

15、提早实现自动化部署

系统能在你的机器上运行，或者能在开发者和测试人员的机器上运行。同时也需要能够部署在用户的机器上。系统除了运行在开发服务器上，同时也要运行在生产环境中。这就意味着，你要用一种可重复和可靠的方式，在目标机器部署你的应用。
质量保证人员应该测试部署过程

从第一天起就开始交付，一开始就进行全面部署，而不是等到项目的后期，这会有很多好处。事实上，有些项目在正式开发之前，就设置好了所有的安装环境。

系统的安装或者部署应该简单、可靠和可重复，一切都很自然。

16、使用演示获得频繁反馈

需求就像是流动着的油墨。你无法冻结需求，正如你无法冻结市场、竞争、知识、进化或者成长一样。
没有人的思想和观点可以及时冻结，特别是项目的客户。就算是他已经告诉你想要的东西了，他们的期望和想法还是会不停地进化——特别是当他们在使用新的系统的部分功能时，他们才开始意识到他的影响和可能发生的问题。这就是人的本性。
作为人类，不管是什么事情，我们都能越做越好，不过是以缓慢而逐步的方式。

我们经常看到，给客户演示所完成功能的时间与得到客户需求的时间间隔越长，那么你就会离最初的需求越来越远。
应该定期地，每隔一段时间，例如一个迭代的结束，就与客户会晤，并且演示你已经完成的功能特性。
如果你能与客户频繁协商，根据他们的反馈开发，每个人都可以从中受益。

演示是用来让客户提出反馈的，有助于驾驭项目的方向，如果缺少功能或者稳定性的时候，不应该拿来演示，那只能让人生气。可以提早说明期望的功能，让客户知道，他们看到的是一个正在开发中的应用，而不是一个最终已经完成的产品。