目录
第十二章:基本数据类型
-
避免使用神秘的数字;
好处:方便统一修改;提高代码可读性;
-
参数标明数据类型
-
避免混合类型的比较
-
注意编译的警告
各类型注意事项:
整数:
检查整数除法,
检查整数溢出;因为程序的数字计算是二进制的
浮点数:注意尾差
处理尾差注意:使用双精度;将浮点数变为整型存储,比如金额存分;
字符串:
避免使用神秘的字符或字符串,用常量标示;
布尔:
将项目中一个复杂的条件语句用变量简化,方便阅读;
用枚举代替布尔,让表达更清晰;
常量:
多处使用的参数常量化;
用常量代替一些数字或字符串,方便阅读以及后期修改;
数组:
数组赋值时注意下标,别弄混;
第十四章:组织直线性代码
- 必须有明确的顺序语句:就是能清晰的看到下面的语句用到上面语句获得的参数,让整体更连贯
- 让代码的依赖关系变得更明确:
- 是子程序能凸显依赖关系:子程序的名称比较清晰
- 利用子程序参数明确显示依赖关系:
- 对不清晰的依赖关系加注释;
- 把相关的语句组织在一起:相关的语句指都处理相同的数据、执行了相似的任务,或在执行顺序上有某种关联;
第十五章:使用条件语句
将常见的情况(放在前面)放在if后面不要放在else后面,方便阅读;
第十六章:控制循环
循环体里面的代码尽可能的简介,易懂
循环体嵌套不要超过三层;
第二十章:软件质量
软件质量外在特征:正确性、可用性、效率、可靠性(平稳无故障)、适应性(系统能在不同的环境运行)、精确性(输出结果的误差程度)、健壮性;
软件质量内在特征:可维护性、灵活性、可移植性、可重用性、可读性、可测试性、可理解性
改善软件质量:明确定义质保工作、测试策略、软件工程指南、非正式技术复查、外部审核
什么时候进行质量保证:开工之时就该开始做好质量保证
要点:提高生产效率和改善质量的最佳途径就是减少花在这种代码返工上的时间,无论返工的代码是由需求,设计改变还是调试引起的。
第二十一章:协同构件
结对编程理解:是指两位程序员肩并肩地坐在同一台电脑前合作完成同一个设计、同一个算法以及同一段代码,并且两人的角色可以随时互换
成功运用结对编程的关键:
用编码规范来支持结对编码;
不要让结对编程编程旁观(不编程的人应该一主观的思维去考虑功能代码的实现以及后期实现、测试);不要强迫在简单的问题是上使用结对编程;
有规律的对结对人员和分配工作的人员进行调换;
鼓励双方跟上对方步伐;
确认都能看到显示器;
不要强迫结对;
避免新手组合;
指定一个组长;
好处:
可以相互学习;
相互提升;
改善代码质量;
利于培养集体荣誉感;
第二十二章:开发中测试
单元测试:将项目中的一个完整的类、子程序从系统中隔离出来测试
组件测试:组件可能会被多个系统用到,也是将项目中的一个完整的类、子程序从系统中隔离出来测试;
集成测试:对多个类进行联合测试
回归测试:重复测之前测过的
系统测试:对整体测试
错误并非平均地分布在所有的子程序里面,二是集中在少数几个子程序里面。
大多数错误的影响范围是相当有限的(不超过一个子程序)。
大多数的构建期的错误是编人员的失误造成的。
笔误(拼写错误)是一个常见的问题根源
很多错误是由于没有彻底地理解设计
软件质量的普遍原则:开发高质量的软件,比开发低质量软件然后修正的成本要低廉。
第二十三章:调试
如何在调试中有收获:
理解你正在编写的程序;
明确你犯错的类型;
以代码阅读者的角度分析你的代码;
审视自己解决问题的方法;
低效的调试方法:
凭猜测找出缺陷
把时间浪费在理解上
科学的调试方法:
收集数据
根据相关数据统计构造一个假设;
设置推翻假设
证明反正假设;
反复上面操作
第二十四章:重构
重构策略:
在增加子程序、类时进行重构
在修补缺陷时进行重构
关注容易出错的模块
关注高度复杂的模块
如果在维护一个系统,改善你手中正在处理的代码。确保代码在离开你的时候比来之前更健康。
定义清楚干净代码和拙劣代码之间的边界,然后尝试把代码移过这条边界。
第二十五章:代码调整策略
性能和代码调整应该考虑的方向:
程序需求:是否真正的有必要优化,
程序设计:;
类和子程序的设计
同操作系统的交互;
代码编译;
代码调整;
代码调整总结:
- 用设计良好的代码来开发网站是程序易于理解和修改
第二十六章:代码调整方法
- 按照出现频率来调整判断顺序:让运行最快和判断结果最有可能出现的先被执行;
- 尽可能少的在循环内部做工作,涉及到计算的可以在循环外部做的都在循环外部做穿进去;
- 用哨兵值结束循环,
- 把最忙的循环放在最内层
数据变换:
尽量用整型
尽可能减少数组引用:将数组的值赋给一个变量,方便后期多处访问,
第二十七章:程序规模对构建的影响
随着项目规模的增大,更大一部分错误要归咎于需求和设计。
随着项目规模的增长,构建活动将只占项目总工作量的一小部分。
小项目以构件为主,更大的项目需要做更多的架构、集成工作和系统测试工作才能完成;
对于大项目来说,如果不有意识地去选择方法论,就将无法完成任务。
项目越正规,你不得不写的文件的数量也越来越多,用于确认你已经完成了自己的工作。
随着项目规模的扩大,交流需要加以支持。大多数方法论的关键点都在于减少交流中的问题,而一项方法论的存亡关键也应取决于它能否促进交流。
在其他条件都相等的时候,大项目的生产率会低于小项目。而大项目的每千行代码错误会高于小项目。
在小项目里的一些看起来“理当如此”的活动在大项目中必须仔细地计划。随着项目规模扩大,构建活动的主导地位逐渐降低。
放大轻量级方法论要好于缩小重量级方法论。最有效的办法是使用“适量级”方法论。
第二十八章:管理构筑
鼓励良好的编程:
每个项目的每一部分分派两个人:结对编程
代码评审;
要求审查签名
经常拿出一些好的代码示例做参考
强调代码是公有财产:需要有意识这段代码别人也需要容易理解的使用
奖励好的代码
配置管理:系统化的定义项目工件和处理变化,使项目一直保持七完整性;
需求变更和设计变更:
遵循某种系统化的变更控制手续。
成组地处理变更请求。记下所有的想法和建议,不管它实现起来有多容易。把它记录下来,直到你有时间取处理它们。到那时,把它当做整体来看待,从中选中最有益的一些变更来加以实施。
进度落后时,增加时间通常并不可行。
任何一种项目特征都是可以用某种方法来度量的,而且总会比根本不度量好得多。度量结果也许不会完全精确,度量也许很难做,而且也需要持续不断地改善结果,但是它能使你对软件开发过程进行控制,而如果不度量就根本不可能控制。
程序员之间有着数量级的差异。即时个体程序员都一样,不同编程团队在软件质量和生产率上也有着相当大的差异。
评估构件进度表:
建立目标;
为评估流出时间,并且做出计划;
清楚的说明软件需求
在底层细节层面进行评估:将项目做出详细的考察,想的尽可能细致
使用若干不同的评估方法,并且比较结果
定期做重新评估
第二十九章:集成
集成好处:
更容易诊断错误;
缺陷更少
可以花费更少的时间获得一个能工作的产品
更短的整体开发进度表
更好的顾客关系
增加项目完成的机会
更可靠的估计进度表
更准确的现状报告
改善代码质量
减少文档
要点:
构建的先后顺序和集成的步骤会影响涉及、编码、测试各类的顺序。
一个经过充分思考的集成顺序能减少测试的工作量,并使调试变容易。
增量集成有若干变型,而且–除非项目是微不足道的–任何一种形式的增量集成都比阶段式集成好。
针对每个特定的项目,最佳的集成步骤通常是自顶向下、自底向上、风险导向以及其他集成方法的某种组合。T型集成和竖直分块集成通常都能工作得很好。
Daily Build能减少集成的问题,提升开发人员的士气,并提供非常有用的项目管理信息。
增量集成策略:
自顶向下集成:先加入顶部的类,最好加入底部的类;