为什么叫好胜心的转变，我是一个好胜心很强的人。为了让我的好胜心得到满足，我也在努力丰富自己，让自己说的理论是对，在争辩的过程中能满足自己的好胜心，当然有时候结果并不能和我预想的一样，有时候我发现我错了的时候我是比较难接受的。所以有时候会让与别人的争辩变成狡辩。今天的一次争辩差点又让自己变成了狡辩，初期也不例外，各持己见各自陈述，中期我的观点暂时得到了大家的认同，然后吃饭中场休息，回来之后发现我的解决方法并不能解决问题，然后推翻，我开始接受，然后大家一起把争辩变成为当前的问题找出最优的解决方案。
自己为啥还要为此写篇博文，是因为我觉得这个的收获不仅仅在于结果，更多的在于自己的态度，不觉得谁的方案一定好，谁的方法一定优，只有谁的方案最适合当前的项目。
问题的起因
问题的起因大概是所有功能模块内的子模块采取扁平的结构好，还是有一个明确的父子关系比较好。
仔细分析可以得知，两种架构都会有适应自己的场景。因为之前bnbhybrid是使用父子关系明确的架构方式来写的，发现维护和修改起来都非常容易，所以在review代码时一看到扁平的结构就觉得是不是不应该这样搞。这样完全是乱搞。然后就是我对这个项目的业务不是很清楚，然后就觉得应该纠正这个问题，并没有完全结合当前的项目场景来分析。
争论过程
各自有各自的优缺点。
扁平结构：
优点：文件结构清晰，易维护。模块间交互容易，层级不深，网状结构。
缺点：无从属关系，公共模块划分模糊。
明确父子关系：
有点：从属关系明确。问题定位容易，线性结构。文件结构清晰，易维护。
确定：层级较深，模块间交互不易。公共模块划分模糊。
结论
采用扁平的结构，用命名空间的方式来区分父模块与子模块的标识，斩断从属关系，大家只存在相互调用，不存在从属。公共模块提出来，这里的公共模块只的是纯组件级别的，必须是脱离业务的。最终也遗留了一个问题，如果业务复杂过分了之后，很有可能成为网状的结构，网状的结构有一种牵一发动全身的感觉，应为你也知道哪些地方对此有引用，然后在修改的时候要非常注意，对开发者的开发能力有一定的要求。
收获
首先肯定是对架构的理解变深了一点，对于当前项目的分析也有一些见解，没有什么东西是绝对的，只有在利弊之间分析得到相应的一个最优解。过程中的体会还是只有参与到其中的人更有体会，当自己能力不足的时候就是多听，当然自己有能力的时候就多思考，再有能力的时候一定要发表自己的意见，不怕错，只怕自己执念的那些对的观点是错的，当然最好的还是自己对于态度的改观，并非是按照自己的性格去思考了，更多是可以从解决问题的方式去思考。
不好的东西
争论中也发现了一些不是很好的东西，比如在争论初期，有一堆人围在一起，这是挺好的，还是我说的，多听也是挺好的。发出一些微弱到几乎听不到的声音是毫无意义的，要说就大声说，本来就是一个讨论的问题，这样的发生首先是没有自信的，然后就是毫无意义的。随着争论的进行，人就开始散了，可能他们觉得这个争论是没啥意义的，当然也确实如此，对于每个人来说收获不一定一样。但是问题的背后却是这些人等待我们争论出来一个结果然后执行，把自己定位成什么样的人，自己就会成为什么样的人，这个可能也是因人而异，呵呵，有什么关系呢。毕竟我也不是所有人。