读了《代码质量》的试读部分，先说说我们在试读章节中学到什么？
所谓的质量，我们所关心的是哪些方面的质量。
1、使用中的质量。是人们最普遍觉察到的质量的方面。也就是真实的终端用户体验。广泛地讲，这个方面反映了用户在一个特定环境下达成自己目标的程度。作为软件开发人员，我们关心用户对于软件的感觉如何。我们对用户永远都不会碰到的程序错误没有兴趣，对于难以理解的代码，或者虽然效率不高但是对于用户所处理的数据量来说没什么影响的算法也不感兴趣。
2、外部质量属性。外部质量方面包括可以通过运行软件确定的方方面面。。通过彻底地测试并修正软件外部质量方面的问题，我们能够把终端用户将要面对的错误最小化。
3、内部质量属性。在软件中，这些属性都是可以通过检查而非运行来确定的。
4、过程质量。很多软件开发商都会使用成熟的框架，就像软件能力成熟度模型（CMMI，Capability Maturity Model Integration）或者ISO 9001，来组织文档化的、可重复的、既定的、受管理的和已优化的软件制造过程。在我们的领域中，似乎一些软件开发组织过分强调了过程，其代价是损害了产品本身及用户，结果不可避免地南辕北辙。
软件的内部与外部质量特性可以归类为哪几个方面呢？
1、功能性。首先是一个与软件做什么而非怎么做相关的质量特征。软件功能性的要素包括：面向指定任务的具体功能与用户目标的相配度、结果或执行的准确性、该软件与其他系统的互操作性，以及该软件为它的数据提供的安全性。
2、可靠性。指的是软件在特定情况下维持既定的性能表现级别的能力。可靠性的要素包括：表明软件中存在的错误多少的成熟性、表示软件在出现某些错误的情况下继续工作的能力的容错性、软件在出现故障之后能够恢复数据并且继续运行的可复原性。
3、可用性。从根本上来看，是一个外部的质量特征。它的三个要素：可理解性--，我们是否可以很容易地搞清楚软件能不能满足使用需求及如何用它来完成某个特定的任务；易学性--掌握它所需要付出的努力；可操作性--使用它所耗费的精力。
4、效率。涉及计算的阴阳两个要素：空间和时间。
5、可维护性。可能是在软件的设计及真正的代码中最能够被实现的要素。个人对可维护性很感兴趣，所以在后面我也将说说自己的感受。
6、可移植性。指的是将软件从一个环境（如Windows）移植到另一个环境（如Mac OS X）的难易程度。
在试读章节中我们了解了很多概念性的东西。那么在我们的工作中我们对代码质量有哪些看法呢？
第一、可读性 。首先软件行业是个团队型的行业，我们每个人开发的代码都可能被团队其他成员维护。在同一个项目或者同一个模块工作的开发者之间一定要彼此理解对方所写的代码。为了减少沟通的时间，提高合作效率，大家最好是在一份理解地比较透彻的代码库上进行协作。如果发现某段代码出现难于理解的情况，立即自我检查、并于其他同事讨论，大家一起拿出来个所有人都易于理解的办法来。其次在没有系统地学习敏捷开发等代码管控技术之前，经常会发生这样的情况，拿出自己前几个月几周甚至几天编写的代码云里雾里，不知道自己当初为什么这么写，所以我们常常面对这样的问题，一方面要努力理解自己之前为什么这么写，一方面又要理解其他成员的难以理解的代码。这样效率问题就不言而喻了。
第二、起个好名字 。无论是变量、函数还是方法我们都应给个有意义的名字。看名知意（想用个合适的词想不起来了，大家理解哈），比如employees_name,让人一看就知道这个变量是什么意思。而不是要用flg、test1.。。。。。
第三、代码格式化 。NetBeans IDE中这样称呼，其实就是排版。这个看着似乎很没有意义的事情，其实我觉得是个人很好的习惯。其实代码排版这种略带个人化的东西，不仅仅是让代码看起来更漂亮，其根本目的还是着眼于代码的可读性，要有助于代码的理解、维护、纠错。具体到执行层面。
第四、写好注释 。注释的作用是什么？是加深代码使用者的理解程度。当然注释也不是越多越好越全越好，对于一些显而易见的代码就不需要注释了。对于参数的取值范围、参数非法时是否会造成异常、设置的新值是否会立刻生效等等就应该明确定义。
以上就是通过《代码质量》这本书学到的和想到的，希望对以后的工作有帮助。