技术QA是我造出来的词,指的是团队中的自由人,他没有特定的编码任务,只是检查程序代码,并优化代码结构或提出优化代码结构的合理性建议,帮助成员重构其中重复的或低效的代码。
我的建议(包括以前提过的)可以分为三类,一是团队的架构和运营、二是具体技术、三是用人法则。前两个我以前都提过很多,这次我主要提用人法则。
现在项目出现了不少状况,有人员流失,有软件成型困难等,我认为跟用人法则有很大关系。当领导能够因人的不同而赋予不同的角色时,团队的效率、活力、成员的成感、团队的凝聚力,产品的质量都会很高,反之如果把每个人都当成相同的人来用,所有人都是写代码的程序员,都平均被分配一块任务,我认为会出现成员在接到只能发挥自己三分之一能力的任务时会很没成感,接到超过自己能力的任务时会很有挫败感,没有成感的工作会使成员失去向心力,进而流失。我觉得Tony的辞职有这方面的原因,每个人都是不一样的,平均主义行不通,差异化很重要。
微软之所以能够取得的成,我认为有两方面原因,一方面是商业策略的成功,一方面是在软件开发过程中形成了一套合理高效的团队文化,这些经过实践检验的模型和准则统称为MSF(Microsoft Solution Framework)。里面的团队模型包括了开发、测试、用户体验、产品管理、程序管理、发布管理、后勤等如此多截然不同的角色,而各角色间同等重要,因为任何一个出了问题,都会影响到产品的进度和质量。也是说我想当“技术QA”这个角色并非是想要个官儿当当,因为这个角色并不高人一等,而是跟其它角色平等的,只是分工不同,专业的分工产生高效和优质的劳动。我的意图是做自己擅长的,团队会有更好的成果,自己也能获取成感,我不是聪明的,我的自信建立在写过的代码量上,在技术的追求上,以及自我否定精神方面,现有团队中没人比得过我,我达到了俯视现有项目中代码的水平,我能推翻别人,也乐意推翻自己。我担当这个角色,通过读代码,与其他人结队编程等方式,可以在模块划分,接口设计和编码风格方面指导团队成员,编写出健壮的代码,减少Bug,提高质量。这样用于测试的时间将会缩短,成本便会降低,客户满意度会提高, 我觉得你跟Michal和Dawn把道理讲清楚,他们没有理由不支持。
我想当这个角色的第二个原因是,更好的传播知识和应用知识。我以前提过的很多建议基本上在刚开始被否定,但经过解释都被认可,却终束之高阁无人问津,没有得到贯彻落实。我反省自己,出现这个现象的原因是,“仅仅大概知道”一个新的好的方法,等于0,因为仅仅大概知道,无代码审核机制,人员自己追求技术的主动性又不足(意思不是说大家一点都不重视质量,而是没有达到渴望的程度),终结果是不用。知道不重要,做很重要。要能够把好的方法用起来,需要领导的“强力”推广和“深度”的技术沟通,养成代码重构的习惯,当遇到一个新问题时,不是“勤奋”的堆砌,仅仅让代码跑起来完成任务,而是积极研究佳解决方案,用少的代码去实现它,“懒惰”的追求“简单性”。研究完后向团队做讲解,经过质疑和完善,得到一个成熟的方案。当遇到一个旧问题时,不是“耐心”的用自己的“笨”方法去实现,而是学习别人已经研究过的成果,用“浮躁”的方式实现它。总之一句话,让质量管理落在实处。
测试的作用只是检查程序的正确性。
一般QA的作用是从管理角度提高产品质量。
技术QA的作用是深入代码内部,在开发的过程中,从技术上提高产品质量,降低Bug率。
所以我认为我们的团队需要技术QA的迫切程度和重要程度超过测试。我们不应该被传统思想所禁锢,应该学会创新思维,积极开创工作新局面。
后我想说一下代码的问题,我认为如果把软件比做大厦,那么程序员是地基,软件的架构是柱子,一行行代码是砖瓦。人的作用重要,起到地基的作用,楼的高度不但决定于人的数量,更决定于人的质量(By the way,质量是可以改进的,但是也是难以改进的,一方面是人的追求不同,他的观念很难被改变,另一方面是智商的限制,比如我再怎么努力也达不到微软的录用标准,成为操作系统的地基)。你所说的用了某种模式可以被认为是某些柱子,但并非所有的柱子,缺少另外一些柱子显然不能支撑起大厦。重要的是,不能因为一些柱子造好了,认为砖瓦也是好的。柱子也是代码,从量上说,柱子只是大厦的百分之一,没有柱子没有大厦没错,但没有砖瓦的大厦只是亭子,只能看不能住。柱子好是必须的,没什么值得炫耀,真正的难点是每块砖瓦都是好的。用破砖烂瓦盖出的只能是危楼,实践证明,它连表面都不会风光。所以我认为,佳做法是用较少的精力搭出初始架构,之后必须把大多数精力集中在砖瓦上,在开发过程中不断的前进——反省和否定自我——对代码和架构做必要的重构——再前进……周而复始。这种小步快跑的策略也被用于企业的发展。
总结:虽然我不是牛人(牛人都去微软了),但在这个团队中,我有能力当“技术QA”,团队中也急需这个角色。另外,我的心态很好,当不上也不会辞职。