很多年前，当我还是一名计算机专业的大四学生时，整天上网浏览各类招聘信息，想找到一个合适的程序员实习岗位。除了实习岗位外，我偶尔也会点进一些“高级工程师”的招聘帖里。现在回想起那些帖子，抛开让人眼花缭乱的技术名词，我印象最深的就是常出现在第一行的岗位年限要求：“本职位要求

中很常见，因此改起来并不麻烦。将它们通通搞定后，程序终于可以正常运行了。经过简单的测试和验证，我发现它完美实现了我要的功能。之后我算了一笔时间账。从开始描述需求到调通整个程序，我一共花了

正是因为这样，对继承的态度也可以大致分为两类。大多数人认为，继承和多态、封装等特性一样，属于面向对象编程的几大核心特征之一。而同时有另一部分人觉得，继承带来的

如果某个类违反了“单一职责原则”，那意味着我们经常会因为不同的原因去修改它。这可能会导致不同功能之间相互影响。比如，可能我在某天调整了页面解析逻辑，却发现输出的文件格式也全部乱掉了。

9”的函数相比，新函数变得稍微复杂了一些。为了保证程序的正确性，我需要为它写一些单元测试。但当我准备写测试时，却发现这件事情非常麻烦，主要问题点如下：

这个函数虽然可以完成任务，但是相信不用我说你也能发现。它有着非常严重的性能问题。对于每一条去过普吉岛的记录，我们都需要遍历所有新西兰访问记录，尝试找到匹配。整个算法的时间复杂度是可怕的

里的“装饰器”和“面向对象”没有任何直接联系，它完全可以只是发生在函数和函数间的把戏。事实上，“装饰器”并没有提供某种无法替代的功能，它仅仅就是一颗“语法糖”而已。下面这段使用了装饰器的代码：

但我同时发现，这片黑魔法阵除了能带来好处，它还会引诱你不断往阵内塞入越来越多的代码，包括过滤掉无效元素、预处理数据、打印日志等等。甚至一些原本不属于同一抽象的内容，也会被塞入到同一片黑魔法阵内。

在前面我们提到异常捕获要精准、抽象级别要一致。但在现实世界中，如果你严格遵循这些流程，那么很有可能会碰上另外一个问题：异常处理逻辑太多，以至于扰乱了代码核心逻辑。具体表现就是，代码里充斥着大量的

所以我建议：尽量少写递归。如果你想用递归解决问题，先想想它是不是能方便的用循环来替代。如果答案是肯定的，那么就用循环来改写吧。如果迫不得已，一定需要使用递归时，请考虑下面几个点：