注重实效的途径
7, 重复的危害：
DRY--不要重复你自己。
系统中的每一项知识都必须具有单一、无歧义、权威的表示。
重复是怎样发生的：
强加的重复，无意的重复，无耐性的重复，开发者之间的重复。
强加的重复：
信息的多种表示。编写简单的过滤器或者代码生成器，自动化。
代码中的文档。注释来表达一些高级的东西，不是代码层面。
文档与代码。可以考虑生成代码或者生产文档。自动化测试的例子。
语言问题。头文件重复。但是可以在头文件写接口说明，实现文件写实际细节。
无意的重复：
用访问器来读写对象的属性，可以使其封装。发生变更也只是内部影响。
无耐性的重复：
简单的拷贝修改，可能会给以后带来更多的问题。最好的办法就是修改。
开发者之间的重复：
及时沟通，多看别人写的代码。
让复用变得容易。
8, 正交性：（高内聚低耦合？）
正交的好处：
消除无关事物之间的影响。
提高生产率：
改动得以局部化，所以开发时间和测试时间得以降低。
正交的途径还能够促进复用。
如果你对正交的组建进行组合，生产率会有相当微妙的提高。M*N
降低风险：
正交的途径能降低任何开发中固有的风险。
有问题的代码区域被隔离开来。
所得系统更健壮。
正交系统很可能得到更好的测试。
你不会与特定的供应商、产品、或是平台紧绑在一起。
项目团队
正交化，使得各自责任清晰，重叠变小。但是也要多交流。
设计
分层的途径是设计正交系统的强大方式。
修改某个需求，应该只有一个模块受影响。
MVC。
不要依赖你无法控制的事物。
工具箱与库
明智地选择技术。方便使用，方便更换。
编码
让你的代码保持解耦。跟其他模块代码隔离。
避免使用全局变量。1：使用全局变量，会把自己与共享该数据的其他组建绑架。修改多线程不方便。2：可以把所需要的语境显式的传入模块。换句话说，你可以创建包含语境的结构，并传递指向这些结构的引用。3：单例模式可能造成不必要的关联。
避免编写类似的函数。重复代码可能是结构问题。设计模式的策略模式。这就是重构啦。
测试
正交系统易于测试。修改bug时需要修改很多地方吗？考虑重构。
文档
内容和表现形式。改变外观很容易。
认同正交性
运用DRY原则，你是在寻求使系统中的重复降至最小；运用正交性原则，你可以降低系统的各组件的相互依赖。最终系统变得灵活，易于理解，更易于调试、测试和维护。善莫大焉。
9, 可撤销性
不存在最终决策。
灵活的架构：
配置文件，把第三方代码隐藏在定义良好的抽象接口后边。
去你妹的薛定谔的猫。
10, 曳光弹
如果不明确的时候。
经典的做法是把系统定死。制作大量的文档，逐一列出每项需求、确定所有未知元素、并限定环境。
在黑暗中发光的代码：
用曳光弹找到目标。
总有改动需要完成，总有功能需要增加，这是一个渐进的过程。
曳光代码的有点如下
1, 用户能够及早靠到能工作的东西。从差变好的过程。
2, 开发者构建了一个他们能在其中工作的结构。有一个蓝本，可以接着做。
3, 你有了一个集成平台。每个改动都可以集成了。调试和测试变得更快和更准确。
4, 你有了可用于演示的东西。投资人。
5, 你将能够感觉到工作进展。不断激励。
曳光弹并非总能击中目标
demo，尝试，可以帮助找到目标。什么技术，什么样子，什么数据库，什么架构。
曳光代码 vs 原型制作
原型制作生成用过就扔的代码。
曳光代码虽然简单，但是可以运行的，完整的，并且构成了最终系统的骨架的一部分。
11, 原型与便签，像是说画图？草图？
12, 领域语言
靠近问题领域进行编程
数据语言与命令语言
独立语言与嵌入式语言
修改应用读取的脚本，就可以修改应用的行为，却不需要编译。
易于开发还是易于维护
可扩展性和维护，建议采用更复杂的更好的语言。
BNF文法是什么东西？？？
这一节的练习很有价值！
13, 估算
估算，以避免发生意外。
时间越长，估算单位提高代表准确程度适度下降。
估算需要借助自己或他人的经验。
理解提问内容，选择的范围，思考的前提。
建立系统的模型
把模型理解为组建。
给每个参数指定值。
计算答案。四分之三秒和750ms不同的感觉。
追踪你的估算能力。调整
估算项目进度。通过代码对进度表进行迭代。
在被要求进行估算时说什么。我等会儿回答你。
763
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
