《程序员修炼之道——从小工到专家》阅读笔记*part3

 

曳光代码并非用过就扔的代码：你编写它，是为了保留它。它含有任何一段产品代码都拥有 的完整的错误检査、结构、文裆、以及自査。它只不过功能不全而已。但是，一旦你在系统的各组件间实现了端到端（end-to-end) 的连接，你就可以检査你离目标还有多远，并在必要的情况下进行调整。一旦你完全瞄准，增加功能将是一件容易的事情。曳光开发与项目永不会结束的理念是一致的：总有改动需要完成，总有功能需要增加。这是一个渐进的过程。

 

曳光代码方法有许多优点：

1.用户能够及早看到能工作的东西

2.开发者构建了一个他们能在其中工作的架构

3.你有了一个集成平台

4.你有了可以演示的东西

5.你能够感觉得到工作进展

 

领导在询问进度时，你就不用说，正在规划中，你可以给他看这个，表明项目正在有条不紊的进行中。如果只是一味的策划，计算，花费大量时间最后进行尝试，如果失败或者偏离目标，那么还得更改数据甚至重新测试分析。通过曳光弹代码，你可以一点一点的改进，并非一下就命中，尝试嘛，总是一点一点前进的。只要勇于尝试，多动手，总比一直动脑强。

 

 

 

 

估算也是有学问的事情。当询问进度时，尽量不要太模糊不清。

 这是比较理想的估算方法。估算，使开发变得有约束，而不是三天打鱼两天晒网。

以下是第一、二章的小tip：

1.关心你的技艺 Care About Your Craft
如果你不在乎能否漂亮的开发出软件，你又为何要耗费生命去开发软件呢？

2.思考！你的工作 Think! About Your Work
关掉自动驾驶仪，接管操作。不断地批评和评估你的工作。

3．提供各种选择，不要找蹩脚的借口 Provide Options, Don’t Make Lame Excuses
要提供各种选择，而不是找借口。不要说事情做不到；说明能够做什么。

4.不要容忍破窗户 Don’t Live with Broken Windows
当你看到糟糕的设计、错误的决策和糟糕的代码时，修正它们。

5.做变化的催化剂 Be a Catalyst for Change
你不能强迫人们改变。相反，要向他们展示未来可能会怎样，并帮助他们参与对未来的创造。

6.记住大图景 Remember the Big Picture
不要太过专注于细节，以至忘了查看你周围正在发生什么。

7.使质量成为需求问题 Make Quality a Requirements lssue
让你的用户参与确定项目真正的质量需求。

8.定期为你的知识资产投资 Invest Regularly in Your Knowledge Portfolio
让学习成为习惯。

9.批判地分析你读到的和听到的 Critically Analyze What You Read and Hear
不要被供应商、媒体炒作、或教条左右。要依照你自己的看法和你的项目的情况去对信息进行分析。

10.你说什么和你怎么说同样重要 It’s both What You Say and the Way You Say it
如果你不能有效地向他人传达你的了不起的想法，这些想法就毫无用处。

11.不要重复你自己 DRY - Don’t Repeat Yourself
系统中的每一项知识都必须具有单一、无歧义、权威的表示。

12.让复用变得容易 Make It Easy to Reuse
如果复用很容易，人们就会去复用。创造一个支持复用的环境。

13.消除无关事物之间的影响 Eliminate Effects Between Unrelated Things
设计自足、独立、并具有单一、良好定义的目的的组件。

14.不存在最终决策 There Are No Final Decisions
没有决策是浇铸在石头上的。相反，要把每项决策都视为是写在沙滩上的，并为变化做好计划。

15.用曳光弹找到目标 Use Tracer Bullets to Find the Target

曳光弹能通过试验各种事物并检查它们离目标有多远来让你追踪目标。

16.为了学习而制作原型 Prototype to Learn
原型制作是一种学习经验。其价值并不在于所产生的代码，而在于所学到的经验教训。

17.靠近问题领域编程 Program Close to the Problem domain
用你的用户的语言进行设计和编码。

18.估算，以避免发生意外 Estimate to Avoid Surprises
在着手之前先进行估算。你将提前发现潜在的问题。

19.通过代码对进度表进行迭代 Iterate the Schedule with the Code
用你在进行实现时获得的经验提炼项目的时间标度。