抽象层——问题分解

What are the Secrets?

• A few(somewhat vague) overall concepts

  • Working code isn't enough: must minimize complexity （最小化复杂度）

  • Complexity comes from dependencies and obscurity

  • Strategic vs tactical programming （战略 VS 战术）

  • Classes should be deep （接口简洁，隐藏复杂的实现）

  • General-pirpose classes are deeper

  • New layer, new abstraction

  • Comments should describe things are not obvious from the code

  • Define errors out of existence （定义错误不存在——定义语义以消除错误）

  • Pull complexity downwards

• Most constructive in the context of code reviews

• Course is more about red flags that recipes

Classes Should be Deep, cont'd

• Common wisdom: "classes and methods should be small" （一个方法中代码行数不超过一页屏幕，例如50行）
• Result: classitis
• Rempant in Java world: FileInputStream, BufferedInputStream, ObjectInputStream （过于复杂）
• Length isn't the big issue, it's abstraction （概念的抽象）

A Deep Interface

• Unix file I/O
  • open, close, read, write, lseek
• Hidden below the interface
  • On-disk representation, disk block allocation
  • Directory management, path lookup
  • Permission management
  • Disk scheduling
  • Block caching
  • Device independence

Define Errors Out of Existence

• Exceptions: a huge source of complexity
• Common wisdoms: detect and throw as many errors as possible
• Better approach: define semantics to eliminate exceptions（减少异常情况的定义）
• Example mistakes
  • Tcl unset command(throws exception if variable dosen't exist)
  • Windows: can't delete file if open
  • Java substring range exceptions

Overall goal: minimize the number of places where exceptions must be handled （减少异常处理的地方——》在常见的情况下，做正确的事情是简单的）

讨论

1. String substring VS Character index
2. Exception VS Error Code
   1. Error, Exception, RuntimeException
   2. 程序崩溃也是可选项

Tactical vs Strategic Programming

• Tactical programming
  • Goal: get next feature/bug fix working ASAP
  • A few shortcuts and kludges are OK?
  • Result: bad design, high complexity
  • Exctreme: tactical tornadeos（战术龙卷风）
• Complexity is incremental（复杂度是增量的）

Working code isn't enough

Tactical vs Strategic Programming, cont'd

• Strategic programming
  • Goal: produce a great design
  • Simplify future development
  • Minimize complexity
  • Must sweat the small stuff
• Investment mindset（投资心态，但难以衡量投入成本、获取净收益的时间点、最终收益）
  • Take extra time today
  • Pays back in the long run

How Much To Invest?

• Most startups are totally tactical
  • Pressure to get first products out quickly（上线压力）
    • "We can clean this up later"
  • Code base quickly turns to spaghetti（面条式代码）
  • Extremely difficult/expensive to repair damage
• Facebook: "Move quickly and break things"
  • Empowered developers
  • Code base notoriously incomprehensible/unstable
  • Eventually changed to "Move quickly with solid infrastructure"
• Can succeed with strong design culture: Google and VMware
  • Attracted best engineers（吸引最好的工程师，公司文化）

How Much To Invest, cont'd

• Make continual small investments: 10-20% overhead
• When writing new code
  • Careful design（精心设计）
  • Good documentation（好的文档）
• When changing existing code
  • Always find something to improve（逐步的迭代优化）
  • Don't settle for fewest modified lines of code（不仅仅是修改最少的代码）
  • Goal: after change, system is the way it would have been if designed that way from the start

Is the Course Working?

• Hard to know: ask students in 5-10 years?
• Just the first step towards becoming a great programmer
• Good energy in class
  • Tone of discussions changes halfway through
  • Students are thinking about their code in new ways
• Interesting challenges for me
  • What causes complexity?
  • How to design simple code?
• Discovering new ideas from reading student's code
  • Specialized——》complicated
  • General-purpose——》simple, deep

问题

1. 是否设计评审？
2. 设计评审中讨论设计问题，而不是编码风格和错误？
3. 其他重要的事项
   1. 单元测试
   2. 基于其他人代码，构建新功能
   3. 线程的使用是不可避免的，但它不是好的设计
   4. 对于初创公司，招聘匹配基于学习能力，而不是现有能力（斜率，而不是y轴）
   5. 海仑定律：用户依赖于接口中泄漏的实现细节（隐式依赖内部实现）——》在修改接口实现时，引发系统故障。

海仑定律（Hyrum's Law）是软件工程中一种观察经验：

有了足够数量的 API 用户，您在合同中承诺什么并不重要：
您系统的所有可观察行为都将取决于某人。

引用

1. A Philosophy of Software Design | John Ousterhout | Talks at Google