柳鲲鹏

　　一个大函数，有好处，有坏处。总体来说，坏处大于好处。所以要拆分。听起来很简单，做起来就发现问题。原函数运行正常，拆分之后就错了，还不知道哪里有问题，也没有人问。怎么办？　　近日因为工作关系，拆分了一个大函数。有了一些体会。写出来，也许有人需要呢？　　拆分大函数，难题就是如何把变量变成小函数的参数。象Ｃ这样的有指针的还好说，一个指针下去就万事大吉。对于JAVA这种语言就很麻烦：值传下去容易，问题是变量会变。这种情形有两种办法：搞一个结构体。一般不使用这种方法，因为这表示进入函数就要新建一个对象

　　近来修改了一些代码，就是把if改为switch。为什么呢？switch性能更好一些。好多少？看分支数量及实际运行参数。不换行不行？不换也行，就是显得咱不够专业，没有追求。　　除了性能更好，switch看起来也更整齐，阅读起来更方便。...

　　LINUX安装后某些文件图标不变，暴躁的测试人员天天抱怨。最近终于受够了，决定专门研究一下。如果能够彻底解决，再也不会听到测试人员的。如果能再也不用听测试人员的聒噪。　　首先回顾了一下泰山OFFICE的LINUX安装。整套脚本、资源都是吾亲自建立的，各种细节也都考虑到了。打开方式、图标也反复检查过，确实没有发现可疑的地方。所以，现在是要是学习一下别人的做法，找到差异，进而找到解决办法。　　系统自带WPS OFFICE。吾于是研究了一下postinst。学到了一个命令：# i=48MIME

　　上周问了一下某头目，加密清理搞好了？回答搞好了。吾兴冲冲的打开配置文件一看，感觉自己的智商受到了侮辱。以前所有的加密类，都保留着，装模作样的加了一句“要用反射”。大哥汝真的一点脑子也不动吗？为什么这个要用反射，那个不用？　　吾爱管闲事。吾自己也知道。其实仔细想来，吾真的不是爱管闲事，而是不管什么工作，看一眼就会觉得自己智商受到了侮辱，不解决就无法忍受。而这些问题，其实只要稍微有那么一点的责任心，就不会出现。　　汝说他们是故意的？吾觉得倒不是。说是应付一下？这个差不多。只要做完就行，没有任何要检查

　　吾工作过的软件公司，主管只关心工作有没有完成。自然的，员工也是一样。其实这只是开始，后面还有很多层次呢。简单的说：做好。做好的意思，就是自己设计测试方案，做测试案例。 做精。功能考虑全面，没有遗漏。 做美。这个境界更高了，就是代码要漂亮，而且没有复制代码。那肯定经过多次重构、振荡。 做顶。就是世界顶级水平，拿出去别人看了也觉得真漂亮。 做宗。这意思就是有很多突破、全网首发等。　　做精已经很少，做美基本就没有了。事实上，做精、做美，并不会耽误工作，只是把后期的工作，提前进行。...

　　前几天，给测试同事们培训了一下，其中讲到一个：要建立测试基准。　　什么是测试基准？就是标准的测试环境、配置：OS版本，JDK版本，产品版本，参照软件。具有以下特点：这个不是口头的，约定的，而是公开的书面的强制的。而且要定期检查。 并根据需要升级，并在同一时刻全公司升级。 每次升级，只升级其中一个因素。 除非特别指明，否则都是当前最新的版本。 参照软件，用来测试产品与系统的交互，如拷屏，剪贴，文件等等。　　这个听起来是不是很简单？那你看看有几个公司这样做了？比如吾讲了之后，测试主管就没做

　　可视化编程也是一个老概念了。今天忽悠想，顾名思义，也是可视化编程的内容和要求。　　什么叫顾名思义？就是文件名、类名、函数名、字段名、变量名等，都能达到一看就知道意思和用处。　　常见的有两类问题：起名过于随便（一般不会张冠李戴），没有动脑。 有人想做到顾名思义，结果用词不当。这还是很常见的。这属于稍微动脑，没有深入思考场景、同义词的差异。　　人是很懒的，都不想动脑。想动脑也是天赋。　　...

