八年前写的读后感，现在看看，写得没什么毛病。
Kent Beck在他的《实现模式》里面，提到了编程的价值观问题。沟通，简单，灵活，这就是Kent Beck认为的编程时影响他每一个决策的核心的价值观。我完全认同他的观点。在我的编程实践里，我也时刻朝着这个方向努力。
这种价值观都建立在这样一个基础之上，就是说代码是经常需要人去维护的。事实上维护代码的成本远远高于构建它们的成本。当然，如果一个软件写出来之后就基本上不需要再维护，那么我们或许应该采用一种完全不同的价值观。但至少大部分的软件，尤其是应用层上的软件，可能都不会超出这个范畴，毕竟需求总是时刻在变化着的。
如果我们都认为，代码的可维护性非常重要，那么沟通、简单、灵活的价值观就是不言而喻的。
首先，代码必须能够展现出作者的意图来。好的代码读起来就像作者在跟你侃侃而谈，你可以很容易的就清晰理解他的思路。而晦涩难懂的代码，可能你读了半天还完全不知道作者到底想干什么。这会大大增加代码维护的成本。首先你读懂代码需要花费很大的力气——甚至很有可能你以为自己读懂了，其实里面某些trick你并没看明白，结果完全搞反了作者的意思。而越难看懂的代码往往就越难修改，这样又增加了维护的难度。
其次，代码要简单。往往代码中会存在着许多不必要的复杂性。去掉了这些复杂性，可以让代码更容易理解，同时可以避免很多由于这种复杂性可能会导致一些不容易发现的错误。怎么样保证代码的简单？首先要保证程序的确是为了完成需要完成的工作。经常可以看到有些代码里面有一些无用的东西，可能当时写下这段代码时的动机已经发生了变化，但是却没有把已经变成多余的东西删掉。这些东西多了只会让读代码的人感到疲惫，无可奈何。另外需要去除重复。相同的逻辑要是重复超过三遍，这就肯定有问题了，尽量把重复最小化，抽象出本质的东西来。
代码的灵活性体现在修改代码所付出的工作量上。如果需求没有变化，代码不需要修改，那么灵活性就是完全没有必要的。但是，可以肯定的是，需求一定会变化。但是我们怎么知道需求究竟会如何变化？要考虑所有可能的变化？这样只会适得其反。毕竟追求灵活会带来一定的复杂性，这样会破坏程序的简单，而过于追求灵活可能反而导致程序变得过于复杂，反而不容易修改了。所以必须有一个完整的测试集。在需求真正发生变化的时候，我们可以修改代码，给简单的代码增加一些灵活性，让它对功能的扩展开放。而不是凭空想象出程序需要什么灵活性，反而把简单的事情搞复杂。
我认为开发人员在编码的时候，应该时刻考虑沟通简单灵活这三条原则。
