接上回说, 在基本上完成通讯组件后我就开始对整个平台应用模式的规划了. 因为这个时候我已经完成平台中端对端的聊天信息互传, 就是聊天软件的功能了. 对于整个平台来说架子算是搭建起来了. 剩下的就是用各种应用外插式的丰富平台功能. 不过在这之前我还需要做一件很重要的事, 就是将平台的地基打稳当, 否则后续应用插进来会出现各种各样的问题, 我会无暇顾及的.

其实在我学习软件开发的早期, 对代码质量, 产品质量这些是没有一个客观的印象的. 不关心所谓的产品质量, 也不知道如何提高产品质量. 而随着我对软件开发控制的了解和学习后, 这种基本的概念就慢慢的通过一次次因为产品质量出现的现场问题而逐渐让我关注起来, 所以说提高什么的都是有个过程的, 冰冻三尺非一日之寒啊. 在后来的开发中, 我就特别注意细节了, 因为很多产品质量都是细节模糊导致的漏洞. 有时候过多的去关注需求, 关注功能, 反而会忽略一些潜在的问题, 而这些问题是很难在测试中发现的, 最终还是流到现场流到客户那里去了, 我不认为这是失误, 而是失败, 对于产品质量控制的失败.

其实对于产品质量控制也是一个很大的话题(知道你又要这么说了), 我就不去理论性的描述控制方法了, 网上一大把. 老规矩, 还是结合我自己的开发经历说说吧. 我最初关注到内存泄露, 资源泄露这些缺陷的时候, 还是从学习C++才开始的, 因为VB开发的时候讲求的是快速实现, 逻辑精简, 界面优美, 然而对于代码本身的质量却关注的很少, 因为寻思着用最简单的代码实现就行了, 没必要搞的复杂, 所以其实本身问题还是很少的. 后来学习了C++才对内存, 系统资源这些关注起来. 就好像我后来对Silk平台进行质量提升的时候, 就专门去对平台做内存泄露测试, 不像单一的软件, 启动运行, 操作, 检测, 分析, 改进. 而对于这种C/S模式的还要麻烦些, 不仅要排查客户端的问题, 还要同时排查服务器的问题, 也许在客户端做出某种行为后, 服务器就会出现问题. 也有可能服务器的某个回应会导致客户端出现问题. 所以测试起来相当的麻烦, 而有些测试是白盒测试没法搞定的, 只能在现场环境实际应用中才能重现出来. 就像软件开发的过程一样, 质量问题的排查也是遵循这个过程, 就是从内到外, 从实现到应用的. 环境越接近现场, 测试和排查的难度越大, 不过相对来说出现问题的几率也会更小, 前提是前期的质量控制手段做的很充分, 到后期暴露的问题就会越少, 这是比较理想的.

我就蛮喜欢把问题扼杀在摇篮中的, 因为这样的话可以避免后期的排查和维护工作量, 问题发现的越早对于解决越有利. 所以在代码编写阶段就要开始重视产品质量的问题. 但也不用过于深入, 这样会本末倒置的. 而很多手段都是可以完成这些工作的, 比如代码静态检测, 单元测试, 白盒测试等工具, 用好这些工具对你代码质量的控制是非常好的, 也是及时有效的. 不用等到黑盒测试, 很多问题就可以立马解决了, 这不是很爽快吗? 在我印象中有些开发人员是不喜欢搞测试的, 特别是黑盒测试, 认为很枯燥. 我觉得不仅其然, 还是我以前文章的观点, 关键在于你把自己放置于一个什么样的位子, 你的关注点在哪? 关注于产品才能真正的做到主动出击, 防患于未然. 关注于功能的话, 会有很多局限, 眼光狭窄, 考虑问题也不会深远, 省心是省心了, 后续出现问题的时候就得花更多的时间和精力去解决, 很不划算的. 最好的办法就是代码写完(完成静态检测)并进行一般性能优化(已完成功能和性能测试)后, 就可以开始做深入的白盒和黑盒测试, 这里测试的目的不是走流程了, 而是在进入实际现场应用环境前进行最后一次把关, 这关口就很重要, 因为是防止很多应用性问题流入到现场的最后一个手段. 其实在这里操作, 不懂代码的测试人员一般是无法发挥出这个位置的重要性的, 很有可能和测试人员做一样的操作结果导致很多隐含的问题在现场才暴露出来, 很不幸, 这个时候客户已经看到了, 改进还来得及, 不过产品质量的印象已经下降了.

这里还要说一点我对分析问题和解决问题的一些看法. 一个好的研发人员不应该期待测试人员测试的时候全部通过, 因为对于产品质量来说, 谁也不敢拍着胸脯说绝对没有问题. 所以对于测试人员测试出来的问题应该感到欣喜若狂, 这些问题表面上是"嘲笑"了你的开发水平, 实质上确实对于产品质量提高的一次重大机会, 面子重要还是质量重要, 我想对于一个不利欲熏心专注于产品的研发人员来说, 他的答案是肯定的. 如果他能够意识到质量比指标更重要的话, 他会在各种"嘲笑"中不断的完善产品, 也在不断的提高自己的水平. 后续无论是产品还是自身, 出现"嘲笑"的几率会越来越小, 何尝不是件美事呢? 说到这里, 就需要说说自主研发和需求研发的区别了. 这里说的自主研发不是说独立开发某种技术, 而是对于一个研发人员能够主动的去发现某些需求, 发现某些问题, 然后提出来解决了. 这种研发人员对于整个团队来说都是很大的一笔财富, 特别是对于产品质量. 而需求研发就很好理解了, 研发的目的只是为了完成需求, 然后就再也别无它求, 兴许交付率很好, 兴许客户当时很满意, 但是也许隐含的漏洞就暗藏在产品里, 终有一天会爆发出来, 让客户蒙受损失, 而这种损失对产品开发项目组和客户都是不希望见到的.

未完待续...