获得徽章 0
- “有时候你受命去解决一些本身就非常复杂的问题，比如编写拼写检查或国际象棋的程序。问题复杂，解法不一定会复杂；相反，在处理此类问题时，你必须更努力地追求代码的简洁。如果你在解决复杂问题时遇到了麻烦，那么用简单易懂的文字把它写在纸上，或者画出来。有些最优秀的程序设计就是在纸上完成的，真的。把它输入到计算机里只是次要的细节。大多数麻烦的设计问题，都可以用在纸上画图或写出来的办法找到答案。
如果系统中某个部分太过复杂，有个好办法来解决：把它分解成几个独立的小部分，逐步重新设计。每次修改都应该足够小，这样可以放心动手，不会让事情更复杂。
“你对软件行为的了解程度，等于你真正测试它的程度。
你必须观察测试的结果，确保它们是有效的。如果测试失败了，必须有办法让你知道这个情况，以及失败的具体原因。
你还必须保证测试是准确的。如果测试显示程序的行为完全符合预期，事实却并非如此，或者测试显示程序崩溃了，其实它跑得好好的，那么这些测试都是不准确的。
如今的程序员在落实测试法则时，会编写许多自动化测试来测试所写的每一段代码。这样做的好处在于，有任何改动都只需要重新运行这些测试即可，程序会测试系统中的方方面面，确保修改之后所有部分仍然保持正常。
-- 来自《简约之美：软件设计之道》”
上面的文字合并了本书第八章的后半部分以及第九章的内容。
介绍了作者推荐的解决复杂问题的方法以及关于测试的相关知识。很惭愧现在还不太会写测试代码，但是作者所说的“对软件行为的了解程度，等于你真正测试它的程度”提醒了我在后面开发的时候，最好可以多思考软件执行的几种路径，并且可以编写配套的测试代码来验证程序。展开等人赞过
29 - “软件的复杂性是会叠加的，而且不是简单的线性叠加。也就是说，下述假设是不成立的：之前有10项功能要开发，因此再加1项只会增添10%的工作量。因为新增的功能需要与已有的10项功能相协调，所以如果开发新功能需要10小时，可能还要花10小时才能保证已有的10项功能与新功能正常交互。原有功能越多，新增功能的成本就越高。优秀的设计可以尽量避免此类问题，但是每项新功能仍然会有单独的成本。
你正开发的任何系统，其基本用途应当相当简单。这样开发出来的系统，既满足实际需求，整体来说也是简单的。但是，如果你给系统添加新功能去满足其他目标，事情就立刻变复杂了。
举例来说，文字处理软件的基本功能就是帮助用户写作文档。如果突然要求它能够阅读邮件，最终就会得到的非常荒唐复杂的玩意。我们都知道，这不是文字处理软件本来的用途。这么做，甚至都不是在扩展软件的用途，而是增添与目的无关的功能。
有时候，营销人员或者经理会给软件设定一些目标，但是这些目标其实并不符合程序的基本用途，比如“要好玩一些”、“设计要更有冲击感”、“要受新媒体欢迎”，“要使用最新的技术”等等。这些人可能是公司里的重要人物，但他们不是那些决定程序应当做什么的人。身为软件设计师或是技术经理，你的职责是保证软件的基本用途，防止它偏离正轨，这个责任其他人谁也担不起。
最受用户喜欢的软件是专注而简洁的，并且始终执着于基本用途。
-- 来自《简约之美：软件设计之道》”
这段作者呼吁大家要尽量让软件变得专注而纯粹，不要通过试图增加多样化的功能来给软件带来更多复杂性，导致提升后面的维护成本。而且如果是作为软件设计师或者是技术经理，也要有义务保证软件不偏离原有的目标。展开赞过 评论1 - “某一部分的代码越简洁，未来进行变化的难度就越低。
如果你的代码写得简洁、自洽，那么修正问题、维护系统就很容易。
如果你设计的是庞大繁杂的模块，那么每一部分都需要花费大量精力，也很难做到足够精致。这样的系统就很难维护，而且必须经常打补丁才可以正常运行。那么，为什么会有人编程时要采用庞大繁杂的模块，而不采用小巧简洁的模块呢？在软件第一次编写时，采用大模块表面上可以节省下相当多的时间。如果使用众多小模块，就必须花很多时间来组合。如果采用大模块则不会这样，零件很少，而且很容易对接。
要简洁到什么程度呢？
简单到傻子也能看懂！
许多程序员在这方面做得尤其差劲。他们以为别人都愿意花很多时间来学习自己写的代码，毕竟这是自己花很多时间写出来的。这些程序员很重视自己的代码，所以对其他人也应当同样重视。没错，程序员通常都是非常聪明的人。但是“噢，其他程序员会理解我写的所有代码，没必要简化或者注释”的看法仍然是不对的。这个问题与智商无关，而与背景知识有关。第一次接触你代码的程序员完全没有任何背景知识，他必须学习。学习的难度越低，找出问题的速度也就越快，使用起来也越容易。
降低代码学习难度的方法有很多：简洁的注释，简单的设计，循序渐进的引导，等等。不过，如果你的代码没有做到傻子都能看懂，其他人学起来就会遇到困难。他们会误解，会制造bug，会把事情搞得一团糟。等这一切发生的时候，他们会找谁？对，就是你。这时候你就得花时间回答他们的各种问题。
-- 来自《简约之美：软件设计之道》”
作者提倡我们要写简洁的代码来提高代码的可维护性。还提到了两个方法：用小模块构建系统，适当使用注释。尽量做到不需要让别人和未来的自己花费太多成本来读懂代码。展开赞过 评论1 - “永远不要“ 修正” 任何 东西，除非它真的是一个问题，而且有证据表明问题确实存在。
如果相当多的用户认为某个行为是bug，它就是bug；如果只是少数用户（比如一两个）认为它是bug，那么它就不算bug。
在你的程序中，真正需要关注速度的部分，应该局限于你可以证明的、真正让用户体会到有性能问题的那些部分。对程序的其他部分，最主要关心的还是灵活和简洁，而不是速度。
有些开发人员想让速度尽可能快，所以，他们还没弄清楚速度到底慢不慢，就花时间来优化程序。这就好像做慈善事业时，一边把食物送给富人，一边说“我们只是希望帮助他人。
在动手解决之前，真正拿到证据，证明问题确实存在。
-- 来自《简约之美：软件设计之道》”
作者强调了在解决问题之前应该先确认这个是不是问题。如果确认了是问题才需要去解决。
关于bug：有多数用户反馈的bug才是bug，如果极少数用户反馈的bug，就不应算作bug或者优先级可以排到后面，它不应该属于我们首先解决的问题。
关于性能优化：只有可以证明的，用户体会到性能上有问题的部分才需要去优化性能。
其实这就是“把钱用在刀刃上”在软件开发中的实践：我们的开发资源永远是紧张的，因为无论是现在还是未来都要有很多事情要做。因此我们需要解决的是那些明确的，有证据证明的，真正需要解决的问题。展开等人赞过 评论16
juejin.im