《简约之美》章节试读

《简约之美》的笔记-第1页 - 简约之美

简约之美

《简约之美》的笔记-第29页 - desirability

合意程度（可取程度） desirability 我是没猜出来这个单词。翻译的好别扭。音译：“得劲儿程度”。讲的是软件的期待的样子。那个梦想中的软件完成时的样子。

《简约之美》的笔记-第63页

The ease of maintenance of any piece of software is proportional to the sim-
plicity of its individual pieces.正比，译反了。好像。

《简约之美》的笔记-第30页

有时候是很难的。很难得

《简约之美》的笔记-第81页 - Testing

我们不能保证我们写出来的软件没有一点bug，也不能保证它在未来随着环境等一系列条件的变化还能一直正确运行，因此，我们需要测试。The degree to which you know how your software behaves is the degree to
which you have accurately tested it.我们应该尽可能测试详细、周到，这样我们自己心里就对我们的软件的可靠性更有把握。
另外，软件开发人员都知道，任何一点细小的改动都可能引入另外一些bug，因此我们每一次改动都应该仔细斟酌；最好的方法就是每改动一处就将所有的测试用例跑一遍，以确定我们软件的正确性。
这又引入了另外一个问题，如果每次都手动测试的话，这是很大的工作量，一般开发人员也没有这么多的时间；因此，我们需要自动化测试。
我觉得应该给每一个开发人员都配一个测试人员，该测试人员应该对软件的需求了解得很透彻，能够编写自动化测试脚本，与开发人员之间最好有良好的默契。

《简约之美》的笔记-第1页 - 前言

好程序员和差程序员的区别在于理解能力。差劲的程序员不理解自己做的事情，优秀的程序员则相反。信不信由你，道理就是这么简单。---该书前言第一句话。

《简约之美》的笔记-第70页

anotherNameLikeThat 这怎么还能抄错。

《简约之美》的笔记-第1页 - null

简约之美：软件设计之道【美】Max Kanat-Alexander

常识

2014-09-21 18:44:29
用简单的技术构建清晰的架构

2014-09-21 19:17:43
“降低维护成本”

2.3　为什么不存在软件设计科学

2014-09-22 21:56:16
这些数学家才是计算机科学之父，计算机科学正是对信息处理所做的数学研究。它并不像现在一些人认为的那样，是关于计算机编程的学问。

2014-09-22 21:58:27
其实，缺席的科学分为两种：软件管理的科学，软件设计的科学。

第3章　软件设计的推动力

2014-09-23 08:56:07
总之，在设计软件时，应当将目标——帮助他人——视为应该考虑的最重要因素，这样，我们才能认识并了解软件设计的真正科学。

2014-09-23 09:00:13
确保软件能提供尽可能多的帮助。

2014-09-23 09:00:17
确保软件能持续提供尽可能多的帮助。

2014-09-23 09:00:22
设计程序员能尽可能简单地开发和维护的软件系统，这样的系统才能为用户提供尽可能多的帮助，而且能持续提供尽可能多的帮助。

2014-09-23 09:03:07
有时候，学习新技术，做一份好的设计，都要花很长时间，但是长期来看，你做出的选择必须确保开发和维护软件都比较简单。

4.1.5　化简方程式

2014-09-23 09:12:41
随着时间的流逝，它会越来越不重要，甚至完全无足轻重。于是，随着时间流逝，这个方程式变成了

2014-09-23 09:12:33
其实，几乎所有软件设计的决策都完全忽略了未来价值与维护成本的对比。

4.1.6　你需要什么，不需要什么

2014-09-23 09:18:49
相比降低实现成本，降低维护成本更加重要。

5.1　真实世界中程序的变化

2014-09-23 09:28:21
另一点值得学习的有趣之处是，回顾某个特定文件修改历史。如果某个文件存在了很长时间，而且你有程序记录每个文件的修改历史，请回顾整个过程中的每次修改。问问自己，最初写这个文件时，你能预测到这些变化吗，是否一开始写好就能够减轻后期的工作量。总的来说，就是要尝试理解每次修改，看看是否能从中得到一些关于软件开发的新的收获。

5.2.1　编写不必要的代码

2014-09-23 09:28:54
如今，软件设计中有一条常见的规则，叫做“你不会需要它”（You Ain't Gonna Need It），或者简称为YAGNI。

5.3　渐进式开发及设计

2014-09-24 01:06:19
相比开始就建立完整的系统，一次性构建出来，这种开发方法需要时间更少，也不用考虑过多。如果你习惯其他的开发方法，头一次实践可能并不那么容易，但是经过锻炼，用起来就会变容易。

2014-09-24 01:06:10
总的来说，在其中的每个阶段，下一步都只做最容易的事情。

2014-09-24 00:26:44
有些时候，你甚至需要把某个单独的功能拆分为一系列小的、简单的逻辑步骤，然后才可以很方便地实现。

第6章　缺陷与设计

2014-09-24 21:48:51
在程序中新增缺陷的可能性与代码修改量成正比。

2014-09-24 21:49:52
最好的设计，就是能适应外界尽可能多的变化，而软件自身的变化要尽可能少。

