11月阅读笔记其三

程序员修炼之道–从小工到专家——读书笔记

第四章注重实效的偏执
你不可能写出完美的软件；
防卫性编程，对自己错误也进行防御式编程；
断言式编程，主动检验自己的假定代码；
21 按合约设计
合约规定你的权利与责任，也规定对方的权利与责任；
DBC: 文档记载生命，并进行校验，是按合约设计(DBC)核心所在；
前条件：调用例程前，必须为真的条件；
后条件：例程保证会做的事情，例程完成时世界的状态；
类不变项：类确保从调用者的视角，该条件总为真；
允诺返回东西要尽可能少；
DBC最大好处迫使需求与保证的问题走到前台，列举输入域的范围是什么，边界条件是什么，允诺交付什么；
能够用断言做DBC的一切：断言不能沿着继承层向下遗传；代码增加；库不支持，不会被检查；
预处理器：会把这些注释展开成检验断言的代码；
DBC与早崩溃：谁负责检查前条件，调用者；通过早崩溃，在问题现场找到和诊断问题要容易的多；
不变项的用法
循环不变项：循环的最终目标陈述；
语义不变项：表达不可违反的需求；出错时要偏向消费者；
22 死程序不说谎
它不可能发生，是一种心理状态；
要崩溃，不要破坏：异常机制，确保对异常做出处理；
23 断言式编程
在自责中有一种满足感，当我们责备自己时，会觉得再没人有权责备我们；
这绝不会发生，如果它不可能发生，用断言确保它不会发生；
无论何时，你觉得那当然不可能发生，增加代码检查它，最容易的办法是用断言；
不要用断言代替真正的错误处理，断言检查是绝不应该发生的事；
让断言打开：断言增加开销，因为检查是不应该发生的事；
假定测试能找到所有的bug，防线检查任何可能的错误；
程序运行在危险的世界中，防线使用断言设法检测你疏漏的错误；
断言与副作用：不要因为增加断言，制造了新的错误；
24 何时使用异常
异常应该保留给意外事件；
将异常用于异常的问题，异常表示的即时的，非局部的控制转移；
错误处理器：exceptionHandler；
25 怎样配平资源
要有始有终，资源分配和解除分配的处理；
嵌套的分配：以资源分配的相反次序解除资源分配；代码不同地方分配同一资源，相同的次序分配它们，降低死锁发生的概率；
对象与异常：异常的地方解除资源棘手；构造器与析构器，finanlly；
当你无法配平资源时：为内存设一语义不变项，垃圾回收，引用计数；
检查配平；
第五章弯曲，或折断
26 解耦与德墨忒尔法则
前文正交性和合约设计的羞怯工作方式，不向别人暴露你自己，不与太多人打交道；
德墨忒尔法则，最小知识原则，把代码组织成最小单位/模块，并限制他们之间的交互；
使耦合程度最少；对象间的直接关系导致依赖关系的组合爆炸，修改影响很多模块，害怕修改；
德墨忒尔试图使程序中的模块耦合程度减至最低，设法阻止你为了获得第三个对象的方法访问而进入某个对象；
27 元程序设计
细节会弄乱我们整洁的代码，把细节赶出代码；
动态配置：让系统高度可配置，不要集成，用元数据描述应用的配置选项：参数，偏好，安装目录等；
元数据，是关于数据的数据；
将抽象放进代码，将细节放进元数据
迫使你解除你的设计的耦合；
迫使你通过推迟细节处理，创建更健壮、抽象的设计
无需重新编译应用，可以对齐进行定制；
与通用编程语言比，可以用更接近问题领域的方式表式元数据；
不要变写渡渡鸟代码：
没有元数据，代码及不能有它的适应性与灵活性；
28 时间耦合
时间是软件架构设计经常忽略的因素：并发和次序；
日常编写程序，经常事情是线性的；
通过容许并发，解除任何时间或次序上的依赖；
分析工作流、活动图、UML图，改善并发性；
用服务进行设计，降低组件的耦合；
用并发进行设计：必须对全局或静态变量加以保护，免于并发访问；不管次序如何，确保给出的是一致的状态信息；引导设计更整洁的接口；
29 它只是视图
事件使得系统耦合减至最少；
发布/订阅；推模式/拉模式；
视图与模型分离：
模型：表示目标对象的抽象数据模型；
视图：解释模型的方式；
控制器：控制视图，并向模型提供新数据的途径；
30 黑板
黑板方法：没有侦探需要知道其他任何侦探的存储；侦探可能受过不同训练，具有不同程度的背景；
很多项目设计工作流或分布式数据采集过程；
黑板系统让我们完全解除我们的对象之间的耦合，提供一个”论坛“，知识消费者和生成者可以在哪里匿名，异步交换数据；
一种键值对模型为基础实现；
与黑板有单一、一致的接口；消除了太多接口的需要，带来更优雅、一致的方案；
例子：黑板，结合封装法律需求的规则引擎；
第六章当你编码时
31 靠巧合编程
避免靠巧合编程-依靠运气和偶然的成功-要深思熟虑的编程；
如何靠巧合-一开始就不知道它为什么能工作；
实现的偶然-现在的代码编码方式导致，要开没有计入文档的错误或者边界条件；良好的模块化及把实现隐藏在撰写了良好文档的小接口之后；
不是真的能工作；
边界条件；
未记入文档；
多余调用，慢，引发bug；
语境的偶然
如何深思熟虑的编程?
总是意识到你在做什么；
不要盲目编程，构建不完全理解的应用或不熟悉的技术；
按照计划行事；
依靠可靠的事物，不要依靠巧合或假定；
为你的假定建立文档；
不要只是测试你的代码，还要测试你的假定；
为你的工作划分优先级，时间花在重要的的方面；
不要做历史的奴隶，实在不行就重构；
32 算法速率
估算算法使用的资源-时间、处理器、内存等；
O()表示法
O(1)常量型，O(lgn)对数，O(n)线性，O(nlgn)比线性差，O(n2）平方，O(Cn)指数；
100条1秒，1000条？O(1) 1秒， O(lgn)3秒，O(n) 10秒 O(nlgn) 33秒，O(n^2 100秒， O(2n)10263年
简单循环 n，嵌套循环 m*n，二分法 lgn，分而治之nlgn，组合
估算你算法的阶；
最好并非是总是最好的，合适的，注重实效；
33 重构
周遭所见皆是变易与衰败
重写、重做、重新架构合起来为重构；
何时重构？代码不合适，重复、非正交的设计、过时的知识、性能；
现实世界的复杂情况：时间压力的借口，肿瘤，早重构，常重构；
重构就是重新设计：
不要试图在重构的时候增加功能；
在开始重构之前，确保有良好的测试；
采取短小、深思熟虑的步骤，小布重构；
34 易于测试的代码
单元测试，对模块进行演练的代码；
针对合约进行测试；
为测试而设计
单元测试：说明你的模块的所有功能，文档；构建回归测试，验证未来对代码的改动是否正确；
使用测试装备：Junit
构建测试窗口
测试文化: 大大降低维护费用，减少客户服务电话；
测试你的软件，否则你的用户就得测试；
35 邪恶的向导
不要使用你不理解的向导代码；
开发者每天都依赖他们完全不理解的事物？如果开发知识依赖的库调用或标准的操作系统服务，但是向导代码编程了应用的完整组成部分；
————————————————
版权声明：本文为CSDN博主「匿名玩家-V」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u012605629/article/details/104664403