有时候做一个东西，或者实现一个需求，发现没有什么好的办法，没有什么直观的方案。
但是却有一个方案，这个方案初看起来感觉会很奇怪。既然没有什么直接的好办法，那就多绕些远路，从这里取点经，从那里拿点米，拼凑出一个方案来。
这个拼凑出来的方案，也能解决问题。只是这个方案里的这里一小块那里一小块，每一块本来都不是为了解决当下的这个问题而存在的，而是为了解决其他问题的，只不过把它们拿过来拼凑在一起，正好能解决当下的问题。
依我之见，与其费尽心思去拼凑出方案来，不如不做。
因为这种拼凑来的方案，跟正统方案最大的区别在于，它完全没有灵活性。它里面的每个部件只能按照这样的组合才能工作。
哪天需求稍微改一下，或者来了一个基本类似的需求，这个拼凑方案就没法work了，还需要拼凑另一个方案，到那时，之前拼凑这个方案所需要花的全部力气，还得再从头重新来一遍。还不一定能拼凑出可以解决新需求的方案。
简短来说，拼凑的刚刚好的恰好能work的方案，无法形成平台，不能用同一套code去服务各种不同的需求。而是只能针对每个需求从头定制一个方案。
这是人才，时间和金钱的极大浪费。做完一个项目，这个项目的code没有办法套其他类似项目，因为种种限制。所以没有积累。
反过来问一下，为什么就没有一个正统的方案呢？
正统的方案肯定是有的，只是被“卡脖子”了，一个图中的一个连接很多其他节点的关键路径节点，这个关键的急所没有打通，所以只能绕道而行，每次都绕道而行。
当然了，方案只要能work就行了，其他的东西都不在kpi范围之内。