虽说没什么新鲜玩意，但还是能有一些启发。倒不是说讲师多NB。

很多东西自己以前都看过，学过。但有个人能领着你过一遍，感觉还是不同。

比如这两年开始很流行一个词：暗喻。也有人叫它隐喻。其实就是类比。你对一个概念不懂，找一个

和它类似的概念，以这个你熟悉的概念为切入点进行更深入的思考。早在几十年前，伯利亚的《如何解题》里开篇讲的就是这个道理。

     还有一个例子举得和我现在的工作比较接近：来了一个需求，需求人员出了需求文档之后，开发马上就按照文档进行编码。不是说没有一点设计，只是很多设计只存在于开发人员的脑袋中，说白了，就是经验在驱动开发。而不是设计在驱动开发。经验是个好东西，但它有些致命的缺陷--缺乏前瞻性和整体性。如果需求哪天作了改动，下一个接手维护的开发人员头可能就会大了---因为前一个开发人员编码的时候，根本就没考虑所谓的扩展性。好吧，我承认，其实从一开始就不存在设计。

      写到这，又想起来最近总有一种感觉：觉得项目组内部有什么问题存在。但总是说不上来具体是什么。

     今天参加完这个培训之后，脑子里就在想：我们是做施工项目管理软件的。其最终的目的是给施工单位规范他们的流程。提高效率。但感觉我们自己内部其实对于标准流程是什么样子，自己也不清楚。

     我们做了很多家客户化了，收集的素材不可谓不多，但我们仅仅是收集了很多原始资料。我们从来都没有对这些资料进行过分析和抽象。我们开发作的工作一直都是在进行从需求文档到代码的简单映射关系。真没技术含量。

     对这些资料进行分析，不是需求人员的事情，这应该是开发的事情。如果以后不走这一步，哪怕现在的重构版客户化验证做的再好，这个所谓的业务平台也起不来。感觉一个好的平台或者说业务架构，除了能方便的提供处理变化的能力之外，还应该能对平台的使用者（开发人员）起到一个引导和合理约束的作用，简而言之，就是说我做一个模块，我不用过多的去考虑：我要注意别忘了哪些步骤等等诸如此类的东西。它会让你清晰的知道：正确的业务流程就是这个样子。

     我现在觉得，项目组花了这么大力气作重构，感觉却像在沙滩上盖房子，说不定哪天就塌了。或许它不会塌，但是如果把一个产品最后做成了项目，也是谁都不愿意看见的。