《代码大全2》学习笔记1

第一部分:打好基础

第一章

构建包括的范围很大:

定义问题

需求分析

规划构建

软件架构(高层设计)

详细设计

编码与调试

单元测试

集成测试

集成

系统维护

保障维护

----------------

平时接触的也就是从详细设计到系统维护,

后面的测试和技术支持都是必须要打交道的,

但是定义问题和需求,基本都属于产品部门。

----------------

P7:“很多项目,程序员得到的唯一文档就是源代码本身。需求规格书和设计文档可能过时,但是源代码是最新的”

――基本如此,很多工程只有在编码之前有需求文档和设计文档,在以后的修改中,基本都不会去修改这2个文档。

----------------

构建活动主要是从详细设计到开发者测试,也就是程序员的工作,从设计到编码实现,到最后的自测试。

P7:“构建活动是唯一一项确保会完成的工作”

因为时间原因,需求可能是临时的,测试可能是不充分的,但是代码必须编码完成。

――以前有个培训,排名程序员的各项条件,我把诚实放到后面了,不是它不重要,而是没有办法去不诚实,跟卖商品不一样,有没有实现需求,靠嘴说谎马上就要露馅。

 

第二章

“隐喻的重要性。”

“使用隐喻的方法叫建模。比如分子运动理论是撞球,光的波粒二象性。”

“编程最大的调整是问题概念化,编程中很多错误是概念性的错误。”――个人认为,不应该是编程中,开始编程基本概念已经确定了,而是在前三步(定义问题,需求分析,规划构建)

“把软件的构建过程比作房屋的建设过程,移动承重墙肯定比移动隔墙成本低,软件的结构改变也根本比周边功能改动成本高。”

 

第三章

“准备工作的中心目标是减低风险。”

“建设大厦和搭建狗舍的前期准备肯定不一样。”

“测试不能测试出‘设计了一个错误的产品’,解决缺陷要在构建活动之前完成”

准备工作不周全的原因“

1、绝大多数开发人员没有需求、产品方面的经验和训练。

2、程序员无法抵御‘尽快开始编码’的欲望。

3、管理者对准备工作的重要性不理解。

--------------------

――对2深有体会,每次总是喜欢写个大致的详细设计,然后立刻投入编码,不过似乎只有在编码中才能更好的去构想细节,如果不编码那么脑袋里面就没有具体的印象,可能是没有使用伪代码编程的习惯,在后面的章节里面有伪代码编程的例子。

这也同样导致了我宁愿一个人加班完成工作,也不原因和别人合作完成一个程序。

不过在实际中,可能是我的团队人数都很少,一个人的效率要比几个人合作高的多。而且就算是分开每人维护一个模块,接口的调试都会花去很多时间。如果2个模块是自己一个人负责的,接口的调试很快就通过了。这或许也是最早设计报文格式的时候不周全导致的。

-------------------

“有时候用户一开始不完全确定自己想要什么,找出他们真正想要的,比做一个错误的东西再修正要好多了。”

没有直接面对客户,也没有直接的感觉,但是客户经常会提出永远都用不到还必须要有的功能。

 

“需求、架构、构建,缺陷越靠前,修改的成本越大。”

------------------

“我们最好立即编码,后面有很多调试要做。”和“我们没有为测试安排太多时间,因为将来不会发现太多的缺陷。”

相对而言,第二个比第一个好。

-----------------

“迭代法开发比序列开发节约成本”

迭代法就是随着项目的进展,开始检查并返工,再进行下一步的开发。

序列法是开发完成后检查并返工。

-----------------

“问题定义只是定义了问题是什么,而不涉及解决方案。”

“问题定义要用顾客的语言来书写,而不是用计算机的专业术语来叙述。”

‘我们的出口带宽总是跑满’,‘我们需要优化缓存系统,让出口带宽不要跑满’

明显前一个是问题,而后一个不像问题,倒像一个解决方案了。

----------------

“明确需求有助于用户驾驭系统功能,有助于避免程序员之间的争论”

――感觉很多程序做出来,发现需求理解的不一样,往往研发之间无关紧要的就糊过去了,最多的争论在于研发和测试对它的不同理解。

“客户经常改动需求,IBM的统计平均开发过程中,需求会有25%的改动。”

“客户往往喜欢拍脑门,用成本和进度可以提醒他们。”

――哈

 

P42针对功能需求有疑问,这么详细的外部接口,包括握手协议,通信协议到底是属于需求还是属于详细设计?感觉不应该是需求层的啊。

P46数据设计也一样的疑问,不过里面提到的,使用什么数据结构或算法要写出为什么这么用的好处,便于让程序员洞察构架师的思想。

“数据通常只有一个子程序或一个类之间访问”

“程序员会处于专业自豪感,对自己编写的类做过度工程”

――的确是事实啊,但是如果有时间的话,难道不好吗?

“架构应该描述所有主要决策的动机,而不是向来如此”

“优秀的架构很大程度上与机器和编程语言无关,但是也不能忽视环境。独立于环境的好处是避免过度架构。”

 

第四章

构架决策:

选择编程语言

编程约定(代码规范和风格、性能or稳定)

团队工作(代码管理cvs,如何分工)

质量保证(先写测试用例,评审)

工具(代码管理工具、编译工具)


你可能感兴趣的:(程序员,源代码,技术支持)