6.1　如果这不是问题……

2014-09-24 21:50:49
没错，如果不添加代码，也不修改代码，就不会引入新的缺陷，这是软件设计中的一条主要规律。

2014-09-24 21:51:11
永远不要“修正”任何东西，除非它真的有问题，而且有证据表明问题确实存在。

2014-09-24 21:53:27
在这类问题上，最有名的错误就是所谓的“提前优化”。也就是说，有些开发人员想让速度尽可能快，所以，他们还没弄清楚速度到底慢不慢，就花时间来优化程序。

2014-09-24 21:53:32
在你的程序中，真正需要关注速度的部分，应该局限于你可以证明的、真正让用户体会到有性能问题的那些部分。对程序的其他部分，最主要关心的还是灵活和简洁，而不是速度。

2014-09-24 21:53:37
要违背这条规律有成千上万种办法，不过遵守它的办法很简单：在动手解决之前，真正拿到证据，证明问题确实存在。

6.2　避免重复

2014-09-24 21:53:46
理想情况下，任何系统里的任何信息，都应当只存在一次。

2014-09-24 21:54:52
遵守这条规则的一个强有力的理由，就是缺陷概率定律。如果新增功能时可以重用代码，就不需要写太多代码，引入错误的可能性也就随之减少了。

第7章　简洁

2014-09-24 21:56:02
软件任何一部分的维护难度，反比于该部分的简洁程度。
换句话说，某一部分的代码越简洁，未来进行变化的难度就越低。

2014-09-24 21:59:02
不过，由大模块构成的系统，质量要差得多，而且，将来你得花很多时间去修正错误，结果就是维护的难度越来越高。相反，简单系统的维护难度会越来越低。长期来看，能保证效率的恰恰是简单的系统，而不是复杂的系统。

2014-09-24 21:59:32
落实这条法则的一个好办法，就是第5章讲解的渐进式开发和设计方法。因为每次添加功能之前都有个“重新设计”的过程，所以系统能持续简化。即便不用这种方法，你也可以在增添新功能之前，花点时间去化简任何让你或你的同事觉得不够简洁的代码。

7.1　简洁与软件设计方程式

2014-09-24 22:00:47
我们不必预测未来，完全可以只审视自己的代码，如果它足够复杂，就立刻动手简化它。这就是随时间推移降低维护成本的办法——持续不断地让代码变得更简洁。

7.4　保持一致

2014-09-24 22:07:23
要做到简单，保持一致是很重要的工作。如果你在一个地方采用了某种规则，就应当在其他每个地方都遵守这种规则。

2014-09-24 22:08:19
真实世界里或许不存在这样的一致性，但是程序的世界由你负责，所以必须保持程序的简单和一致。

2014-09-24 22:08:41
编程也是这样——缺乏一致性，只会一团糟。有了一致性，世界就很简单。即便你做不到那么简单，至少也要做到：一旦你理解了某种复杂性，就不必再进行重复劳动。

7.5　可读性

2014-09-24 22:09:07
软件开发领域反复强调一点：代码被阅读的次数远多于编写和修改的次数。

2014-09-24 22:10:53
代码可读性主要取决于字母和符号之间的空白排布。

2014-09-24 22:12:22
一般来说，如果某段代码有很多bug，又难以阅读，那么首先要做的是让它更容易阅读。然后，bug在哪里才能看得更清楚。

7.5.1　命名

2014-09-24 22:12:50
名字应当足够长，能够完整表达其意义或描述其功能，但不能太长，以免影响阅读。

7.5.2　注释

2014-09-24 22:15:30
但事实并非如此，你的代码可能很容易阅读，但系统仍然非常复杂。

7.6　简洁离不开设计

2014-09-24 22:17:10
反过来，如果你的设计非常好，一般却难得听到多少称赞。设计中的缺陷是大家都看得到的，但逐步演变为良好设计的改进过程，却是不熟悉代码的人看不到的。于是，设计师就成了一个费力不讨好的工作。解决重大缺陷为你赢得很多赞誉，但是避免缺陷发生……嗯，没有人会注意到。

第8章　复杂性

2014-09-24 22:19:37
原有功能越多，新增功能的成本就越高。优秀的设计可以尽量避免此类问题，但是每项新功能仍然会有单独的成本。

2014-09-24 22:19:45
有些项目从一启动就设定了繁多的需求，所以永远无法发布第一版。如果遇到这种情况，就应当删减功能。初次发布不应当设定过高的目标，而应当先让程序跑起来，再持续改进。

2014-09-24 22:24:39
相比众多平庸的开发人员，少量精干的开发人员更容易获得成功。

2014-09-24 23:45:45
一般来说，“困于糟糕的技术”指的是你之前决定了采用某种技术，因为极度依赖它，长期无法摆脱。这里说的“糟糕”，意思是你深陷其中（未来无法简单地切换到其他技术），不能灵活地适应未来的需求，或是达不到设计简洁软件所需的质量标准。

2014-09-24 23:46:04
程序员不理解自己的工作，就容易设计出复杂的系统。这可能是恶性循环：理解错误导致复杂性，复杂性又进一步加剧理解错误，如此往复。提升设计水平的最主要办法是，确保自己完全理解所用的系统和工具。

