Chapter3 的整理细节如下：

Chapter3.类与继承

第22条：尽量用辅助类来维护程序的状态，而不要用字典和元组

要点：

• 不要使用包含其他字典的字典，也不要使用过长的元组。
• 如果容器中包含简单而又不可变的数据，那么可以先使用namedtuple来表示，待稍后有需要时，在修改为完整的类。
• 保存内部状态的字典如果变得比较复杂，那就应该把这些代码拆解为多个辅助类。

举个例子：本来记录每次学生考试的成绩的一个简单例子，由于不停地添加需求，比如增加记录此成绩占该科目总成绩的权重，等等，代码膨胀成如下这样：

class WeightedGradebook(object):
    def __init__(self):
        self._grades = {}

    def add_student(self, name):
        self._grades[name] = {}

    def report_grade(self, name, subject, score, weight):
        by_subject = self ...

继续，Chapter2的梳理如下：

Chapter2.函数

第14条：尽量用异常来表示特殊情况，而不要返回None

要点：

• 用None这个返回值来表示特殊意义的函数，很容易使调用者犯错，因为None和0 及空字符串之类的值，在条件表达式里都会评估为False；
• 函数在遇到特殊情况时，应该抛出异常，而不要返回None。调用者看到该函数的文档中所描述的异常之后，应该就会编写相应的代码来处理它们了。

举个例子：

def divide(a, b):
    try:
        return a / b
    except ZeroDivisionError:
        return None

这里会产生一个错觉，我们可能不会专门去判断函数的返回值是否为None，而是会假定：只要返回了与False 等效的运算结果，就说明函数出错了。

x, y = 0, 5
result = divide(x, y)
if not result ...

最近在看《Effective Python》这本书，觉得很不错，对于今后的代码如何写得更pythonic。整理下吧，后面可以反复看，感觉很多建议都非常实用。

下面是一些重点摘要：

Chapter1.用Pythonic 方式来思考

第1条：确认自己所用的Python 版本

没什么可说的，还是尽快把代码迁往py3.x吧，顺便写下如何了解所使用的具体版本python：

➜  ~ python --version
Python 2.7.10
➜  ~ python3 --version
Python 3.5.0

import sys
print(sys.version_info)
print(sys.version)

• 有两种版本的Python处于活跃的状态：python2 和 python3；
• 有多种流行的Python运行时环境，例如：CPython，Jython，IronPython 以及 ...

1.组织领域逻辑的三种主要模式

一.事务脚本

事务脚本具有如下几个优点：

• 它是一个大多数开发者都能理解的简单过程模型。
• 它能够与一个使用行数据入口或表数据入口的简单数据层很好地协作。
• 设定事务边界的方法显而易见：一个事务始于其脚本的打开，终于其脚本的关闭。很容易用工具在幕后设定事务边界。

但是，事务脚本也存在许多缺点，当领域逻辑复杂性增加时这些缺点就会凸现。当若干个事务需要做相似的动作时，通常使多个脚本中包含某些相同的代码。通过将这些代码提取出来组织成功公共的子例程可以部分消除这种情况，但在许多时候，消除副本仍比较棘手，而检测副本则更为困难。这使得应用程序没有清晰的结构。

二.领域逻辑

用领域模型而不是事务脚本正是面向对象的程序员所鼓吹的“理论体系转换”的精髓。在领域模型中，不再是由一个过程来控制用户某一动作的逻辑，而是由每一个对象都承担一部分的相关逻辑。

领域模型的开销来自使用上的复杂性和数据源层的复杂性。同时，我们也能够使用的组织细粒度逻辑结构的技术，例如继承，策略和其他面向对象的设计模式应用在领域模型上。

当领域逻辑很简单时，领域模型并不合适，因为要透彻理解这一模式需要很大代价，而且数据源层的复杂性也会在开发中增加许多工作量，这些努力此时不会得到回报。

三.表模块

1.企业应用的特点

• 企业应用一般涉及持久化数据;
• 企业应用一般涉及很多人同时访问数据;
• 企业应用还涉及大量操作数据的用户界面;
• 企业应用很少独立存在，通常需要与散布在企业周围的其他企业应用集成;
• 同时还会带来业务过程中的差异以及数据中概念的不一致性;
• 在业务开发的过程中，成千上万的"一次性特殊情况"最终导致了复杂的业务"无逻辑";

2.系统性能应该关注的几个指标

1. 响应时间：是指系统完成一次外部请求处理所需的时间，如用户的交互行为。
2. 响应性：响应性不同于请求处理，它是系统响应请求的速度有多快。
3. 等待时间：是获得系统任何形式响应的最小时间，即使应该做的工作并不存在，如调用过程中的线路传输。
4. 吞吐率：是给定时间内能够处理多大的请求量，通常用每秒事务数(tps)来度量。这种方法的一个问题是指标依赖与事务的复杂程度。
5. 负载：关于系统当前负荷的表述，也许可以用当前有多少用户与系统相连来表示。
6. 负载敏感度：是指响应时间随负载变化的程度。
7. 效率：是性能除以资源。如果一台双CPU系统的性能是30tps，另一个系统有4个同样的CPU系统性能是40tps，则前者效率高于后者。
8. 容量：系统的容量是指最大有效负载或者吞吐率的指标。它可以是一个绝对值最大值或者性能衰减至低于一个可接受的阈值之前的临界值 ...