编程中的原则

[BruceChen7]

参考资料

• Repeat yourself, do more than one thing, and rewrite everything (2018) | Hacker News
• Unit-Testing-Principles

简单的几个原则

• 模块原则

  • 使用简洁的接口拼合简单的部件

• 清晰原则

  • 清晰胜于技巧。

• 组合原则

  • 设计时考虑拼接组合，在输入输出方面，Unix 极力提倡采用简单、文本化、面向流、设备无关的格式。
  • 因此一般在 Unix 下多数程序都尽可能采用简单过滤器的形式，将一个输入的简单文本流处理为一个简单的文本流输出。

• 简洁原则

  • 策略同机制分离，接口同引擎分离。

• 吝啬原则

  • 除非确无他法，不要编写庞大的程序。

• 透明性原则

  • 设计要可见，以便审查和调试。
  • 要一眼就能看出软件是在做什么以及怎样做的。
  • 显见性指程序带有监视和显示内部状态的功能。
  • 健壮源于透明和简洁
    • 健壮源于透明和简洁。

• 表示原则

  • 复杂的数据，尽量用数组初始化表示，不要把复杂的选择逻辑丢进程序里。

• 通俗原则

  • 接口设计避免标新立异。越通俗，越流行，越好。

• 优化原则

  • 优化之前先确保能用。先求运行，再求正确，最后求快。

• 封装

  • the first and most important quality of modular code is encapsulation.
  • Encapsulated modules don't expose their internals to each other.
  • They don't call into the middle of each others' implementations, and they don't promiscuously share global data. They communicate using application programming interfaces (APIs) — narrow, well-defined sets of procedure calls and data structures. This is what the Rule of Modularity is about

• API

  • 在设计层面上，真正定义架构的是 API（而不是它们之间的实现细节）。
  • 一个好的测试来检查 API 是否设计良好是这样的：
    • 如果你试图用纯人类语言（不允许包含源代码）来描述它，是否可以理解？
    • 在编写 API 之前，养成书写非正式描述的习惯是非常好的做法。

• Compactness

  • 紧凑性是指设计可以适应人类大脑的属性。一个好的紧凑性的实际测试是：有经验的用户是否通常需要手册？如果不需要，那么设计（或者至少覆盖正常使用的设计子集）就是紧凑的。
  • 价值紧凑性，并在可能的情况下为其设计，并不随意放弃它。

• Orthogonality

  • Orthogonality is one of the most important properties that can help make even complex designs compact.

• DRY rule

  • 系统中的每一条知识都必须具有单一、明确、权威的表达方式。

• 观点

  • 永远不要单纯相信一个抽象原则。找到具体的例子来理解原则背后的基本因素。
  • 通过修改这些例子来提高自己对原则的理解。
  • 寻找可能与原则相矛盾的例子，并了解其中的原因。
  • DRY 原则为例：
    • 如果在一个地方做出了更改，并且我必须知道其他 4 个遥远的地方才能进行相同的更改，这会引起问题吗？
    • 如果在同一文件中有两行相同的代码，紧挨着彼此？
    • 如果重复了一个 3000 行的文件？一个 4 行的函数呢？
    • 如果在一个地方进行更改并不意味着必须更改其他地方呢

• Top-down, bottom-up, and glue layers

  • Top-down tends to be good practice when three preconditions are true:
    • 你可以预先明确指定程序需要做什么
    • 在实现过程中，规范不太可能发生重大变化
    • 你在选择以低层次的方式如何完成这项工作方面拥有很大的自由

• Bottom-up programming

  • 从底向上编程在试图了解尚未完全理解的硬件、软件或现实世界现象时，也可以显得更具吸引力。
  • 底层编程让你有时间和空间去完善一个模糊的规范。

• Glue layer

  • 应用逻辑的顶层和基础领域原语的底层需要通过一层粘合剂进行阻抗匹配。
  • Unix 程序员数十年来学到的一项经验教训是，粘合剂是黏性且麻烦的东西，保持粘合剂层尽可能薄是非常重要的。
  • 粘合剂应该将事物粘合在一起，而不是用于隐藏层次中的裂缝和不平坦之处。
  • 薄粘合剂原则
    • 可以被视为规则分离的一种完善。
    • 策略（应用逻辑）应该与机制（领域原语）清晰分离，
    • 但是如果有很多既不是策略也不是机制的代码，则很有可能它们除了给整个系统添加全局复杂性外，几乎没有什么实际作用。
    • 见Unit-Testing-Principles

