性能测试应该怎么做？
偶然间看到了阿里中间件Dubbo的性能测试报告，我觉得这份性能测试报告让人觉得做这性能测试的人根本不懂性能测试，我觉得这份报告会把大众带沟里去，所以，想写下这篇文章，做一点科普。
首先，这份测试报告里的主要问题如下：
1）用的全是平均值。老实说，平均值是非常不靠谱的。
2）响应时间没有和吞吐量TPS/QPS挂钩。而只是测试了低速率的情况，这是完全错误的。
3）响应时间和吞吐量没有和成功率挂钩。
目录
为什么平均值不靠谱
为什么响应时间（latency）要和吞吐量（Thoughput）挂钩
为什么响应时间吞吐量和成功率要挂钩
如何严谨地做性能测试
为什么平均值不靠谱
关于平均值为什么不靠谱，我相信大家读新闻的时候经常可以看到，平均工资，平均房价，平均支出，等等这样的字眼，你就知道为什么平均值不靠谱了。（这些都是数学游戏，对于理工科的同学来说，天生应该有免疫力）
软件的性能测试也一样，平均数也是不靠谱的，这里可以参看这篇详细的文章《Why Averages Suck and Percentiles are Great》，我在这 ...
为什么我反对纯算法面试题
算法面试可能是微软搞出来的面试方法，现在很多公司都在效仿，而且我们的程序员也乐于解算法题，我个人以为，这是应试教育的毒瘤！我在《再谈“我是怎么招程序员”》中比较保守地说过，“问难的算法题并没有错，错的很多面试官只是在肤浅甚至错误地理解着面试算法题的目的。”，今天，我想加强一下这个观点——我反对纯算法题面试！（注意，我说的是纯算法题）
图片源Wikipedia（点击图片查看词条）
我再次引用我以前的一个观点——
能解算法题并不意味着这个人就有能力就能在工作中解决问题，你可以想想，小学奥数题可能比这些题更难，但并不意味着那些奥数能手就能解决实际问题。
好了，让我们来看一个示例（这个示例是昨天在微博上的一个讨论），这个题是——“找出无序数组中第2大的数”，几乎所有的人都用了O(n)的算法，我相信对于我们这些应试教育出来的人来说，不用排序用O(n)算法是很正常的事，连我都不由自主地认为O(n)算法是这个题的标准答案。我们太习惯于标准答案了，这是我国教育最悲哀的地方。（广义的洗脑就是让你的意识依赖于某个标准答案，然后通过给你标准答案让你不会思考而控制你）
目录
...
为什么Scrum不行？
这篇文章的原文在这里（原文链接）（下文不是全译，也不是部分译，我只是把其总结，有我自己的发挥，但是原意大致不变），这篇文章完全是在调侃Scrum的，作者第一段就是一个免费声明，其说他是Scrum和其它敏捷方法的big fan， 他也认为Scrum 100% 对 软件开发可行。作者使用Scrum 5年了，也公开作过几次敏捷的分享会。他觉得写这篇文章只是为了好玩，因为他们戴上Edward de Bono 的 black hat （黑礼帽 – 是6个思考之帽中的一种——负面思考，思考事物的负面因素，这样才知道：它会起作用吗？缺点是什么？它有什么问题？为什么不能做。）
因为本人经常站在Agile的风口浪尖，所以我有必要也来一个“免责声明”。Shit！其实我想来的是“不免责声明” ——下文中的九大原因是对中国的各种Agile实践者咨询师不注重实际只重方法论的批判，本人必然要和那种只以流程方法论为中心的软件开发斗争到底。其实我没有那么嚣张，我只是想说，下面的这些东西相当的现实。希望各种Scrum的实践者们认识到这些问题，从而可以让你们明白软件开发中的人的重 ...
再谈“我是怎么招聘程序员的”（上）
我以前写过一篇“我是怎么招聘程序员的”的文章（在CSDN那里有很多人进行了回复）。今天，我想再谈谈关于招聘和面试这方面的东西，主要是以下这些原因：
近半年来我在进行了大量的招聘工作，对面试有一些新的体会。
酷壳最近发布了几篇趣味面试题（面试题一，面试题二，面试题三），从回复中让我有一些思考。
我有一个同事最近面试了一家公司，他和我分享了一个博士专家对他的面试，也让我思考了一些。
在豆瓣上看到“知乎上某人写面试豆瓣产品经理的经历，很欢乐”(亮点是面试官现身知乎亲自作答)
所以，我很想把自己的这些新的想法再次写下来的。还是和以前一样，这篇文章同样是献给面试官的。我认为，面试的好坏完全在面试官而不是面试的人。下面是我对“我是怎么招聘程序员的”一文中的一些加强性的观点。（关于一些点评，请参看本文下篇）
为了让我的文章有连续性，请允许我重申一下前文的几个重要观点。
只有应聘者真实和自然的表现，才能了解到最真实的东西
重要的不是知识，重要的是其查找知识的能力
重要的不是那个解题的答案，而是解题的思路和方法
操作，知识，经验，能力
我们有很多的面试官似乎分不清，什么是操作能力 ...
再谈“我是怎么招聘程序员的”（下）
<<<再谈“我是怎么招聘程序员的”（上）
在上篇中，我们说到了一些认识人的方法（操作，知识，经验，能力），还有一些面试的方法（算法题，实际生产活动中的挑战），下面我们来说说，面试的风格，还有一些点评。
把应聘者当成你的同事
有些公司的面试官，在面试过程中问你一个算法题，然后等着你解答了，如果你给出一个答案，然后就会问你有没有更好的答案，如果你给出了正确的答案，他们就会问你一个更难的问题，如此循环下去。他们基本上很少给你提示，甚至不停地质问你，挑战你，搞得应聘者很紧张。
另外，有很多问题是没有标准答案的，或者说是，同一个答案的描述方法有多种，很多面试官会觉得你没有回答到他想要的答案，因此表现得有对你不屑，并表现出你不行的样子，并觉得你的能力有问题。真是可笑了。比如我一个朋友在回答什么是异步的问题时，举例说明了异步调用就是不能处理完就返回，并且需要传递一个回调函数给调用方以便完成后回调通知结果。这样的回答并没有错，但是这并不符合面试官心里想要的答案，面试官对此并不满意，进而认为我这个朋友还需要去多读读书。
我相信大多数面试官都会这样干的。我想问问这样的面试官，你们有没有 ...
![[转]TDD到底美还是不美？](/wp-content/othersite-resources/cnblogs_com/weidagang2046/feedback_cycle.jpg)
[转]TDD到底美还是不美？
下面的文章转自Todd Wei 的《TDD到底美还是不美？》，对于这篇文章，我个人能过透过作者的观点感受到他的项目中使用TDD的难点，同样可以感受到作者内心的纠结。不管怎么样，我能够感到作者Todd Wei在独立思考，独立思考总是好的，因为那是走向成熟的必要条件。(另，大家可以移步过去看看相关的评论，挺有意思的)
————————————————————————————————————
最近CoolShell上的一篇《TDD并不是看上去的那么美》引起了敏捷社区的高度关注和激励辩论。今天，InfoQ甚至专门举行了一个“虚拟座谈会”《TDD有多美？》，几位国内敏捷社区的名人专门就此问题展开了深入地讨论。不论结果如何，这个纯技术的探讨精神还是非常值得赞赏的。事件实际上可以简单地归纳为“一个有一定影响力的开发人员质疑TDD，一群敏捷社区名人对TDD进行解释和辩护”。现在，就让我坚定地站在CoolShell一边，为对TDD的质疑和批判添砖加瓦吧！
TDD的核心理念是什么呢？第一是Specification by Example，即把测试用例作为表达需求的一种方式。传统的需求表 ...
TDD并不是看上去的那么美
春节前的一篇那些炒作过度的技术和概念中对敏捷和中国ThoughtWorks的微辞引发了很多争议，也惊动了中国ThoughtWorks公司给我发来了邮件想来找我当面聊聊。对于Agile的Fans们，意料之中地也对我进行了很多质疑和批评。我也回复了许多评论。不过，我的那些回复都是关于中国ThoughtWorks咨询师以及其咨询的方法的。我对Agile方法论中的具体内容评价的不是很多，所以，我想不妨讨论一下Agile方法论中的具体的实践（以前本站也讨论过结对编程的利与弊）。
那么，这次就说说TDD吧，这是ThoughtWorks中国和Agile的Fans们最喜欢的东西了。我在原来的那篇文章中，我把TDD从过度炒作的技术剔除了出去，因为我还是觉得TDD有些道理的，不过，回顾我的经验，我也并不是很喜欢TDD。我这篇文章是想告诉大家，TDD并没有看上去的那么美，而且非常难以掌控，并且，这个方法是有悖论之处的。
TDD简介
TDD全称Test Driven Development，是一种软件开发的流程，其由敏捷的“极限编程”引入。其开发过程是从功能需求的test case开始，先添加一个test ...
代码重构的一个示例
还记得以前和大家提到过的《各种流行的编程风格》吗？有一些人问我那些编程风格具体是什么样子的。下面是一个代码重构的实例，让我们看看那个流行的编程风格是实践是什么样的。下面的这个实践不是虚构，如有雷同，请对号入座。
首先，我们有一个表达式如下所示：
s = 7;
很明显，这个表达式的变量名太没意义了，很不利于程序的可读性，所以，我们需要取一个有意义的变量名：
slots = 7;
很好，不过，那个常量7是hard-code或是一个Magic number，而且，这常量没有名字也不利于代码的可读性啊。再改：
SEVEN = 7;
...
slots = SEVEN;
靠！上面，是这是哪门子的改法？（不过，我保证这是真实发生的），常量名也要有意义一点嘛，再改：
SLOTS_PER_WIDGET = 7;
...
slots = SLOTS_PER_WIDGET;
这还差不多，不过，名字可能会重名啊，最好放到一个类中：
import widgetConstants;
...
slots = widgetConstants.SLOTS_PER_WIDGET;
现在看起来好很多了，不过，即然面向 ...
一些鲜为人知的编程事实
文章来源：http://dotmac.rationalmind.net/2010/08/some-lesser-known-truths-about-programming/
我的程序员经历让我明白了一些关于软件开发的事情。下面是一些在编程中可能会让人感到诧异的事情：
一个程序员用了大约只用了10%-20%的时间来编码，而且大多数程序员，无论他的水平如何，其平均每天只有10-12行的代码最终会进入最终的软件产品中。这是因为，优秀的程序员会花费90%的时间来思考、调查、研究最佳的设计。而糟糕的程序员则会花费90%的时间来调试代码，并随意地改动代码并尝试让代码工作起来。
“A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.” –Bill Gates
“一个优秀的车工 ...
五种应该避免的代码注释
在酷壳，有很多文章都提到了代码注释，如：《十条不错的编程观点》、《优质代码的十诫》、《整洁代码的4个提示》、《惹恼程序员的十件事》等等。今天，某国外的程序员在这里列举五种应该避免的程序注释，我觉得比较有道理，但我觉得有少数几个观点也并不绝对。所以，我把原文的这五种应该避免的程序注释罗列在下面，并放上原作者和我的个人观点作为比较。希望对大家有用。
一、自恋型注释
（注：原文为Proud，我觉得“自恋”更好一点）
public class Program
{
static void Main(string[] args)
{
string message = "Hello World!"; // 07/24/2010 Bob
Console.WriteLine(message); // 07/24/2010 Bob
message = "I am so proud of this code!"; // 07/24/2010 Bob
Console.WriteLine(message); // 07/24/ ...
各种流行的编程风格
在过去的N年中，我遇到了很多使用囧然不同风格的开发者，下面是我所知道的一些，你还知道其它的吗？
目录
散弹枪编程
撞大运编程
Cargo-Cult 编程
刻舟求剑编程
设计模式驱动型编程
侦探型编程
屠宰式编程
散弹枪编程
这种编程风格是一种开发者使用非常随意的方式对待代码。“嗯，这个方法调用出错了……那么我会试着把传出的参数从 false 变成 true!”，当然依然出错，于是我们的程序员会这样：“好吧，那我就注释掉整个方法吧”，或是其它更为随意的处理方式，直到最后让这个调用成功。或是被旁边的某个程序员指出一个正确的方法。
如果我们把一个正规的程序员和一个撞大运的程序员放在一起做结地，那么，那个正规的程序可以马上变得发疯起来，并且，可以把正规的程序员的智商降到最低。两个撞大运的程序员不应该在一起做结对编程，这是因为他们破坏性的才能会造成的伤害会比只有一个还差。
撞大运编程
这是一种比散弹枪编程要温和一些的编程方式，我相信这种方式可能会是大多数程序员都会使用的方式。这种编程方式经常出现于程序员并不确切知道 ...
橡皮鸭程序调试法
下面，让我来为你介绍一个程序调试大法——“橡皮鸭程序调试法”，这个方法在调试界是很出众的，实施起来相当方便和简易，几乎可以随时随地地实验，几乎不需要借助任何的软件和硬件的支持，你甚至可以把你的程序打印出来，在纸面上进行调试。
那么，为什么这个方法要叫做橡皮鸭呢？因为橡皮鸭子是西方人在泡澡时最喜欢玩的一个小玩具，所以，这个东西应该家家户户都必备的。因为，这个方法由西方人发明，所以，就被取名为“橡皮鸭”了。
好了，话不多说，下面是整个调试方法的流程。
找一个橡皮鸭子。你可以去借，去偷，去抢，去买，自己制作……反正你要搞到一个橡皮鸭子。
把这个橡皮鸭子放在你跟前。标准做法是放在你的桌子上，电脑显示器边，或是键盘边，反正是你的跟前，面朝你。
然后，打开你的源代码。不管是电脑里的还是打印出来的。
对着那只橡皮鸭子，把你写下的所有代码，一行一行地，精心地，向这只橡皮鸭子解释清楚。记住，这是解释，你需要解释出你的想法，思路，观点。不然，那只能算是表述，而不是解释。
当你在向这只始终保持沉默的橡皮鸭子解释的过程中，你会发现你的想法，观点，或思路和实际的代码相偏离了，于是你也就找到了代码中 ...
编程命名中的7+1个提示
前几天Neo写过《编程中的命名设计那点事》，这里也有另外一篇和程序命名的文章，可以从另一个角度看看。
1.- 变量应该是尽可能的望文知意。千万不要使用教材中的命名方式。
好的变量： daysDateRange, flightNumber, carColor.
坏的变量： days, dRange, temp, data, aux…
在我们的日常工作中，有很大数量的开发人员喜欢使用短的变量名，而不是有含义的变量名。这主要是因为我们大学教科书的那些示例所造成的，人都是先入为主，所以，教科书中的那些很抽象，带着演示的变量命名影响了我们一代又一代的程序员，并影响了他们很多年。虽然那些短的，教材式的变量名，可能会让你少打一些字，但其实，这是非常非常不好的。因为软件的维护成本远远大于了软件的开发成本，如果你不取一个好的一点的变量名，那么当进行代码评审时，当进行bug fixing时，当进行代码重构时，当进行代码维护时，你的某个变量名可能会让你一头雾水，不知道所措，还可以会让你走入陷阱，造成更大的时间成本。所以，一个可阅读的代码必然和那些不错的变量名分不开，而这也能让你 ...
优质代码的十诫
1.- DRY: Don’t repeat yourself.
DRY 是一个最简单的法则，也是最容易被理解的。但它也可能是最难被应用的（因为要做到这样，我们需要在泛型设计上做相当的努力，这并不是一件容易的事）。它意味着，当我们在两个或多个地方的时候发现一些相似的代码的时候，我们需要把他们的共性抽象出来形一个唯一的新方法，并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。
DRY 这一法则可能是编程届中最通用的法则了，目前为止，应该没有哪个程序员对这一法则存有异议。但是，我们却能发现，一些程序在编写单元测试（unit testing）时忘记了这一法则：让我们相像一下，当你改变一个类的若干接口，如果你没有使用DRY，那么，那些通过调用一系例类的接口的unit test的程序，都需要被手动的更改。比如：如果你的unit test的诸多test cases中没有使用一个标准共有的构造类的方法，而是每个test case自己去构造类的实例，那么，当类的构造函数被改变时，你需要修改多少个test cases啊。这就是不使用DRY法则所带来的恶果。
2.- 短小的方法 ...
编程中的命名设计那点事
在我开始设计系统的时候，我会花去很多时间去设计命名，因为好的命名和好的设计是分不开的。
In the beginning was the Word, and the Word was with God, and the Word was God
太初有道。道与神同在，道就是神。 (约翰福音第一章，第一节)
在设计过程中给类，方法和函数好的命名会带来好的设计，虽然这不是一定成立，但是如果坏的命名那一定不会给你带来好的设计。在设计过程，如果你发现你很难命名某一个模块，某个方法时，可能你真正遇到的问题不是难命名的问题，而是这个设计是否真的合理，你或许应该花更多的时间来重新设计一下你的模块。
好的命名不仅会带来好的设计，好的命名还提高了程序的可读性，降低代码维护的成本。另一方面，如果糟糕的命名会给代码带来一堵无形的墙，让你必须深入代码去研究代码具有的行为，增加你理解代码的时间。
为此我总结了几条关于命名的指导原则，希望这几条原则能为你的命名设计带来帮助，我使用的是C++的语法，当然这些原则也很容易扩展到其他语言中去。
类型命名(类，接口，和结构)
名字应该尽量采用名词Bad:& ...
结对编程的利与弊
结对编程(Pair-Programming)可能是近年来最为流行的编程方式。所谓结对编程，也就是两个人写一个程序，其中，一个人叫Driver，另一个人叫Observer，Driver在编程代码，而Observer在旁边实时查看Driver的代码，并帮助Driver编程。并且，Driver和Observer在一起时可以相互讨论，有效地避免了闭门造车，并可以减少后期的code review时间，以及代码的学习成本。
有实验证明，平均下来，结对编程所花费的时候比单人编程增加了10%，但也会比单人编程减少15%的代码BUG。如果再算上后期代码的维护和学习成本，结对编程比单人编程更有效率，还更为节省成本。无论是对开发团队还是对于Business，结对编程都会是非常不错的Programming Practice。
下面是一些结对编程的优点：
程序员互相帮助，互相教对方，可能得到能力上的互补。
可以让编程环境有效地贯彻Design。
增强代码和产品质量，并有效的减少BUG。
降低学习成本。一边编程，一边共享知识和经验，有效地在实践中进行学习。
在编程中，相互讨论，可能更快更有效地解决 ...
