第二十一章 协同构建 这一章中的21.2其实上周就有看，因为上周进行了结对编程。不过读书笔记写在了一起。 21.1 概要 有一个惊人的数据，设计期间程序员平均每小时会引入1 ~ 3个缺陷，编码期间平均每小时引入5 ~ 8个缺陷。 有许多同样惊人的数据显示，协同构建可以缩短开发周期，通过代码复查检查错 ...
分类：
其他好文 时间：
2018-04-26 18:22:07
阅读次数：
175
1.结构性定义 文件类型 <HTML></HTML> （放在档案的开头与结尾） 文件主题 <TITLE></TITLE> （必须放在「文头」区块内） 文头 <HEAD></HEAD> （描述性资料，像是「主题」） 文体 <BODY></BODY> （文件本体） （由浏览器控制的显示风格） 标题 <H ...
分类：
Web程序 时间：
2018-04-18 23:40:27
阅读次数：
276
记得这次与core组对接，为了一个命名为suanshi的文件笑了好久，其实我们自己在命名过程中也比较随意，虽然早过了大一那会用abc命名的年纪，但命名往往还是有点随心所欲，大小写，下划线，有的时候第二次用就多加一个字母或者少写一个字母，总之很混乱，有的时候再读自己的代码时想变量名代表什么都要想好久， ...
分类：
其他好文 时间：
2018-04-15 23:52:06
阅读次数：
281
第一部分：打好基础 + "第一章：欢迎进入软件构建的世界" + "第二章：用隐喻来更充分地理解软件开发" + "第三章：三思而后行：前期准备" + "第四章：关键的“构建”决策" 第二部分：创建高质量的代码 + "第五章：软件构建中的设计" + "第六章：可以工作的类" + "第七章：高质量的子程序 ...
分类：
其他好文 时间：
2018-04-06 16:45:16
阅读次数：
158
+ 在架构层将系统划分为多个子系统，以便让思绪在某段时间内能专注于系统的一小部分。 + 仔细定义类接口，从而可以忽略类内部的工作机理。 + 保持类接口的抽象性，从而不必记住不必要的细节。 + 避免全局变量，因为它会大大增加总是需要兼顾的代码比例。 + 避免深层次的继承，因为这样会耗费很大精力。 + ...
分类：
其他好文 时间：
2018-04-06 16:42:41
阅读次数：
115
核对表（自说明代码） + 你的类接口体现出某种一致的抽象吗？ + 你的类名有意义吗，能表明其中心意图吗？ + 你的类接凵对于如何使用该类显而易见吗？ + 你的类接囗能抽象到不需考虑其实现过程吗？能把类看成是黑盒吗？ 子程序 + 你的每个子程序名都能准确地指示该子程序确切干些什么吗？ + 你的各子程序 ...
分类：
其他好文 时间：
2018-04-06 16:04:39
阅读次数：
153
很多好的编程做法都能减轻你的大脑灰质细胞（指脑力）的负担。 + 将系统“分解”，是为了使之易于理解（“设计的层次”）。 + 进行审查、评审和测试正是为了减少人为失误。如果你从不犯错，就无须复审自己的软件。但要知道，人的智力是有限的，所以应和他人沟通，来提高软件质量。 + 将子程序编写得短小，以减轻大 ...
分类：
其他好文 时间：
2018-04-06 16:03:58
阅读次数：
150
神话：一个管理很完善的软件项目，应该首先以系统化的方法进行需求开发， 定义一份严谨的列表来描述程序的功能。设计完全遵循需求，并且完成得相当仔 细，这样就让程序员的代码编写工作能够从头至尾饩线型地工作。这也表明绝大 多数代码117欠编写后就己完美，测试通过即可被抛到脑后。如果这样的神话是真 的，那么代 ...
分类：
其他好文 时间：
2018-04-05 23:10:21
阅读次数：
179
》结对编程 》 正式检查 结对编程 成功运用结对编程的关键： + 用编码规范来支持结对编程 + 不要让结对编程编程旁观 + 不要强迫在简单的问题上使用结对编程 + 有规律的对结对人员和分配的工作任务进行轮换 + 鼓励双方跟上对方的步伐 + 确认两个人都能够看到显示器 + 不要强迫程序员与自己关系紧张 ...
分类：
其他好文 时间：
2018-04-05 19:14:26
阅读次数：
127
接下来的几个章节讲述几种基本的逻辑结构。 这次读书笔记相对短一点，因为我慢慢发现这本书真的细节太多了QWQ看得太快了完全记不住。 第十四章 组织直线型代码 14.1 必须有明确顺序的代码 对于具有明显的顺序关系的代码，应该使用顺序结构。 对于隐含的顺序关系，应该： 去除不合理的依赖关系（如不应该在C ...
分类：
其他好文 时间：
2018-04-05 18:35:57
阅读次数：
165