　　JAVA中，如果不停的产生新对象，会有严重的性能问题：耗时长，内存消耗大。自然的，我们就想用一些技巧，就是对象回收利用。这个当然也要简单好用，复杂了大家也受不了。　　吾一直对已有代码中的回收利用NOT FULL。前几天终于有了灵感，写了一个通用方便的回收箱。简单来说：对象实现一个接口，方法有复制、是否回收、设置回收标志、清理等。 回收箱为每个类建立一个箱子，和构造器。 申请对象时，传递一个类。使用反射，建立第一个对象。后续对象使用复制函数，加快速度。 对象不用时，回收。...

　　今天测试了一下，突然发现内容超出了内容区。嗯？昨天跟今天都没改什么功能，也就是清理了一下垃圾代码。怎么就错了？回滚吧。　　回滚出错的版本，仔细看了一下，原因是吾把一系列if/else改为switch，因为都是判断字符，用switch显然更好一些。那么怎么就出错了？原来这里是在while中，原来代码的break能够正常工作。 改为switch后，break只是中断了switch，没有中断while循环。　　错误找到了，怎么办？改回去也不好，因为这种情况下if确实不如switch。于是吾加.

　　昨天下午时，旁边几个同事去拿了盒饭，意思是晚上要加班。吾就奇怪的问：尔等聊了一下午的上学房子，晚上竟然加班？这有意思吗？　　当时其主管开会去了（这个会的意义这里不讨论），开会时间有点长，于是旁边几位开启了聊天模式。注意是聊天模式，不是闲谈的那种（边工作，偶尔说几句），说到激动处，还站起来更靠近一些。周末嘛，活一周的活搞得差不多了，已经收好尾了，放松一下也正常。聊了半个下午，所以下班时吾看到他们晚上要加班（加班没有硬性规定，都是自己决定），莫名惊诧：你们加班干什么？下午为什么不干活？　　工作中大家

　　是高境界迁就低境界，还是低境界迁就高境界？　　在今天的《有组织测试技术》中，吾提出这个问题。正确答案是：　　低境界做好自己能做的工作部分，剩下的交由高境界。　　这样，经过一段时间的工作，低境界的工作水平自然就提高了，境界也就提上来了。...

自己听不懂，埋怨别人讲的没用

　　今天测试人员通报版本问题，又提到图标不刷新（重启才生效）。吾当即批评：这个问题已经三令五申（以重启????），为什么还要说？下次再有此类事情，要写事故报告。　　对方不服。吾立即说：你不满意就投诉。重复有什么用？　　其实不管是主管还是员工，有人已明确表示问题解决不了，或者你对结果结论不满意，不断重复强调这个事情，是没有任何意义的。人家只能做成这样，你重复有什么用？他就能解决了？他能解决还跟你废话？你有本事你来啊？　　正确做法是什么？如果你认为问题很严重又希望解决，怎么办？其实有三个办法：你

　　测试同事搞了个５０Ｍ大文件来测试性能，吾指出这是不对的。为什么呢？同样是50Ｍ，视频、图片、文字的性能测试结果是完全不一样的。应该具体细节：50Ｍ文字、50M图片（大小、格式、数量）、50M视频（分辨率、颜色等，实际上视频50M很常见），分别进行测试。　　这个道理是不是很简单？在理解上没有任何难度？现实是，这样简单的道理，测试同事不听，测试主管同样不听。　　人是不讲道理的，试图说服别人是不可能的，除非他自己想明白。...

　　昨天旁边的美女小声跟我说，不想干了。嗯？为什么呢？她抱怨说，活又多又难，自己又没做好。边说边流了泪。她为什么这么想？其实就是被活给逼的，而她又很负责。吾指点说，不要急，慢慢来。哈哈，每当想到工作让美女哭了就有点好笑。　　记住一个原则：再紧急的工作到了员工手里，都不急。什么？主管说真的很紧急？如果是真的，那么：主管自己亲自上啊，带头冲锋啊。口头说谁不会啊？ 主管安排得力员工协助、帮忙。 主管也搞不定，那赶紧向上反映。 如果自己是顶层了，那就开会讨论：有什么办法绕过去，看看谁能上，从外部找帮助

　　昨天对一批代码文件进行了清理。大哥汝吃饱了没事干？吾在进行某一工作之前，都会进行此类操作。这也是吾推荐给其他人的做法。内容有：加@Override 降低访问关系，如去掉public。 删除无用代码。 去掉注释。　　有朋友看到第四项会觉得奇怪，大家不都是鼓励、要求写注释吗？汝怎么还删除？因为注释都是没人维护的，或者本身就含糊甚至错误，留着没有好处反而有坏处。　　每个公司都鼓吹注释重要、有用，实际上呢？并没有安排写注释的时间。所以，注释不是工作的一部分。所以：注释程序员免费赠送给公司的，

