关于软件的质量

        本人工作两年多，一座BS架构为主，并没有太多的经验，一下都是我的个人感悟，如有不对的地方，还请指导。

        在我们开发一个软件时，我是在考虑我们要干什么，我们的软件要干什么，如何利用软件来提升现实生活中我们的工作效率，或者方便我们的生活。如果软件不能够改善我们的生活也不能进行科学研究，那么软件的存在又有什么意思。在明白我们要干什么之后，我们要严格的去考虑我们的软件能够实现的一些功能，并且分为多个重要程度，一定要实现的，可以去实现的，如果时间充裕可以去实现的。在考虑我们的软件要实现的功能的时候，同时我们也要将实现的成本考虑一些，如果成本和收益不成正比，就不一定要去实现。在知道我们的要干什么之后，我们应该考虑调研、需求分析、设计、开发、测试、实施等环节了。在这整个过程之中，我觉得都可以对软件的质量进行控制是必要的。对软件质量的控制就是给每个环节定义一个指标，以确保有一个可衡量的标准，否则一切都会变的不可控。

        调研的期间，我觉得可能对人的分析更多，软件的使用者是谁，有话语权的人对待这个项目的定位，跟你接洽的人是谁，需求需要和谁确定，又有谁能够拍板敲定。客户领导对待项目的态度，以及项目对他带来的利益，决定了你在该项目上所要花费的成本。需求能够和谁确定以及对方对需求的了解程度，这决定了你在软件中需求变动所花费的成本。一般的程序员是没有很好的沟通能力，也不能将立马从客户手中将需求挖掘出来，这些需要很强势的谈话和有过同类型项目的经验。甚至很多时候客户也不能理解自己的业务或者自己是什么的，和工作的流程，所以这时候需要项目经理对业务的理解能力和对问题重要性的判断能力。在调研期间，理解相关的人和要干什么是关键。保持好的客户关系能让你减少很多的麻烦。

        需求分析期间，需要将要做的事情定下来，这是一个权衡利弊的过程，这一步很关键，因为在考虑要做什么的时候，我们还要考虑实现的难度。也就是说在讨论需求的时候，我们就想要如何去实现了。在确定要做哪些事情之后，我想需求分析的工作就完成了一半。对所做的事情进行分类整理，在逻辑上能够将所要做的事情形成一种合理的结构。对于这些功能所要实现的结果给一个定义，如果能够详细最好，不能够详细的话，有经验的程序员也是自己可能完善的，就好比是一个查询，查询之后的列表所展示的信息有哪些(姓名、年龄、身份证)。在需求分析的时候，用来衡量成果的就是需求分析文档，这里面能够看出需求分析人员对于项目的理解，对于功能的提取是否很精练，有没有将几个功能能够划分到一个功能中，有没有将一个功能拆分为几个功能。对于功能模块的划分，我觉得要看模块之下的功能的关联性是否很强，以及他们划分的标准是否一致。我一直相信最简单的就是最好的，而且没有东西是复杂的，东西之所以复杂是因为人一直没有抓住重点。当然文档的结构是否清晰明了也很重要，如果公司有固定的文档格式那固然很不错。

        设计的时候，想必设计师已经对需求了然如胸。设计的第一步就是明白，当前系统是干什么的，在整个系统中处于一个什么样的位置，那就知道什么是可为什么是不可为。当前的系统和外围的系统的一些交互，是通过一些通讯协议还是通过其他的通道都没有关系，但是这些肯定是在设计的时候就考虑到的。然后就是选型了，是用什么技术实现。选型完了之后就是具体的设计了，如果是分层的话就是对每一层经行设计，这些设计就是业务与技术的整合。而且每层之间的依赖关系是十分重要的。很多的bs项目在设计的时候就将数据库设计好了，数据库的设计是对逻辑层的一种限制，因为你总无法存储数据库中没有的一个字段，而且你的持久层选择使用数据库来实现，你总不至于将一些关联的信息通过文件的来存储在硬盘上吧。在设计的时候肯定能够对之后的开发进行约束。设计的衡量结果是设计人员是否能够将整个项目牢牢的把握，甚至需要考虑技术上的风险和可能出现的问题。设计人员的设计概要清晰明了，其中于包括外围系统之间的调用关系和接口，数据库表之间的关系，服务器端所使用的技术，这些技术的调用接口，服务器的拓展性，主要业务逻辑调用的活动图。这些东西能够让开发人员快速的开发，甚至避免遇到各种不必要麻烦(比如说因为数据库设计的不合理，开发人员要拼一个执行时间很长的sql语句)。

        开发的时候，如果前面都做的很好的话，我想开发的时候不会遇到太大困难。如果之前做的不好的话，所有的问题恐怕都要在开发这一步解决。因为大部分人认为开发能够解决所有问题，而且不细分这些工作的话，开发人员可能要干以上所有的活。任何在开发中遇到的问题都可以算在软件开发人员的技术能力上，而且一些有经验的工程师对于解决在开发中遇到的设计时就存在的问题或者不合理的需求已经很有经验了。我对开发的要求很简单，任何能够提取的东西尽量的提取，而且编码保持一致。不希望在一段类似的代码中出现两种截然不同的编码风格。如果你的代码我一眼就能看懂，那我就觉得很不错。如果有时间就重构吧！

        测试时一个非常重要的环节，如果开发人员的技术能力不足的话，那问题只能在测试的时候暴露。我遇到很多的项目把测试工作外包给其他公司了，还有些公司内部会有测试团队。我的个人建议是个人确保自己的工作没有问题，然后可以内部交叉测试，如果有技术实力做自动化测试的话也可以试试自动化测试，然后提交测试组。测试的时候暴露的问题并不是软件中的所有问题，只能说是一些显而易见的问题。然后就是对于性能的测试，当然更多的时候，一些项目根本就不需要性能测试，我不明白一个企业内部使用，只有一百多个用户，常用只有几十个用户的系统要什么压力测试。测试的重要性显而易见，如果bug在这里没有发现就会流到了客户那里。测试的结果至少让我们在正常的页面点击时不会出现问题，如果错误的话那要给客户一个错误提示页面，而不是一些堆栈异常。