《Code Simplicity》附录B

偶然间发现《Code Simplicity》这本书,篇幅很小,加上封面、前言、目录、附录什么的才刚好90页。看书名还以为是讲简洁编码的,和《The Art of Readable Code》类似,读下来才发现并不是这么回事。这本书关注的重点是软件设计,基本囊括了软件生命周期的各个部分,并着重于“设计”二字,即如何在正确的时间做正确的事情来保证软件和软件工程的简单性。

书后有两个附录,其一是“软件设计法则”,其二是“事实、法则、规则和定义”,基本上就是全书的“精华”所在了,而后一篇附录又基本上包含了前一篇里的所有法则,正巧我也许久没有翻译东西了,便全文翻译在此:

  • 事实:糟糕的程序员和优秀的程序员之间的区别在于理解。即糟糕的程序员并不理解他们在做什么,而优秀的程序员却能够理解。
  • 规则:“优秀的程序员”应该竭尽所能去编写对于其他程序员来说足够简单的代码。
  • 定义:程序是:
    1. 给予计算机的一系列指令
    2. 计算机为响应给定的指令而采取的操作
  • 定义:在你创建软件系统时,任何参与到该系统架构或者技术决策中的事情都属于“软件设计”。
  • 事实:编写软件的每一个人都是设计师;
  • 规则:设计不是民主制度,决策应该由具体的个人来制定。
  • 事实:软件设计是有法则的,它们是永恒的、不变的、本质正确并且有效的,它们不是秘密,可以被你所知。
  • 法则:软件的目的是帮助人们
  • 事实:软件设计的目标是尽可能的:
    1. 让我们编写的软件有用
    2. 让我们的软件持续的有用
    3. 将系统设计为使程序员容易创建和维护,如此系统就可以——并且持续可以——有用
  • 法则:软件设计的等式:
    law1
    这就是软件设计的主法规。用文字表述就是:

    变化的可取性与当前价值和未来价值之和成正比,与实现成本和维护成本之和成反比。

    随着时间的推移,这个等式还可以简化为:
    law2
    它表明减少维护成本要比减少实现成本更为重要。

  • 规则:设计的质量级别应该与系统在未来持续帮助人们的时间成正比。
  • 规则:有些事情你是不知道的,它们叫做未来。
  • 事实:程序员犯的最为常见和灾难性的错误就是预测未来,而事实上他们无法得知。
  • 规则:如果你压根不去预测未来,而是基于已知的当前信息来制定设计决策,那么你就是最安全的。
  • 法则:变化法则:你的程序存在的时间越长,它的某些部分就越是有可能必须改变。
  • 事实:软件设计者在应对变化法则时容易犯的三个错误(或称为“三个缺陷”)是:
    1. 编写不需要的代码
    2. 没有让代码容易更改
    3. 过于通用
  • 规则:除非真正需要,否则别去编写代码,并把所有没有用到的代码删掉。
  • 规则:代码应该基于你的现下所知来编写,而不是基于你所认为会在将来发生的情况。
  • 事实:当你的设计实际上把事情复杂化,而不是简单化的时候,你就过度工程化了。
  • 规则:只有当你确知你的需要是正确无误的,再去思考如何使代码通用。
  • 规则:你可以通过渐进的开发和设计来避免前面提到的三个缺陷。
  • 法则:缺陷概率法则:在你的程序中引入缺陷的机会与你对它所做的变化的大小成正比。
  • 规则:好的设计会用最少的软件变化来适应最大的环境变化。
  • 规则:在某件事成为问题并且你有证据显示这个问题确实存在之前,别去“修复”它。
  • 规则:在任何特定的系统中,任何信息都应该——理想状况下——只在一个地方出现。
  • 法则:简单法则:软件的任何部分在维护时的难易程度与这些部分的简单程度成正比。
  • 事实:简单是相对的。
  • 规则:如果你真的想要成功,最好蠢一点。
  • 规则:要始终如一。
  • 规则:代码的可读性主要依赖于字符和符号如何占用空间。
  • 规则:名称应该在能充分传达信息的基础上尽量短一些,如果太长,就会难以阅读。
  • 规则:注释应该去解释代码为什么这样做,而不是去解释它在做什么
  • 规则:简单是需要设计的。
  • 规则:你可以这样引入复杂性:
    • 扩展软件的目的
    • 在团队中加入新的程序员
    • 更改不需要变化的事情
    • 被糟糕的技术所束缚
    • 错误的理解
    • 糟糕的设计,或者没有设计
    • 重复发明轮子
    • 违背软件的目的
  • 规则:你可以通过检阅某个技术的生存潜力、互操作性和对质量的关注来确定它是不是“糟糕的”。
  • 规则:通常,如果某件事变得非常复杂,就意味着在其设计中,复杂性出现的层面下面有不对劲的地方。
  • 规则:面对复杂性,应该去问:“你想解决的是什么问题?”
  • 规则:在纸上简单的写写画画可以解决大多数困难的设计问题。
  • 规则:想要在你的系统中处理复杂性,应该分小阶段重新设计各个独立的部分。
  • 事实:所有有效的简化背后的关键问题都是:“如何使其更容易处理或理解?”
  • 规则:如果你在处理程序之外的某个无法修复的复杂性,那就把它包装一下,让它对其他程序员来说变得简单一些。
  • 规则:只有在某些限定情况下才能接受重写这种做法。
  • 法则:测试法则:你对软件的行为的熟知程度也就是你对它进行精准测试的程度。
  • 规则:除非你已经试过了,否则你不知道它能不能运行。

这本书里讲述的大多是一些指导原则,没有落到实处,可能会有人觉得空泛,不过我倒觉得,正确的指导原则对制定具体决策有莫大的帮助。这个世界上没有万用的方法,却有千差万别的各种具体问题,而我们需要的就是一些正确的指导原则,选择正确的方法,也就是选择不违背这些原则的方法。

2 Comments

发表评论

电子邮件地址不会被公开。 必填项已用*标注