唯有思考没停

回顾QA的产生至今，QA起源于测试，但随着后置测试而导致高昂返工代价，人们学会了将测试前置（如评审、演示以及迭代开发）。但不管如何，测试被天生局限在了一个阶段的末端活动来验证活动的输出制品，也就是说它依赖于了有形产品。据研究，75％劣质产品质量是因为生产的过程混乱而导致的，基于此人们将过程质量与产品质量关联起来，意识到坏的过程导致了坏产品，那么将坏的过程变好，则产品也会好起来。自然地，保证过程...

断点 vs 日志断点是我们日常开发最为常见和高效的调试手段, 相比较输入日志它给予更多的状态信息和灵活的观察角度, 但断点调试是有前提和局限的.  # 需要一个界面友好, 功能强大的IDE,  # 比较适合于在单机的开发环境中进行. 企业应用开发中, 我们常常会遇到无法断点调试的窘境, 例如:  # 这个异常仅在生产环境出现, 开发环境里无法重现;  # 存在外部系统依赖, 开发环境无法模...

一直以来都没有正正经经的读过一本关于算法的书，只因为当初老师说过，“算法前人都写好了，你就拿来用好了”，以至于我对算法的理解还一直停留在“排序”的层次，现在想来惭愧不已。不错，经典的算法几乎所有流行的编程语言都有现成的实现，供我等应用开发人员直接使用。而且，若要想在盛行DRY的氛围下，尝试从头再来一次的话，所要承受舆论的压力不可小视。但算法就仅仅只是指“快速排序”、“八皇后”吗？不是，算法...

 短短几年工作里，我接触到了不少关于“面向XX”和“XX驱动”的思想，每当第一次听到它们时都会令我有种莫名的敬畏。 昨天在初探Erlang的时候，它的创始人Joe Armstrong的一句话让我印象深刻： Joe Armstrong 写道[1]At the highest level of abstraction an architecture is “a way of thinkin...

信息是表状的 一个事物有一组特征（属性），具有相同特征的若干事物被放在了一起，共享特征的说明。 信息是树状的 事物之间是有联系的，于是它们被线连了起来。 信息是分子结构状的 当事物之间的关系复杂到无法用二维平面去关联，此时只有三维空间能从多个角度来呈现如此复杂的关系网。 信息是什么形状的这样一个问题，能够帮助我们如何找到存储信息和呈现信息的最佳方式。...

今天是Qcon北京站的第二天, 由于大会日程排得很紧凑, 我只得放弃了今晚有些不靠谱的沙龙来整理这两天来脑中的一些零碎. 忧 我习惯先说的不好的,因为我总喜欢把好吃的留到最后.也许是我对此行期望过高,导致了我的失望,就牢骚几句吧: 1 大师不愧是大师, 只是他们的英式发音让我这个看惯美剧的人,无法保持1个小时注意力.尽管有同步翻译,毕竟不是内行...

软件开发过程是连续的太多开发人员受瀑布模型的影响太深了，习惯性的将开发过程做严格的划分。这样的划分多半是自欺欺人，软件开发过程主要是靠人的思维创造，而思维过程是连续的。切断一个连续的思维过程，这可能吗？或多或少有完整项目经验的程序员，在接到新的项目需求时，很自然就会在脑海里浮现代码实现的轮廓，剩下的活就应该是动手编码了，用个成语来形容它就是“顺 理成章”。软件开发过程也应该顺理成章，不要再...

      这两天我利用不多的工作空隙时间，用Groove做了一个简易的事务跟踪工具。这个点子来之于《小型团队软件开发：已RUP为中心的方法》，他们使用Groove做了故障跟踪的，我想这对任务、问题、风险应该同样适用。      工具的实现是基于Groove自带的Issue Tracking的工具模版改良而成，大部分的工作是汉化和界面定制，要想实现一些高级功能需要用脚本，好久没有编码都生疏了，...

大多数java教程的书籍中,对异常的处理都是及时的,也就是哪里抛了,就在哪里catch.看别人的代码渐渐多了,就有些模糊的意识到不是所有的异常都是及时处理的,而是通过throws抛给调用者处理.问题出来,每次遇到异常的时候,我就在catch与throws之间挣扎好久,那么到底要在哪里处理异常?似乎书上并没有答案.我曾就这个问题请教过一个前辈,他的解答是"在合适的地方处理". 汗,我被这...

前段时间又面试了一些应聘的人，明显的感觉到人才难求啊！此难求非彼难求，也就是人才难求是两方面的，一方面要人才自身显露，二方面则要面试官有双慧眼。 面试中通常非常关注一个人的综合素质，在这方面的考察有很多有潜在意义的问题。面对这样的问题，通常有两种应对者：第一种，不太理解问题要问什么，回答要么肤浅要么干脆跑题，这种人以没有工作经验的人占大多数；第二种，非常清楚问题的意义，相当明确...

最近才看很久之前唐博发给我的一篇文章《Bug管理的经验和实践》，由于在大学讲课的关系，我准备翻看一下作为上课授课题材。没有想到，文章（准确的说是访谈录）中微软研发过程中bug管理给我启发颇大。但直接将文章中的内容转述给学生们，似乎不会有好效果，因为学生是没有研发背景的，对于我转述的内容的价值不会有太多意识。不知道自己的脑袋是不是被闪电击过，闪念间想到用游戏的形式呈现这一个过程，下面就来分享一下...

受@放翁_文初的<逻辑划分线程池> 一文的启发, 用了几个小时动手实现了一个简陋支持配额的共享线程池. 基本思路与放翁相同, 区别在于引入了两种线程分配策略:悲观策略简单的共享一个线程池, 最容易出现的问题就是不同类型任务(或事件)在随机争抢线程资源时, 可能出现”饿死”现象(即抢不到线程).因此, 悲观策略的宗旨是绝对的保证每种任务都会被分配到预留的(reserve)...