《简约之美，软件设计之道》随笔

很幸运能有机会接触到这本书。这本书不厚，但是内容充实，干货满满。可以说是一本不错的书。可以说是和目前大环境下“降本增效的”理念相吻合。

从事软件开发最容易疏漏的一点就是，我们编码是为了什么？从我自己的经历看，在日常工作中，很容易出现这么一种情况。为了完成工作，而实现需求，然后就继续下一个需求。却没有想过，这个需求为什么需要做，或者为什么要做成这样？做的话为什么要在这个系统做，而不是另外一个系统做。

我一直很崇拜像是linus这样的大神，just for fun地去完成某件事。但是自己深知到自己很难像大神一样，但是可以以软件的目的为动力，为他人尽可能地持续地提供帮助。

软件的目的

本书提出了一个很非常核心的观点。就是软件的目的到底是什么？软件的目的在于以下的两点

确保软件尽可能地提供帮助
确保软件能够持续提供尽可能地帮助
尽可能简单的开发和维护系统软件。这样的系统才可能持续的提供尽可能多的帮助。

第一点的个人理解就是管它黑猫白猫，能抓到老鼠的就是好猫。第二点是第一点的补充和扩展。从时间的维度上不能说你这次抓到了老鼠就是好猫，但是你每次都能抓到老鼠，很难不说你是一只好猫还有一个额外隐藏的点就是，你不能花太长的时间去抓到老鼠，不然抓到老鼠都饿死了。也因此需要你自己去提升抓老鼠的能力或者先抓肥的老鼠。

如何达到这个目的？

只要是有需求的，那么就会是有个能提供帮助的软件。而如何使得软件可以维护，并且耗费的人力或者无力能够最小。

其核心就是两点

需求的衡量：衡量能够给提供多大的帮助久看其潜在价值以及可能价值
成本的衡量：相比于降开发成本，降低维护成本更重要。而维护成本正比与系统的复杂度

总的来说就

通过衡量需求的价值，优先选择最有价值的需求进行处理。
降低软件复杂度从而降低维护成本，来降低总成本。

衡量需求的价值

如何去衡量需求是否值得做。主要看 总价值/成本

总价值的体现在潜在的价值和可能价值。

潜在的价值：对用户提供帮助时，能够提供多大的帮助
可能价值：有多大可能可以帮助用户

成本体现在实现成本和维护成本

实现成本：开发系统的成本
维护成本：除去实现成本外的成本

最理想的策略应该是：相比于降低实现成本，降低维护成本更重要

降低软件的复杂度

降低复杂度的核心就是怎么让事情处理起来或者理解起来更容易

面对复杂度，首先明白我们想要解决的问题到底是什么。

变化与复杂度

我们需要承认一个事实，就是变化永远都会在软件行业中存在。正因如此，我们需要去拥抱变化。

我们基于这一个事实，我们可以通过以下手段降低软件的负责度。

不编写不必要的代码。因为你很难这段"不必要的代码" 以后会不会用上，可能会，也可能不会。而添加多余的代码，无疑于提高了软件的复杂度
不进行过度设计。因为我们不知道未来的情况会是怎么样，因此很容易对未来存在着“过多“的假设，还有就是不进行设计久编写代码。这样也会提高了软件的如砸度。而理想中的情况下，就是基于当前确认的需求来进行测试，来兼顾未来需求的可能性。在编码中一个重要的体现就是开闭原则
不过分过分追求通用。因为不能预测未来，因此无论做的有多么通用，都可能不能够满足未来面对的真实需求。因此这也是不必要的

但是对于不变的东西，我们也尽量不要去让他发生改变。比如永远不要修正任何东西，除非它有问题或者证据表明问题存在

开发方式的转变

为了面对这一个事实，因此以增量式逐步实现系统的开发方法"渐进式开发"的开发方式是值得提行的。其核心就是

逐步迭代
以用户为中心
代码简洁易懂
具有良好的可扩展性
可靠性与稳定性
同时也要考虑到安全性

简单说就是小步快跑，走一步算一步。但是如果系统有更加统一的规划，那么那是更加好的事情，将渐进式开发与传统软件的模式相结合。

附录

书中浓缩出的定律

变化定律：程序存在的时间越久，它的某个部分需要变化的可能性越大
缺陷定律：新增缺陷的可能性与代码修改量成正比
简洁定律：软件任何一部分的维护难度，反比于该部分的简洁程度
测试定律：你对软件行为的了解程度，等于你真正测试它的程度