代码大全学习笔记3

    周末又花了半个下午的时间看了一章代码大全。发现如果是开着电脑看,总也不能集中精神,于是关了电脑,用笔和纸来做学习笔记。现在再来把记好的东西转过来。
    (more…)

代码大全读书笔记2

用什么方式对软件开发这件事进行建模比较合适?

    软件开发就像写信?
a. 寄出去即为结束?
b. 典型的软件系统在其首次发布之后的工作量,可能达到整个工作量的90%,典型情况下也有2/3之多。
c. 对写作而言,最重要是原创性。但是对于软件构建来说,“努力创造真正的原创成果”的开发效率,往往低于专注于重用以往项目的一些设计思想、代码以及测试用例的开发效率

    培养、种植软件?

    “建筑”软件?

 智慧为工具箱
    技术并不是规则,它是分析的工具

代码大全读书笔记1

    原来很少在自己的blog里面写技术,以至我的blog连个“技术”的分类都没有。这次在team中制定了学习基础开发知识的任务,大家下来都要做homework。正好趁这个时候强迫自己把借来很长时间没怎么看的《代码大全》看了。以后每周会至少写两篇读书笔记。绝对不会全部生抄书上的东西,每一条都是自己个人有所感。到时候总结一下blog就可以做ppt出来讲了。

1. 软件开发在我们公司跟项目中实际上是一件很严肃和理性的事情

2. 开发人员,应该回过头来,更多地关注构建部分
a. 不同程序员的生产率差异可达20倍
b. 构建活动在整个开发活动总时间所占比例为30%–80%之间,而在我们这样的团队,其他的70%–20%工作实际上交由其他team完成。

3. 提高我们生产率和提高我们专业程度的方法—专注于以下方面(同属软件构建的不同部分)
a. 验证有关的基础工作已经完成,因此构建活动可以顺利地进行下去
b. 确定如何测试所写代码
c. 设计并编写类和子程序
d. 创建并命名变量和常量
e. 选择控制结构,组织语句块
f. 对你的代码进行单元测试和集成测试,并排除其中的错误
g. 评审开发团队其他成员的底层设计和代码,并让他们评审你的工作
h. 润饰代码,爱惜进行代码的格式化和注释
i. 将单独开发的多个软件组件集成为一体
j. 调优代码,让它更快、更省资源

4。 应该更广义地理解“模型”,其不仅仅是对隐晦、不直观概念的生动表达,其更表达了我们看问题的角度和方式。当模型本身被制定出来以后,它就已经限制了我们对模型所描述问题的认知。

5. 1973年,数据处理从“以计算机为中心”到“以数据库为中心”转变。把焦点从“在计算机中流动的数据流”转为“以数据池”为中心,已经36年了。是不是这个模型已经阻碍了“数据处理”的进一步发展?

6. 如何给我们在公司的软件开发活动下一个定义?
写作?
就像写信那样去write代码?
(个人觉得这个非常好,作者试着在这部分对不同的软件开发方式下定义,只要有了定义,就有了正确的模型,有了正确的着重点和学习、分析方式。所以这部分准备下次完整地一下看完)