柳鲲鹏

代码就是指，对某部分代码进行修改后，出于觉得改错了、出现新问题、有奇怪问题、想从头再试一遍等等，想从头再来，恢复原来代码。上一篇博文说，抄代码也是要技术的，大多数人不会抄。相信很多人看了也不服。不服归不服，这是个事实。这听起来很简单对不？可惜，大多数人不会。还原代码什么时候使用？

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

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

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

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

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

开始觉得简单，后来发现还是要一点技巧的： private boolean deleteEmptyDir(final File path) { //是文件，本分支不能删除 if (!path.isDirectory()) { return false; } File[] files = path.listFiles(); //空目录

　　同事说新版本的插件有问题，闪一下就没了。插件代码部分这一段时间没有改，那就是接口部分了。接口同事自然也是无辜的样子，没改什么啊（不要大惊小怪，大家都是这样）。 　　吾随即在虚拟机上试了一下，也不对。于是加了几个输出语句，再运行，反复几次，发现是一个接口没了。这叫没改什么？于是一查SVN，吾三句话的插件启动代码，被换成了老的一套。吾就他：　　把这么精美的代码搞乱，你一点数也没有？　　代码能力是有差别，这个没办法，很难跟上。可是人家三句代码完成的功能，精练漂亮，你把老代码的二十句翻出来替..

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

　　昨天要求同事出了个版本。版本出来，吾一看版本号，就觉得不合适。因为有些数字，并不适合作版本号。因为有可能引起麻烦。　　当然了，这里只谈工作，不抬杠。　　这是个小事，也是要注意的。...

　　很多软件，在右下角托盘上会显示一个图标，泰山OFFICE也有。开始叫quickstart。这个词意思不能说错，问题是用得地方太多，泰山OFFICE有三处功能用到。所以一说quickstart，到底指的谁？ 后来吾改名为RapidMenu。这个词就非常好，意思清楚，而且专属。 昨天一更新，看到又改名为starter，吾当时……怒斥这是词汇匮乏症，除了start别的都不会了。这还就算了，自己匮乏不仅不觉得，还觉得自己多么的正确，非要改回去。　　当然了，现在吾说什么也没人听，所以懒得争论了。...

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

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

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

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

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

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

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

　　吾一直反对把看代码作为工作。这跟所有人都不一样。而人又是极度自信的，所以也没有人听。　　某新来的同事，被安排了看代码工作。今天然后问吾：这个函数什么意思？不好意思，吾真的不知道。为什么要知道？这个代码已经运行很久了，也没有发现问题，你看明白有什么用？你能力又不比作者强。　　吾随后说，有这个时间，你不如解决几个简单的BUG，这样代码也看了，流程也了解了，工作产出也有了，转正时也有介绍的内容了。...

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

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

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

　　去年这个时候，有头目突然提出，让测试人员找出产品的痛点，改善用户体验（创新），换个新界面。这就搞得莫名其妙。为什么呢？因为泰山OFFICE是参考MS OFFICE。 而MS OFFICE可以说是千锤百炼，非常好用。　　现在突然提出要改善用户体验，换新界面，意思就是MS OFFICE有明显不足？UI人员已经是世界顶级水平？大哥你信不？结果底下员工就瞎激动了，胡乱提了一些问题，UI也很快搞出一波。结果此事又是让吾负责，吾是很抗拒的。为什么？原因就是尔等自己水平不行，却还觉得自己如何英明（把自己的观点

　　王同事走了， deb打包格式不对，只能由吾负责了。吾就发现一个严重问题：　　应用名不对！　　实际上这个问题以前就遇到过，程序员自己随意定义了应用名，吾还在工作会议上专门强调过。结果还是再次发现了。有三个要点：大多数程序员（如果不是全部的话），根本不知道自己的权力范围。应用名这样的事情，你怎么能决定？你能定义没错，也一定要上报到上一级主管。 别人的工作指导，都是耳旁风。吾已经说过，你为什么没听进去？听不进去是正常的，听进去才不正常。怎么办？ 没有人检查工作，也没有人知道怎样检查。这个问题吾

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

　　为了解决WEB的问题，吾专门提出一个方案，然后开了个小会。在会上，吾讲了9点，涉及方案、执行等。负责工作的那位，自然象其他员工一样，带着本子，往桌子上一放就装模作样听了。吾就问，你为什么不记？　　昨天他来问我其中一个执行动作。吾就问，你为什么不记？回去带本子来。记什么？其实就是设置字体颜色、大小。当时不记，就忘记了。如果当时记呢？听不明白的还能及时询问。　　自吾几年前担任主管以来，吾就经常提这个问题：开会你带着本子从来不记，不如不带。形式主义是需要的，纯形式主义一定要反对。你带本子给谁看？.

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

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

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

　　代码、注释，哪个是本？当然是代码。　　所以，首先要求写好代码。写好了代码，再写注释，就有意义了。反之，代码都乱七八糟，命名都有歧义，还写注释？别人看了，结果就是错上加错。　　道理是不是很简单？没有人会听的，更没有人会做的。除非自己某一天，突然想明白。...

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

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

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

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

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

　　两个线段，有重叠，情形比较多。反过来想，如何判断两个线段无重叠？排除了这个，不就重叠了？代码如下：if (x1 + w1 < x2 x2 + w2 < x1){ //两个线段无重叠}　　代码的思路就是，两个线段不重叠，一定是以下两种情形之一：要么线段1的终点在线段2的始点之前。 要么线段2的终点在线段1的始点之前。...

　　看到这个题目，可能不觉得对；动手写个文章，就会发现真的比写代码难多了。为什么呢？实现目标不一样。代码是实现某个功能，功能是客观；文章表达想法，想法是虚幻的。 大部分人即使训练，也难以写好文章。代码有套路，文章也有，可是这套路太空泛，难以掌握。 代码没人看，只要完成功能，主管根本不会看；文章不一样，写了是给别人看的。 写好代码其实也很难的，显然写好文章更难。　　所以，经常写博文，应该有助于提高编程能力，因为可以把自己的想法更清晰、更条理。...

　　程序员都有体会，遇到的问题千奇百怪，甚至有的问题互相冲突、矛盾。有时为了解决这个问题，采取了头痛医头的办法糊弄过关。这种办法在紧急情况下偶尔可以，却不是长远之计。 长远之计是深入分析，一定找到问题的合理解释，能够把各种现象理顺，这个时候问题才得以解决。　　说起来容易，大多数程序员不会深入分析，工作完成就行了，谁管那么多。这也是人之常情。作为主管，就要注意了，而不是被底下忽悠，只看表面。...

避免重复的。记录上次结果Hash法。switch二分法

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