流程方法

这篇文章来源于Peter Sergeant在Write More Test 博客上的《Test-Driven Development? Give me a break…》，在原文和Reddit 上有很大反响。这篇文章里的很多观点在《TDD并不是看上去的那么美》和《再谈敏捷和TW咨询师》里都出现过（我个人觉得我的观点比其更全面一些）。就像我转的《Scrum为什么不行》 和《Bob大叔和Jim Coplien对TDD的论战》一样，从这些贴子我们可以看到——这是一个全世界的问题，并不是只有在中国才有的问题。 很多敏粉都在说我在是喷敏捷，黑敏捷，向敏捷泼脏水，我只想对这些人说——你们这样的见解很肤浅也很敏感，你们根本就没有认识到——争论，反思和不同观点的意义，你也就无法了解你们所信仰的敏捷！你们只是在肤浅和盲目地信仰和教条敏捷中的许多名词、方法和标准答案罢了。 ——————————————正文开始—————————————— 对于程序员来说有些事有非常危险的信号（red flag）。当我听到有人开始信仰Test-Driven Development 是 One ...

下面的文章和《各种流行的编程方式》有异曲同工，请你不要理解错了。本文来源，翻译如下： —————————————————— 一个非常严重和困难的bug，能够成就一个饱经沧桑深受压力的有经验的专业程序员的职业生涯。经受这种考验的创伤程度，相当你受到了一次严重的身体伤害，离婚，或是家庭成为的离世。 研究人员在研究了计算机编程心理学后，得出了一个程序员们在解决一个困难的bug时的心路里程。这些不同的境界，很像为大众所知的Kübler-Ross Stages of Grief（这个模型描述了人对待哀伤与灾难过程中的5个独立阶段（否认，愤怒，耍赖，抑郁，接受）。绝症患者被认为会经历这些阶段），而且原因都很相似。就好像死亡所伴随的悲伤一样，fix一个bug是一个过程其初始化了一个事件，一开始是拒绝相信，其造就了你苦闷的情绪并开始逐步影响你的心智。这种苦闷的情结果会让你纠结要努力忍受，最终会你会找到一个满意的结果。 了解下面这几个bug-fixing的阶段，会让我们更好的生存下来，并持之以恒，最终带来……关闭我们所有的bug的结果。 第一阶段：抵触 本阶段的状态: 多疑 Skeptical. 生气 ...

在StakeOverflow上有这样一个贴子叫“Confessions of your worst WTF moment”（WTF就是What the fuck的缩写），挺有意思的，我摘几个小故事过来，希望大家在笑过之后能从中学到什么——所有的经验都是从错误中来的（我在其中加了一些点评） 我们公司的软件是给警察局用的，那是一个对用来处理被逮捕的人的系统，此系统还需要收集脸部特征和指纹信息，并且，这个系统和会向FBI的系统提交这些信息。当我们在测试这个系统的时候，我们一般都是用我们自己的指纹，当然，数据库联着的是我们的测试数据库。不过，有一次，在我们测试完后，我们忘了把系统切换回生产库，于是我们的测试数据库就联上了生产环境，于是我们的指纹信息和照片就散布到了其它系统中……清除我们警察局这边的还好办，但是，你需要波士顿警察局警司去法院签字才能从FBI的数据库中清除我们的信息。 点评：测试环境和生产环境的数据不要混在一起。 有一次，我需要向新系统中导入一堆数据，因为数据量太大，需要5个小时，只能在夜里来干，在系统需要正式使用前2个小时，数据导完了，此时是凌晨4点。随后，我需要删除 ...

目录 前言说明 基本观点 对于敏捷方法论的观点 对于ThoughtWorks咨询师的批评观点 关于ThoughtWorks和InfoQ给我的信 前言说明 之所以用了“再”，是因为之前的两篇文章—— 我在《那些炒作过度的技术和概念》中批评了ThoughtWorks中国咨询师的咨询方法是以一种接近于教条、炒作、洗脑和电视购物的方法（虽然我心底觉得有时候有时候更像传销），当然，批评是没有意义的，所以我也给了中国ThoughtWorks那些年轻的咨询师们一些我认为有建设性的建议。 我在《TDD并不是看上去的那么美》一文中列举了一些在实际中使用TDD可能会出现的问题和难题，以此来告诉大家在使用TDD时需要注意的东西。就像是在《结对编程的利与弊》说的一样，只有真正知道一件事情的利弊，你才能用好它。 当然，这两篇文章都不可避免得招来了ThoughtWorks咨询师和Agile信仰者们的很多回复，我也有开始沉不住气回复了很多，当然，有一半以上的不是学术上的讨论，而是对我个人的攻击。甚至，在这两篇文章发布后，酷壳（Cool ...

StackExchange.com上有两个贴子（贴子一，贴子二），贴子名叫“What is the single most effective thing you did to improve your programming skills?” – 对你的编程技术提高最有效的一件事是什么？回复的人中给了很多很不错的建议，我把他们总结了一下，十条，相信一定会对你有用。（注意：顺序是我自己按我的个人经验排的） 和比自己聪明的能力比自己强的人工作。学习他们的代码，他们的做事方法，看一看那些人是怎么处理错误的。 总是倾听别人怎么说，无论那个的资历和职位是什么样的。 实践，实践，实践，总是不满意于一开始出来的事。 多问问自己，现在在写什么代码？为什么要这样写成这样？还有没有更好的方法？ 学习多样的技术，多多比较他们，并一定要了解各种技术的优缺点。 总是问别人问好的问题。 多回头看看走过的路，做过的事，写过的程序，感觉一下他们有多烂。 多读读那些大师写的书。 不要总坐在电脑前编程序，多做做运动，多到户外走走，和非技术人多接触，向他们学习。 ...

对我来说，一个好的程序员应该是努力去追求尽可能无错的高质量的符合需求的代码实现。 一些人也许认为好的程序员是那些懂得多门编程语言，懂得很牛技术的程序员，是的，这在某些情况下是对的。但归根到底，无论你用什么样的技术，什么样的语言，所有的程序被写出来，其功能都要符合需求以及尽可能地健壮无错和高质量。  我们可以想像一下，如果一个能力普通的程序员有足够多的时间来做测试，那么，其也可以保证他的代码的质量。所以，有一种观点这样认为——要达到质量高的代码只需要有足够多的时间来做测试。这对于以结果为导向的商业软件开发中是可以理解的（我们可以看到那些制汽车的产商在汽车测试上花费的精力和时间就可以明白这一道理）。 但是，很明显，所有的已经开发出来项目都是在不完美的条件下开发出来的，一般来说，几乎所有的项目都是在最大化程序员软件的开发速度。而且，很多情况下，我们似乎对深度测试和压力测试并不是很关心，所以，我们总是在祈祷并期望那些赶工出来的代码可以正常工作，尤其是在上线的时候，这种唯心主义的价值观更为强烈。  其实，开发速度和软件产品质量并不矛盾。好的程序员并一定是技术强的程 ...