程序员修炼之道

培养估算能力

  微信入群一块学习技术：Day9884125
  我认为记录下你做过的估算是一个好主意，这样可以看到做过的估算的准确程度。如果一个全面评估涉及到多项次级评估，那么也要记录这些次级评估。你会时常发现，估算的还是挺准确的------事实上很快你就会觉得理应如此。

  当估算错误的时候不要耸耸肩走开。找出为什么结果偏离了你的猜想。也许是选择的一些参数与问题的实际情况不匹配，没也许是模型出错。不管是什么原因，都要花点时间去查出到底怎么回事。只要这样去做，下一次的估算就会更好。

估算项目进度

  一般你会被要求估计完成某件事需要多长时间。如果这件事情很复杂，那么估算起来就很难。在本部分中，我们将研究两种减少不确定性的技巧。
粉刷导弹
  粉刷房子要多长时间？
  嗯，如果一切顺利，而且这种油漆有广告上说的那么好用，可能只要10小时。但恐怕做不到：我猜一个更现实的数字是接近18小时。当然，如果天气变坏，可能会推延到30小时以上。

  这就是人们在显示世界所做的估算，他不会仅有一个数字（除非你强迫他们给你一个数字），而是由一系列的预案构成。

  当美国海军需要计划北极星潜艇项目时，他们采用了这张评估方法，并称之为计划评审技术。

  每个计划评审技术都有一个乐观的、一个最有可能的和一个悲观的估算。任务被排列进一个互相依赖的网络中。然后使用一些简单的统计方法来确定整个项目可能的最佳和最差时间。

  向上面这样使用一个带范围的值是一个好方法，他能避免最常见的那些导致估算错误的因素：因为不确定而随便填一个数字。相反，计划评审技术背后的统计数据为你分散了不确定性，使你能够更好的估算整个项目。

  然而，我们对此兴趣不大。人们倾向于为项目中所有任务做一面墙那么大的图表，并潜在的相信，仅仅因为使用了一个公式，就能得到一个准确的估算。这不太可能成功，因为迄今为止从未有人如愿。

select没出问题

  记住，如果你看见了马蹄印，应该联想到马，而不是斑马。操作系统不大可能出错，select也多半没问题。

  如果你改变了一个东西，然后系统就不工作了，那么这个东西就最可能直接或间接地负有责任，不管看起来多么牵强。有时改变的东西超出了你的控制范围：更新操作系统、编译器、数据库或其他第三方软件的版本，可能会破坏以前正确的代码，因而出现新bug。之前发现bug，你会想办法绕过去，但当这些bug被修复后，你当初绕过bug的方案不能用了，API改了，功能变了；简而言之，这是一个全新的局面，你必须在这些新的条件下重新测试系统。因此，在考虑升级时，请密切关注时间表；有时等下一次发布之后再做升级也许更合理。

让人吃惊的元素

  当你发现自己被一个bug吓一跳时，必须重新评估你一直笃信的真理，在一个计算折扣的算法中，你坚信此处无懈可击，绝不可能导致这样的bug，但你测试了所有的边界条件吗？那段使用很多年的代码，不可能还有bug------真的不可能吗？

  当然有可能。出错时受到惊吓的程度，与对正在运行的代码的信任程度成正比。这就是为什么，当面对一个让人吃惊的错误时，必须接受之前的一个或多个假设是错误的。不要因为觉得一个程序或一段代码没问题，就在它牵涉一个bug时，对它视而不见。你需要证明它没问题，用出bug时的上下文、同样的数据、当时的边界条件来证明它没问题。

不要假设，要证明

  当你遇到一个意外的bug时，除了修复它，还需要确定为什么没有更早的发现这个错误。考虑一下，是否需要修改单元测试或其他测试，以让这些测试能够捕获到它。

  同样，如果bug是损坏的数据造成的结果，而数据引爆程序前经过几层逐级传播，可以试试给函数加上更完备的参数检查，以便更早的将问题剥离出来。

需求之坑

所谓完美境界，亦非加无可加，而是减无可减
----安托 德圣埃克絮佩里

  许多书籍和教程都将采集需求放在项目早期阶段。采集意味着需求已经在那里了，但事实并非如此，需求很少停留在表面。通常他们被埋在某些原因之下。更糟糕的是，需求通常根本不存在。

携手共建

  我从来没有见过有人想读17000页的文档。如果有这么一个人。我会杀了他，将他从基因池中抹去。