2014-09-24 23:46:26
你对它们的理解越到位，对软件开发的一般规律了解越多，你的设计就越简洁。

8.1　复杂性与软件的用途

2014-09-24 23:54:16
你正开发的任何系统，其基本用途应当相当简单。这样开发出来的系统，既满足实际需求，整体来说也是简单的。

2014-09-24 23:54:29
同样重要的是要思考用户的需求。

8.2　糟糕的技术

2014-09-25 00:10:13
好在，开始使用之前，你可以通过三个因素来判断技术是否“糟糕”：生存潜力、互通性、对品质的重视。

8.3　复杂性及错误的解决方案

2014-09-25 00:15:22
一旦程序里出现了“无法解决的复杂性”，就说明设计中有些深层次的基本错误。如果问题在这个层面上无法解决，应当回过头去看看产生问题的真正原因是什么。

2014-09-25 00:15:12
其实，程序员经常这么做。你可能会说：这代码太垃圾了，要添加新功能真够麻烦的。那么，深层次的基本问题就是代码太混乱。所以，你应该整理这些代码，让它们变简洁，你就会发现增加新功能也会变简单。

2014-09-25 00:16:00
所以你真正要做的就是，找出自己所处的环境中最好的办法。

2014-09-25 00:16:26
确认你真正理解了问题的方方面面，找到最简单的解决办法。

2014-09-25 00:16:32
不要问“用现有代码怎么解决这个问题”，或者“Anne教授在程序里是怎么解决这个问题的”，而是问问你自己：“通常情况下，在最完美的方案里，这类问题要如何解决？”

8.4 复杂问题

2014-09-25 00:17:06
如果你在解决复杂问题时遇到了麻烦，那么用简单易懂的文字把它写在纸上，或者画出来。

2014-09-25 00:17:26
有些最优秀的程序设计就是在纸上完成的，真的。把它输入到计算机里只是次要的细节。

2014-09-25 00:17:20
大多数麻烦的设计问题，都可以用在纸上画图或写出来的办法找到答案。

8.5　应对复杂性

2014-09-25 00:18:58
身为程序员，你必然要面对复杂性。其他程序员会写复杂的程序，你必须去修正。硬件设计师和语言设计师会让你的生活更麻烦。

2014-09-25 00:20:14
如果系统中某个部分太过复杂，有个好办法来解决：把它分解成几个独立的小部分，逐步重新设计。

2014-09-25 00:20:29
更常见的做法是在每个步骤中都把一个复杂的部分拆分成若干个简单的部分。

2014-09-25 00:21:30
如果所有的代码都包含在一个巨大的文件里，改进的第一步就是把某个部分保存到单独的文件里。之后改进这个小部分的设计，然后把另一个部分保存到新的文件，再改进这个部分的设计。如此重复下去，最终得到的就是可靠的、可理解的、可维护的系统。

2014-09-25 00:21:55
如果系统非常复杂，这么做的工作量可能相当大，所以必须有耐心。你必须首先做好设计，改进之后的系统要比现在的简单——即便只是简单一点点。然后，朝着这个目标一步步地前进。得到了这个简单的系统之后，就设计下一个更简单的系统，再朝那个目标前进。不必设计“完美”的系统，因为它不存在。你只需要持续不懈地追求比现有系统更好的系统，最终就会得到相当容易管理的简洁系统。

2014-09-25 00:23:38
你甚至可以这样来处理bug：如果发现修改设计之后，某些bug更容易修复，那么先重新设计代码再修复bug。

8.5.1　把某个部分变简单

2014-09-25 00:28:36
不要仅仅因为权威的肯定就机械地生搬硬套某个工具，我们的选择永远是，在当前的环境下，当前的代码中，做合适的事情。

2014-09-25 00:29:08
要怎么做，才可以让事情处理或是理解起来更容易？

8.5.2　不可解决的复杂性

2014-09-25 00:30:16
简化系统时，你可能会发现某些复杂性是无可避免的，可能所使用的硬件就是很复杂的。如果遇到这类不可解决的复杂性，你要做的就是屏蔽这种复杂性。在程序外面妥善包装上一层，让其他程序员更容易使用和理解。

8.6　推倒重来

2014-09-25 00:31:34
你有足够的资源，可兼顾维护原有系统和重新设计系统。绝对不要为了让程序员重写新系统而停止对原有系统的维护。系统只要在使用，都离不开维护。请记住，你自己的精力也是一种资源，必须慎重分配——如果两线作战，你每天有足够的时间分配给原有系统和新系统吗？

第9章　测试

2014-09-25 00:33:41
你对软件行为的了解程度，等于你真正测试它的程度。

2014-09-25 00:33:45
软件最后一次测试的时间距离现在越近，它可以继续正常运行的可能性就越大。

2014-09-25 00:33:53
除非亲自测试过，否则你不知道软件是否能正常运行。
多看笔记 来自多看阅读 for Kindle

《简约之美》的笔记-第37页

满身问题 千疮百孔