　　改了个文件，构建那边出错了。于是顺便看了一眼构建脚本……其实这个工作应该是很出色的，只是因为吾要求看，所以看着实在是难以接受。　　比如说，在脚本中，经常使用到目录、yy...

　　命名是很有学问的，应该好好学习。下图是典型的柳氏风格命名，可以思考一下，为什么这么命名：

　　比如说吧，做了代码审察，指出了问题。然后会怎样？应该有5种情形：拖拉不改，多次督促后才改。 督促后才改。 自觉的迅速改掉。 把此类问题检查了一遍，并修改之。 把问题进行了推广，并进行了检查、修改。　　那么，现实性是怎样的？一般是１、２，连３都很少做到。各位自己是不是这样？碰到的是不是这样？ 能做到4的真是凤毛麟角，根本碰不到。 至于5，那绝对是顶级水平了。　　有人问，可是4、5很花时间啊，工作这么忙，没空。不值一驳：本身花不了多少时间。这个时候可以不需要动脑，可以当作偷懒。

　　这年头，到处鼓吹创新。工作中，有同事就批评说别人不会创新。吾正好相反，极力批评创新。为什么呢？吾在工作中鼓吹的是，死板教条、墨守成规、教条主义。现实中，创新只有坏处没有好处：这些所谓的创新，其实都是把事情搞得更糟糕。老老实实的死板教条，才是正道。 这些所谓的创新，当事人连正常工作都搞得一团糟。把正常工作做好，才是正道。　　为什么他们一搞创新，就把事情搞得更糟糕？原因很简单，一个是不会抄，另外就是抄都抄不对。汝不是天才，连抄都不会，还觉得自己厉害，真的自己心里一点数没有？　　那么什么时候.

　　昨天会议当然没什么用。会议结束后，美女问吾怎么办。吾就告诉她，你范例有了，先把范例跑起来，测试相关功能。那么就有以下几种可能：如果范例跑不起来，那别想办法，找找别的代码。 范例跑起来，功能测试不通过，还要找别的代码。 范例跑起来，功能测试正确，直接运行就可以，请问还有什么问题？　　吾要美女另外建个目录，然后修改了一下脚本，编译成执行文件。测试了一番，功能正常，几个星期没进展的工作，瞬间完成了。美女不适合难题类工作，主管又不会安排工作，不会解决问题，又不会指导……最后美女抹了眼泪，辞职走人了。

　　前一段时间，吾曾经系统讲过WP的布局，提到WP布局的三大难点。其中有一点是标点压缩。　　有人听了表示不服，说标点压缩的难点在于不知道规则，知道规则就好办了。吾当时也没有仔细想，觉得有理。这几天突然想，这话不对。举例来说，围棋：围棋规则简单吧？表面上看，比象棋简单多了。可是汝能下好吗？比如吾，会下围棋也几十年了，连基本死活都不会。 同样的，如果汝看顶级高手的比赛（或讲解），感觉他们下的棋也没有什么厉害的，甚至觉得一般，有一种“吾也会下”的错觉。如果真的让汝上，一定被秒得渣都在乎不剩，死都不知道怎

　　 相信大家都知道产品质量的重要，也知道自己产品的质量差，那么产品质量有提高变化吗？相信都会说，没有。为什么呢？原因是一个误解。　　绝大多数人都认为：这个产品重量不好，是因为时间不够，比如说只做了一年。 如果给两年或者研制，质量就好了，就可以让人满意了。　　这个观点对不对？又要看两种情形：一种情形是赶工，导致一些问题没有时间来解决。这个时候加点时间，确实有用。 等赶工因素消除了，进入了稳定、维护阶段，这个时候质量就进入了平台期，给再多时间，都不会提高。　　有人说这不科学啊。不对，这才是

　　吾发现自己真的跟别人不一样。　　昨天解决一个BUG，解决完了之后，发现拷屏有问题，就跟测试主管说了一声，拷屏有问题。然后测试主管就不停的问我细节。吾怒斥：开发人员这么问是没问题的，你一个测试主管，自己工作疏漏了，别人指出来，竟然不感到惭愧？还要问具体问题？　　测试主管表示不服，跟吾吵了一架。于是吾想，问题出在哪里？出在我是不正常的。当别人指出吾工作疏漏（注意不是BUG)时：吾首先感觉惭愧。疏漏也有不同：有的确实是比较偏门；有的应该考虑到的。这个疏漏吾应该考虑到却没有，惭愧。 然后吾就会反.

