Loki bio photo

Loki

Android & iOS & H5 Developer,做有趣的事情,探寻有趣之物.

Email Github

《代码大全》读书笔记目录

  1. 第一部分 打好基础
  2. 第二部分 创建高质量代码
  3. 第三部分 变量
  4. 第四部分 语句
  5. 第五部分 代码改善
  6. 第六部分 系统考虑
  7. 第七部分 软件工艺

第五部分的主题是改善代码,作者主要从软件质量,协同构建,开发者测试,调试,重构,代码策略调整几个部分来进行阐述的.

读书笔记

软件同时拥有包括内在以及外在的质量特性.

软件的外在特性指的是该产品的用户能够感受到的部分,包括正确性,可用性,效率,可靠性,完整性,适应性,精确性,健壮性.

质量的外在特性是用户关心的唯一软件特性.

软件的内在特性包括可维护性,灵活性,可移植性,可重用性,可读性,可测试性,可理解性,程序员更关注此方面特性.

单元测试以及集成测试,它们的一般检测率仅仅在30%到35%之间.

大部分研究都发现,检查比测试的成本更小.

一个缺陷存在的时间越长,消除它的代价就越高昂.

软件质量的普遍原理就是改善质量以降低开发成本.

提高生产效率和改善质量的最佳途径就是减少花在代码返工上单时间,无论返工的代码是由需求,设计改变还是调试引起的.

缺陷最少的软件项目的开发计划时间最短,并拥有最高的开发生产率,消除软件缺陷实际上是最昂贵且最耗时的一种软件工作(Jones 2000)

开发质量代码最终并没有要求你付出更多,只是你需要对资源进行重新分配,以低廉的成本来防止缺陷出现,从而避免代价高昂的修正工作.

协同构建包括结对编程,正式检查,非正式技术复查,文档阅读以及其他让开发人员共同承担创建代码及其他工作产品责任的技术.

全程采用结对编程的成本可能比单人开发要高大约10%~25%,但开发周期大概会缩短45%.

并不是任何结对编程都是有效的,其关键在于:

用编码规范来支持结对编程
不要让结对编程变成旁观
不要强迫在简单的问题上使用结对编程
有规律地结对人员和分配的工作任务进行轮换
鼓励双方跟上对方的步伐
确认两个人都能够看到显示器
不要强迫程序员与自己关系紧张的人组对
避免新手组合
指定一个组长

协同开发实践往往能比测试发现更多的缺陷,并且更有效率.

80%的错误存在于项目20%的类或者子程序中, 50%的错误被发现存在于项目5%的类当中.

开发高质量的软件,比开发低质量软件然后修正的成本要低廉.

开发高质量软件产品的最佳途径是精确描述需求,完善设计,并使用高质量的代码编写规范.

经验丰富的程序员找出缺陷所用的时间跟缺乏经验的程序员相比,大约少一个数量级.

相对于大规模的修改,小的改动更容易出错(Weinberg 1983)

开发阶段的重构是提升程序质量的最佳时机.

性能同代码速度之间存在着很松散的联系.

为性能优化工作做最好准备的最佳方式就是在最初阶段编写清晰的代码,从而使代码在后续工作中易于理解和修改.

优化结果在不同的语言,编译器和环境下有很大差异.

后感

代码改善最好的方法就是写之前所有的东西都想好,考虑周全,在传统IT行业,或者说的更直白一点,在非常稳定成熟的项目中,交付给程序员的往往是非常确定的需求,在此基础上做开发,往往能够减少很多错误,节省很多不必要的时间, 一些在外企待过的同事,所描述的软件开发流程,对于国内,尤其是互联网行业来说,简直是遥不可及.

现在的产品开发也好,迭代也好,国内的都讲究一个快,在tx这边所参与的一些项目,太多的需求都是设计师出演示图的时候就被要求去做,一个需求反复修改太正常不过了,自身碰到过 最奇葩的一个需求重复做了七八遍.

归根结底都是流程上的不规范,如果在不规范的流程上,去严格按照某些条例去做,所耗费的成本是很大的.

就像作者说的,所有的软件开发,需求也好,架构也好,开发调试也好,修复bug也好,都离不开人,所有的问题,最终都会回归到人的层面去考虑,抛开人性去谈论这些问题,其实都不是非常切合实际.