-----约瑟夫 科斯特洛

  与用户密切合作的建议贯穿该书。用户是你团队的一部分。在共同工作的第一个项目中，我们一起实践了现在被称为结对编程或群体编程的方法：一个人输入代码，而一个或多个团队成员一起评论、思考和解决问题。这是一种强大的合作方式。超越了没完没了的会议、备忘录和冗长的法律文件。

  这就是我们说的“一起工作”的真正含义：不仅仅是提问、讨论、做笔，还要在真正编码的同一时刻提问和讨论。

我该做什么

  如果你目前在个人独立编程，可以尝试一下结对编程。最少预留两周的时间，一次持续几小时，因为一开始会感觉怪怪的。在需要集思广益、想出新点子，或诊断出棘手问题的时候，不妨尝试做一次集体编程。

  如果你已经在做结对或群体编程，是和谁一起做？仅仅是开发者，还是允许用户、测试人员、赞助者等周边团队的成员参与？

  与所有合作性事务一样，你需要对人的方面如同对技术方面一样有所把控。这里有一些用来启动的小技巧：

• 打造代码，而非打造自我。这与谁最聪明无关；我们都有许多闪光的瞬间，也有糟糕的时刻。
• 从小规模做起。只需要4-5人的群体，或者开始时只组成几对，做一些短期活动
• 批评要针对代码，而不针对人。"让我们看看这一块"听起来比"你搞错了"好的多。
• 倾听他人的观点并试着理解。观点不同不是错误。
• 频繁进行回顾，为下一次做好准备

  不管是在同一个办公室还是远程合作，不管是独立还是结对或群体编程，都是通过共同工作解决问题的有效途径。如果你和团队只用过其中一种形式，那么可能会想尝试一些不同种类。但是，不要天真地直接开干：每种开发风格都有规则、建议和指导方针。例如，在群体编程中，每隔5-10分钟就需要换一次打字员。

  做一点阅读和研究。从课本和经验报告中，感受一下可能取得的优势和遭遇的问题，你可能希望从一个简单的练习开始，而不是直接跳到最难的产品代码。

敏捷的本质

你一直在用那个词。我认为它并没有表达出你想的那个意思。
--------埃尼戈 蒙托亚
  敏捷是一个形容词：它指向你做事情的方式。你可以成为一名敏捷的开发人员。你可以加入一个采用敏捷实践的团队，一个对变化和挫折做出敏捷反应的团队。敏捷指你的风格，并不指你这个人。

敏捷不是一个名词，敏捷有关你如何做事

  在该文章书写的时候，敏捷软件开发宣言已经诞生近20年了，我们看到敏捷的价值在很多开发人员的身上成功体现，也看到很多优秀团队在获取和利用这一价值上颇有心得，包括指导所做的事情，以及指导如何对所做的事情加以改变。

  然而我们也看到了敏捷另一面-----很多团队和公司渴望现成的解决方案：让敏捷开箱即用。他们想要的这个东西也是很多咨询公司和咨询师很乐意推销的。结果这些公司采用了更多层的管理、更正式的报告、更专业的开发人员和更花哨的岗位头衔，这类头衔的背后其实就是一些"拿着笔记板和秒表的人"。

  我们觉得很多人已经忽视了敏捷的真正含义，因而希望看到人们回归最基本的东西。

记住宣言中的价值观：

  我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人，因此建立了如下价值观：

• 个体和互动高于流程和工具
• 工作的软件高于详尽的文档
• 客户合作高于合同谈判
• 响应变化高于遵循计划
  也就是说，尽管右项有其价值，我们更重视左项的价值。

  如果有人向你兜售一些东西，而这些东西让你觉得右边的事情比左边的事情更重要，那么这样的人，对于我们和其他宣言作者重视的东西，显然不会认同。

  任何向你推销开箱即用方案的人都没有读过这份介绍性声明。这些价值观，是由不断发现更好软件生产方法的行为。所激发和显露出来的。这不是一份静态的文档，他是对生产过程的建议。

永远不可能有一个叫敏捷的工艺流程

  事实上，无论什么时候有人说，这么干，你就敏捷了，显然都是错的。

  因为无论是物理世界中的敏捷，还是软件开发中的敏捷，谈的都是对变化的响应，对开始后所遇到的未知事情做出的响应。

  无论是对团队还是对个人开发者，都是如此。在开发软件时，并没有单一的计划可以遵循。在敏捷宣言四条价值观中，有三条谈的都是这一点，都是关于收集和回应反馈的。
共同探讨学习技术创建技术氛围Day9884125