　　实现功能，一般人只求完成。作为一个顶级程序员，绝对无法容忍使用愚昧的代码。他的实现跟别人不一样。想用做好一词，感觉不能表达自己的意思，那就叫优美吧。　　有体现的朋友会很认同：把一堆乱七八糟的代码，变成了简洁漂亮，心情真的非常自豪。这个自豪与功能完成又不同，是实实在在的知道，自己的代码，比之前那些代码，好了非常多，是顶级水平。　　补充一句：有过优美代码的程序员，是不正常的；没有的，是正常的。...

　　造假是不是错的？主要是看善意，还是恶意。这个咱不多说。　　在工作中，造假对不对？也看情形吧：恶意造假。这个不用多说。 善意造假。比如工作没有完成，或者还没有开展，结果上面检查，为了应付一下。这也是常见的情形，不需要激动。 突出工作重点。这个是工作的一个必要技巧。什么意思？比如吾为了研究某个问题，搭建一个完整环境又很花时间，这个时候就可以进行环境造假，让研究工作顺利开展。等研究工作有了结论，再看环境问题。这个也可以称之为模拟。...

　　昨天有人告诉吾一个BUG，说在火狐中插件不能用。吾心里还奇怪，这插件功能也算是久经考验了，也很久没有人动了（也确实没有人力了），怎么有问题？一看是去年报的。于是找了台机器（国产平台），一试还真有问题。　　然后吾把代码工程复制过来，开始调试。这个代码工程是吾建立的，一层一层的关系，非常复杂，吾自己都有点头晕眼花。插件在浏览器中可以激活，无法显示，怎么办？查。转悠了半天，吾觉得代码并无问题。于是问了测试人员，说其实另外一个浏览器是有画面的，也跟某某说了。吾心里这个气啊，大哥你报BUG时，能不能老老实实的

　　旁边的美女走了有一个月了？美女为什么走呢？其实就是对任务的难度是否适合自己，一点数也没有。再前一位同事走的进修工作交接给她，这个倒也无所谓。工作交接本来就是个形式，试图说交接一下就搞明白，有这水平已经用不着交接了。所以对于交接，吾都是这样说的：把所有工作提交到SVN，以直接格式化工作机器也不影响工作为准。 任务交接了，是不是就是自己负责了？有问题就要自己解决？不一定。比如说汝是专门负责这个任务的，那推脱不了；如果是手头还有别的工作，那就看具体情况了。　　最关键的是，一个任务的难度是不是适合自己，

　　有一个BUG，有好多步骤。测试人员以为写得很清楚，吾每次看都有点发愁，大哥你明白，别人可看不明白，哪个步骤操作省略一个字都可能引起误解。　　这个时候，怎么办？想办法省略，突出重点。具体来说：把前面的步骤操作保存到一个文档。 只介绍产生错误的那个操作。　　这样别人只看几步，就明白怎么回事了。　　这个想法是不是很简单？很容易？现实中没有人会这样做。甚至吾这样说了，能听的都是个别。所以说大多数人基本功不及格，并不是夸张，而是事实。...

　　软件业有其特点，考评时要参考其他行业，同样也要考虑到特点。软件业有什么特点？工作不好直接比较。不能简单的以代码量、工作进度来比较，难度、复杂度差异太大。比如吾前一段时间解决OpenJDK的旋转字体打印，就改了一行代码，结果把整个JDK翻了个底朝天。所以这个是一个参考。 同样的，有人会浑水摸鱼。 考评说到底是鼓励加班。有钱出钱，没钱另想办法。 其他方面适度放松，不要斤斤计较。比如说，有软件公司的工作时间是比较灵活的，即使不能灵活，也不要天天拿迟到说事。 每个人的技术水平，大家心里都是有数的。一

　　搞了一阵变量局部化。尽管很小心，也认为没问题，结果还是出错了。　　为什么出错了？没注意在while循环中出现的位置。实际上这个变量是在循环外初始化，内部循环时，并不是每次设置为0，而是有选择的赋值并使用。总结教训是：　　循环内部的局部变量，要么是某个小范围使用，要么是每次循环初始化。...

