高效程序员的45个习惯

第三章 学无止境

从事软件开发行业就像在跑步机上，你必须一致跟上步伐稳步前进，否则就会摔倒出局。

往往大家觉得淘汰就是默默无闻的出局，实际对出局的具体事物而言，往往是惊天动地，只是大家把目光投入了新事物而忽略了被淘汰者的惨烈。

学无止境，时刻关注新技术，那么每天都是迭代式进步，不会一下子发现物是人非。如果不能够持续迭代，那么就会发现“少小离家老大回，物是人非事事休”。
学无止境不尽强调了对新事物的学习，还要勇于抛弃不合适的旧实物。

3.1 跟踪变化

如何跟踪变化
-迭代和增量式学习。每天计划用一段时间来学习新事物，不需要占用很长时间。当你听到一些不熟悉的数据或者短语时，简要地记录下来，然后在计划的时间内深入研究它。
-了解最新行情。1）关注社区在讨论什么问题；2）关注优秀博客的解决方案；3）了解顶尖人物关注什么。
-参加本地的用户组活动。
-参加会议研讨。
-如饥似渴地阅读。
-跟踪技术变化。不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。

关注行业信息非常重要，这可以看做是一种背景调研，能够从宏观方面让你把握住问题的根本。

跟踪变化时，需要平衡新技术的使用。不能盲目的引入新技术和新框架。在使用前，最好开发一个小的原型系统。

3.2对团队投资

不要怕团队里面的人比自己优秀，和优秀的人一起共事才会让自己优秀。
团队内分享的时候也可以是敏捷的。坚持有规律的举行讲座。持续、小步前进才是敏捷。稀少、间隔时间长的马拉松式会议非敏捷也。

3.3 懂的丢弃

学无止境提醒你不仅要学习新知识，而且还要果断丢弃旧习惯，已有的技能和习惯为你打下了很好的基础，但是不能依赖他们。
但是也不要完全丢弃，需要有选择的丢弃。

3.4 打破砂锅问到底

这个是一个有挑战的点，尤其在自己不熟悉的领域。但是坚持不懈的问为什么，可以帮助别人理清楚思路，但是这个具体操作中很考验人的情商，不然可能就事与愿违了。
而且，在问为什么的过程中，需要先思考。防止跑题——汽车无法发动，你问轮胎的原因，以及被别人反问为什么。

3.5 把握开发节奏

许多的敏捷技巧来源于时间盒——设定一个短时的期限，为任务设定不能延长的最终期限。你可以选择放弃其他方面的任务，但是最终期限是不变的。你可能不知道完成所有的任务需要多少个时间盒，但每个时间盒必须是短期的，有限的，并且要完成具体的目标。

事情可以做不完，但是截至时间是不变的。这种说法表明在排期的时候需要对任务按优先级做取舍，而不能为了完成任务导致期限无限制的延长。

开发节奏里面每次迭代的时间统一很重要。运用有规律的开发节奏，会更容易达到目标，并确保项目不停的前进。

第四章 交付用户想要的软件
4.1 让客户做决定

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

第一，要不要如实提供各种方案。不同的方案实现成本不一样，面临的挑战也不一样。

2.记录客户做出的决定，并注明原因。好记性不如烂笔头。可以使用工程师的工 作日记或日志、Wiki、邮件记录或者问题跟踪数据库。但是也要注意，你选择 的记录方法不能太笨重或者太繁琐。

必要的记录非常重要。1、和别人交接、谈论的时候都有据可查；2、防止互相扯皮的情况出现。

3.不要什么事情都问业务人员。要做好范围隔离。

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

画关键工作图(例如，用UML) 是必不可少的，因为要使用类及其交互关系来描绘系统是如何组织的。在做设计的时候，你需要花时间去思考(讨论)各种不同选择的缺陷和益处，以及如何做权衡。

主要是从宏观上入手，去做权衡。包括背景调研等。但是此时的设计文档是基于你对需求的理解，并不是最终产物。

设计可以分为两层:战略和战术。前期的设计属于战略，通常只有在没有深入理 解需求的时候需要这样的设计。更确切地说，它应该只描述总体战略，不应深入 到具体的细节。
战略级别的设计不应该具体说明程序方法、参数、字段和对象交互 精确顺序的细节。那应该留到战术设计阶段，它应该在项目开发的时候再具体展 开。
良好的战略设计应该扮演地图的角 色，指引你向正确的方向前进。任何 设计仅是一个起跑点:它就像你的代 码一样，在项目的生命周期中，会不停地进一步发展和提炼。
好的设计是一张地图，它可以进化。好的设计应该是正确的，而不是精确的。
即使初始的设计到后面不再管用，你仍需设计:设计行为是无价的。正如美国 总统艾森豪威尔所说:“计划是没有价值的，但计划的过程是必不可少的1。” 在设计过程中学习是有价值的，但设计本身也许没有太大的用处。

4.3 提早集成，频繁集成

频繁集成的好处是可以及早发现问题，在问题还小的时候就发现，趁早发现问题。不能让两个庞然大物进行融合。

4.4 及早实现自动化部署

目前没有太深感触，公司基础设施好，基本上都是自动化部署。

4.5 使用演示获得频繁反馈

产品或者客户也是人，需要不停的迭代成长，所以不会存在一次提出就不会改变的需求。及时的向他们演示，可以及早发现问题，修正问题。
在项目开发过程中，统一术语很重要。有了完整一致的术语，才能够畅通交流。

4.6 使用短迭代，增量发布。

发布最小可用功能块的产品，每个增量开发中，使用1~4周左右迭代周期。

4.7 固定的价格就意味着背叛承诺

本身这个点是讲报价的。但是感觉在和产品经理谈、评价项目周期的时候也适用。如果规划太长，那么评估的时间就越不准。当时间评估不准的时候，可能会被压缩评估时间，此时就更不行了。

感兴趣的可以自己来我的Java架构群，可以获取免费的学习资料，群号：855801563 对Java技术，架构技术感兴趣的同学，欢迎加群，一起学习，相互讨论。