软件的一大好处是可以将重复的机械劳动自动化，
因此，软件工程师们大多数对重复都深恶痛疾。
一旦发现有重复的迹象，就会想尽办法用技术手段去规避它。
但是，实际项目中的业务逻辑总是错综复杂，
有很多看似重复的场景，但又不完全一样。
因此，到底怎样才能用更低的成本把问题解决掉，
是一件值得斟酌的事情。
成本和价值
成本和价值不同，
对于软件而言，成本的一部分是，编码过程中所投入的人力成本，
而价值则与软件的用户由于使用软件，切实得到的收益有关。
只有能帮用户解决问题的软件，才有价值。
用户并不关心软件的编码情况，
只关心软件是否解决了自己的问题。
因此，具有重复代码的软件，也能解决问题，
这是再怎么强调也不为过的事情。
降低成本
但是，重复度高的代码，其实不好维护，
每次变更都必须要同时修改好几个地方，很容易改错，
因此，软件工程师们都不喜欢重复代码。
重复代码意味着重复劳动。
但是，用户并不关心这一点，
因为消除代码重复，并不会帮用户解决更多的问题，
它只解决了工程师们自己的问题。
因此，降低成本和提高价值是两码事。
起到作用
如果软件对用户来说没有帮助，就没有人用它，
代码也是如此，
一段代码如果没有作用，就更谈不上通用了。
因此，为了让代码具有通用性，就先得让代码起到作用。
这会迫使我们站在代码的使用者角度考虑问题，
而不是考虑代码写成什么样更好。
能抓住用户的核心问题，即使代码写的不好，
也是有作用的，
这胜过了一切编写优雅但是解决不了问题的代码。
通用性
在实现用户需求的时候，一个常见的误区是简化需求，
很多软件工程师，为了用更通用的办法解决问题，
会人为的删减需求。
这样虽然能够写出简洁的代码，但是同时也会遗漏大量细节。
为了代码简洁而不顾用户的真实需求，
是一种自欺欺人的表现。
因此，面对真实的用户需求，应该直面它的客观复杂度，
代码好不好写是次要的，不应该影响待解决的问题。
用户群
现实世界中的问题具有多样性，有时候找不到统一的解决方案，
这时候就应该放弃通用性，
为每一类问题，专门定制一套方案去解决。
这样制定的一族方案，反而具备了高度通用性。
因此为了让代码更通用，我们就必须对用户深入了解，
照顾到每一个用户的特殊需求。
这样才能让我们的软件被更多的人使用。
产品形态
然而，不加分别的盲目照顾所有用户的需求，也是不合理的，
因为有的用户可能不需要我们为其他用户定制开发的功能，
我们也没有精力满足所有人的需要。
就不得不进行取舍。
在业务领域中我们应该努力提取出投入产出比更高的问题类，
使得这一类问题解决后，能让更多的人受益。
注意这与软件工程师们人为的删减需求是不同的，
软件工程师们删减需求只是为了让实现更简单，是不可取的，
而在业务领域中提取公共子问题，是为了正中要害。
结语
通用的代码，不见得会写的多么优雅，
而在于代码的作者找到了更通用的问题子类。
写出通用的代码，也不见得要先对问题找出通用解法，
没有通用解法的问题，我们也可以写出一套代码去解决它。
最后，我们还要敢于确定哪些人不是我们的用户，
集中精力做更重要的事情。