SQA到底应该做一些什么1---培训的故事2

我说的培训不是单位的正规培训，是在实际工作中如何提高开发人员的开发素质，从而达到改善开发流程，提高软件质量，降低开发风险的目的。上回说了一个测试人员 小A的培训，在说说另外一个例子。小B的培训。 
小B是一个开发人员，按道理来说他的培训不应该由我们负责，但他和小A是好朋友。在7月刚参加工作的时候和小A一起测试过系统，平时也经常和我们在意思，所以他问一些开发的问题。我们自然会回答。 
在7月份小B参加了一个系统的测试后，一直没有项目，主要是自己学习，期间也和我讨论过开发的问题，但我总觉得给他讲了很多，但他接受的并不是很多。效果很差（个人认为原因有三，一个是没有真正的项目，而他的开发经验比较少，很多东西很难接受，二没有项目，很难实施很多软件方法，而其中的好处也自然理解不了，三没有项目的情况下，很多时候是只讲解理论，而不能和实际结合起来，没有实例很多问题很难讲的清除）。 
小B终于上项目了，开始他很兴奋，（刚开始工作的同志都是这个样子）。但很快，他就眉头紧锁了，紧接着就开始疯狂加班了。两周的任务在快到中间的时候，他越来话越少了。周五下班的时候，看他还在奋斗，于是过去打了一个招呼。小B仍然是眉头紧锁。看他那个难受的样子，于是决定帮他调试一下代码。调试的开始，首先是把他的代码规范化，很简单，就是层次之间空四个格。他原来的代码一看就是没有经过这种练习，所以代码层次写的很乱，从格式上很难一下分清代码的层次结构。经过十分钟的排版，程序代码的之间的格式很整齐，语句之间逻辑结果也明晰了。很快就将一些语法问题解决掉了。然后是问他处理流程。让我生气地是，他对处理流程不是很清楚，很多时候都是想当然。于是我让他讲所有的处理流程分层次写一下。小B一脸疑惑地看着我说：“这么简单的程序还要写文档呀”，我告诉他就是因为他少写了文档所以他现在才掉到坑里出不，看他一脸不乐意的样子，我说，我来大致的写一下，1程序要从session里读参数，2根据从session里多的参数从系统数据库里获得主表数据，然后根据这些数据在到数据库查询从表数据，3根据所有从数据库中查询结果显示。根据这个大致流程，系统可以分成三个大模块，1从session读参数，2从数据库读数据。3显示数据三个部分。而2有可以划分为2.1从主表读数据。2.2从从表读数据。功能模块有一个大致的划分之后，就要确定接口参数。1到2之间是一个字符串，2到3之间是一个二维结构的数组。2.1到2.2之间传入的是一个字符串。传出的是一个一维数据。整个系统被分成四个函数，每个函数都有专门的用途，这样结构基本清楚。而小B将所有代码都写在一起了，代码行过大，调试起来很困难。我建议小A先按照这种划分将函数编写完毕，然后再作其他处理。让我高兴的是小B抛弃了他原来的代码，按照新的结构划分设计了他的代码。而且代码严格按照层次之间空4个格的方式，新代码的逻辑结构很清楚。但令人奇怪的是新写的代码确总是出问题。问题的症状是无法从数据库中获得正确的数据。于是我们开始调试这段代码。 
首先，我告诉小A，代码的调试，最重要的是缩小问题的范围。我首先将第一个函数的内容注解掉，然后写了一个赋值语句，假设从session中获得了信息。然后再逐步看代码的运行。在系统生成sql查询语言的时候，将这段生成的SQL语言cut下来，然后放到，oracle的client端的SQL环境中去执行。sql语言可以执行，这就证明了构造SQL语言是正确的。但sql语言的查询结果集却是有问题。于是我又去看数据库的结果和存储的内容，这才发现原来数据库的设计有问题（具体问题不说了，简单说就是违反了数据设计的单一性）。所以必须经过一些特殊的处理才可以使用这些数据去构造下边的子表数据的查询SQL语言。但由于主表的结果是公用的。所以我们不能修改这个表结构。问题找到了。解决的方法也就有了。小B又开始了奋斗，半小时，基本搞定。本想回家了，小B却不干，非要请我吃饭，顺便想在问问开发的问题。这么好的同志，我怎么可以拒绝。于是将自己的一些想法和小B说了说。 
首先，我建议他写一下设计报告。很简单的道理，他干了四天半，系统一直有问题，而后来因为我们总结了系统流程很多问题立刻就暴露出来了，于是我们只用了半天就解决了问题。所以很多资料说编码工作的工作量只占这个开发工作量的10%是很对的。当然，基于小B开发的实际情况，我将以他这回先补设计报告，这么做虽然不正规但也是亡羊补牢。下回可以先写设计报告，哪怕只是在纸上画一个大致的框架也好，到第三个系统的时候就要先写设计，在编码了。这样一步一步来，有2，3个月的时间，他就会熟悉先设计在编码的方式。 
其次。我让他注意一下编码规范的问题，这个问题说大不大，说小不小，好的编码规范，代码之间的层次清楚，可读性，维护性都很好。包括函数的行数限制（函数行数最好20-40行，不要超过60）。变量定义的时候一定要初始化，变量名的如何取名。当然问题很多，给了他一本讲代码编程规范的数--代码大全。 
另外一个是体系的设计问题，比如我们的遇到的问题，其实是系统设计问题（虽然我们不能修改它，但不能证明它就是正确的），当初设计的时候没有遵循数据库设计的规范，为以后的工作添了很多麻烦。 
剩下的就是工作方法论的，比如如何调试，如何做设计，如何写代码，其实方法都一样，就是将复杂问题进行划分，分成若干小问题。逐步解决。
关于小B的培训，有几句要说的。 
1因为我现在不管理开发，所以对他的培训是一种私人帮助性质的，而如果是正规的培训效果会好很多。 
2培训首先要让被培训的人认识到培训的必要性。比如我在原来开发人员的培训工作中会先给他们两周作一个系统。然后对这个系统进行测试。一般来说没有开发人员能把这个系统开发的很好。 
3培训要有针对性。在系统测试完之后，第一步，是针对问题，讲解问题出在什么地方。这需要对开发比较熟悉（可以不熟悉开发语言，但一定要有很强的编码经验），帮助开发人员发现问题。其次，讲解编码的开发规范，比如层次之间格、函数的长度限制、写注解的方法、变量说明之后一定要初始化，资源的释放，一般掌握这些最容易犯错误的问题之后。开发人员的开发的代码的质量会提高很多。 
4培训要分层次进行。首先是讲解编码规范，然后是讲解设计的方法，这是很重要的，在学校了都讲解过调研、概要设计、详细设计、调试但却很少实践，在实际工作如何使用这些东西往往是开发人员所欠缺的。在讲解完编程规范后，我会要求开发人员编写详细设计报告（不必在修改错误的代码），然后采用走查的方法通过详细设计报告发现他们设计的问题。然后是概要设计报告，需求。这里要说明一点，正规的开发流程应该是先出需求报告，再概要设计、详细、编码，而我之所以反其道而行之，主要原因一个是开发人员比较好接受（他们习惯编码，而对设计很陌生），其次，让他们了解各种报告需要些什么东西。比如他们如果实现了一个信息管理系统，让他们写详细报告的时候，如果没有定义数据输入域的长度，我就会问他为什么这个输入域在编码的时候长度为10而不是12或8，并告诉他这些东西应该在详细设计报告中写出来，（编码的依据是详细设计报告，不能凭空自己决定）。同样的原理，数据输入长度在概要设计报告中也要写明，而最终这个信息是要在需求中写明的，最后明确告诉开发人员，需求报告是写概要设计的唯一依据，概要是写详细的唯一依据，详细是编码的唯一依据。采用反写报告的方法虽然不符合开发的实际情况，但却可以让大家对各种报告中应该写什么内容有一个比较明确的认识，对以后的写各种设计报告很有帮助。 
5要让被培训的开发人员了解开发的基本原理和方法，只是一个最困难的事情，比如无论是写设计报告，编码，和疑难技术问题的解决其实都是采用分解的方法，拿些报告来说，我要求他们先写第一类标题，全写完了再写第二类标题，然后是第三类标题，解决疑难技术问题的时候，现想明白处理的大致流程，让后把流程中的每一个步骤细化（逐步细化，不要一步到底），调研的时候也要求他们先搞明白框架，在逐步细化，这样做一个保证工作的完整性，其次降低问题的难度。层次关系也比较清楚。（这些实际工作经验不知道为什么学校里都不讲）而在实际工作是最有效的工作方法。 
6对被培训的人员要耐心，基本上每一个新开发人员都有自己的坏毛病。而改正这些毛病是很痛苦的事情。特别是在他们没有了解这些毛病的危害的时候，要一次让他们改正一个毛病，并鼓励他们坚持下去。