　　每个程序员都觉得自己水平高，看不上别人的工作。比如说，在维护别人代码的时候，动不动就鼓吹要重写。前一段时间，我司头目跟我说要重写，我没在意，结果搞起来才发现，完全从头开始。吾斥之为好大喜功，不顾事实搞空中楼阁。　　吾一直反对从头写。理由？你水平不比别人高。如果你觉得高，请拿出令人信服的证据。 你某一点上见解比别人好，不要盲目扩大。 人的知识点可以通过学习增加，而能力、思路是无法通过学习提高的。比如说，你跟高手下棋，一盘棋输了，从头再来还是输。为什么？你能力就这么高，下多少次也是这样。 你的

　　自解释就是文档本身就说明测试内容。举例来说：　　有朋友问，泰山OFFICE能不能完美做到。吾回答是：目前还做不到，因为目前的WP之前不是吾负责的。吾正在改。 如何做到，吾有彻底方案，也做过实验。 目前正在逐步向吾方案靠拢。因为人力及没有助手（当然是能力好的那种），时间较长，预计需要一年。...

　　关于注释，吾有几个言论：注释无用。 注释有害。因为对错不知。写的人意思很难表达清楚，表达清楚了阅读者很难正确理解。 前一文，吾提出一个惊天神论：注释是程序员赠送给公司的，不写也没错。这比注释无用论、有害论更进了一步。　　有人就奇怪了，大哥你说注释无用、注释有害，那么什么有用？当然是代码啊。代码是程序员的工作，做好工作才是关键。实际上现在要求写好代码，代码就是注释。包括：命名清楚、准确。文件名、类名、函数名、字段名、参数名、变量名，没有歧义。比如说，在视图中不要用left表示剩下的意思，因为

　　昨天合并代码后，进行测试，发现文本框变得很高。这是怎么回事？仔细查代码，没发现疑点；使用以前的函数，就是对的。好奇怪啊。　　后来无意中，发现新代码参数与旧代码参数不一样（旧代码有一个转换函数，我复制了另外一个），我按照旧代码参数调用，其中的x位置就对应错了。调整了调用参数，结果就对了。　　你没事为什么类似函数参数顺序不一样？这不是故意捣乱吗？吾随便使用refactor功能，把参数顺序调整为一样的。　　...

　　最近刚刚解决了输入法的问题，自然的，就要进行测试。那么，如何设计测试案例呢？不同输入法系统自带，自行安装；拼音，五笔；长条形，方框形。不同平台WINDOWS、LINUX（多种平台）输入方式正常输入；捣乱输入；键盘输入，鼠标点击。测试对象主窗口上的控件，主编辑区，弹出对话框（模态、非模态）；有滚动条，无滚动条；单页，多页。...

　　昨天有人培训设计模式。吾实在是觉得难以理解。　　难以理解在哪里？有两点：大多数程序员连个代码都写得乱七八糟，比如连常量提取都做不到。这种情况下还谈设计模式？ 设计模式学了真的没用，学了之后只会玩弄一些概念，对于实用并无帮助。反而因为学了，自己更糊涂了。　　有人说你智商不够，所以觉得没用。智商够的人还要学设计模式？自然就会好吧？...

　　昨天有同事急三火四的说，拖放死机，JDK问题。吾当时刚刚找到几个相同的类，正在对比合并。于是就说：汝先试试版本3有没有。他试了说有，并告诉吾复现步骤。吾试之，果然死机。　　...

　　前几天开会，几位主管又提到大家能力得到了提升，以后还要提升。吾立即提出质疑：能力不可能提升的。　　能力不可能提升？这个跟常识违背啊。其实我们换个问法：你记忆力从小学开始，得到提升了吗？相信只有一个答案，没有。那你数学能力提升了吗？也没有吧？为什么别的能力不能提升，工作能力就能提升？那是一个错觉：　　大家把知识的获取，工作的经历，当作能力提升。其实这完全是两回事。　　再换个说法：大家都获取了知识，运用起来差异怎么这么大？因为能力有差异啊。大家都在某公司呆过，工作产出为什么相差很大？因为

　　放假前，同事说送测的软件，打印出了问题。吾一直对测试有意见。为什么呢？遇到问题除了当个传声筒，束手无策。吾随即要求：我司能不能复现？ 其他系统、打印机能不能复现？ 友商打印功能是不是正常？ 老版本是不是正常？ 各种情形做个列表。　　吾使用吾专有测试文档，一下子就发现了规律。又要重复：测试员连个文档都不会做，头目还不服不听，其他头目也不重视。...