程序员修炼之道

• Duplication Arise
  • Impatient Duplication : 时间不够，总想偷懒：记住：shortcuts make for long delays
  • Interdeveloper Duplication : 技术领头人要划分职责，项目成员之间要多交流
  • 一些有趣的观点：
    • 将 Don't Repeat Yourself 应用于数据，而不是代码。
      • 这意味着每个知识点都应该有一个唯一的参考文献。例如，尽可能避免需要同步状态的位置
    • duplication is better than the wrong abstraction
    • 决定将其抽象化之前先将某些东西写三遍。在此之前，不知道哪些部分可以真正抽象化，并且很可能正在浪费时间。
• coding to be maintained orthogonality
  • Keep your code decoupled.
    • Write shy code—modules that don't reveal anything unnecessary to other modules and that don't rely on other modules' implementations.
  • Avoid global data.
    • Every time your code references global data, it ties itself into the other components that share that data.
  • Avoid similar functions.
    • Often you'll come across a set of functions that all look similar—maybe they share common code at the start and end,
    • but each has a different central algorithm.
• Tips
  • make it easy to reuse 模块之间便于重复利用
  • There Are No Final Decisions
  • Eliminate Effects Between Unrelated Things 无关的事情不应该耦合在一起
  • Use a Single Editor Well 用好一种编辑器：选一种编辑器，彻底了解它，并将其用于所有的编辑任务
  • Program Close to the Problem domain
  • Always Use Source Code Control：总是使用源码控制即使团队只有一个人，项目只有一周，确保每样东西都处在源码控制之下
  • Fix the Problem, Not the Blame 要修正问题，而不是发出指责 bug 是你的过错还是别人的过错，并不是真的很有关系。它仍然是你的问题
  • Crash Early 早崩溃：尽早检测问题的好处之一是你可以更早崩溃
  • If It Can’t Happen, Use Assertions to Ensure That It Won’t 如果它不可能发生，用断言确保它不会发生。无论何时你发现自己在思考『但那当然不可能发生』，增加代码检查它，最容易的方法是使用断言
  • There Are No Final Decisions
  • Use Exceptions for Exceptional Problems 将异常用于异常的情况。异常表示即时的、非局部的控制转移——这是一种级联的 (cascading) goto。那些把异常用作其正常处理的一部分的程序，将遭受到经典的诶意大利面条式代码的所有可读性和可维护性问题的折磨。这些程序破坏了封装；通过异常处理，例程和它们的调用者被更紧密地耦合在一起
  • Don’t Panic 不要恐慌。这是调试的第一准则，要总是设法找出问题的根源，而不只是问题的特定表现。
  • Estimate to Avoid Surprises：
  • Don't Assume It—Prove It : 当你遇见一个 surprise bug，你应该反思为什么不能够早点发现。
  • Write code that write code
    • passive code generators are run once to produce a result
      • creating new source files.
      • performing one-off conversions among programming language.
      • producing lookup tables and other resources that are expensive to compute at runtime.
    • Active code generators are used each time their results are required.
  • Finish What you start
    • 多个资源在分配时的顺序要一致（在多个地方内保持一致性），而在析构的时候，以相反的顺序进行
    • 谁申请，谁释放。
    • 对于负载的数据结构分配与释放原则
      • 顶级结构也负责释放任何它包含的子结构。这些结构然后递归删除它们包含的数据，依此类推。
      • 顶层结构简单地解除分配。任何结构它所指向的（未在其他地方引用）是孤立的（意思是，如果没有释放，内存泄漏）。
      • The top-level structure refuses to deallocate itself if it contains any substructures.
  • Put Abstractions in Code Details in Metadata
    • program for the general case, and put the specifics somewhere else-out the compiled code base
  • You Can't Write Perfect Software
    • 意味着你要 code defensively，甚至不能相信你自己。
  • Design with Contracts
    • 写正交的代码，意味着写 shy code，而这条准则下，意味着写 lazy code，在处理前严格的校验输入，返回的结果尽可能的保证少点。

type/system #type/code #public