说起来这“藤缠树”，我最近还真就碰上这么个事儿。不是说真去看山里的藤和树，是在我捣鼓的一个小项目里头，遇到了类似的情况，给我折腾得够呛。
起初的打算
我就是想弄个简单的东西，分了两个主要的模块，想着一个负责数据处理，一个负责展示，清清楚楚的，谁也别碍着谁。就像两棵树，各自长好就行。
咋就缠上了？
结果，做着做着就走样了。 为了图个方便，或者说，是图个快，数据那边有部分逻辑，我觉得展示这边用起来顺手，就直接调了。展示这边，有些临时的状态，想着存起来方便，干脆也塞到数据处理那边去了。
音乐520网站提供热门歌手/热门乐队/经典歌曲合集大全打包下载，点我立即前往》》》经典歌曲合集下载专区
就这么你来我往的，一来二去，嚯！这两个模块缠上了。一开始没觉得有还觉得挺“高效”的，这边改点东西，那边立马就能用上。
- 临时加个小功能，东挪西凑一下，很快就上线了。
- 这边缺个啥状态，直接去那边拿，都不用自己维护。
当时我还挺得意，觉得你看我这多“灵活”。
麻烦来了
好景不长，问题很快就来了。 就像那藤蔓，一开始看着还挺美，缠紧了才发现，谁也动弹不得。
有一次，数据处理那边需要大改，动了一个底层的结构。我寻思着，这跟我展示这边没关系？改呗！结果一改，完蛋，展示这边直接就崩了！ 一查才发现，之前图方便，展示这边依赖了那个结构里的好几个犄角旮旯的东西。
这下麻烦了。数据那边的人也抱怨，说我们这边改点东西，你们那边就叫唤，这还怎么干活？我们这边也委屈，你那边改了，也不打声招呼，我怎么知道你动了哪里？
想把它们彻底分开？那工程量，啧啧，比重写一遍差不了多少。 里面互相调用的地方太多了，盘根错节的，根本就理不清。真就是藤缠树，树也离不开藤（因为藤提供了一些“便利”），藤也离不开树（没了树它就趴地上了）。
咋办的？
也没啥太好的办法。只能是头痛医头，脚痛医脚。
我们开了好几次会，把最要命的几个缠绕点给梳理了一下，做了点“隔离”，加了好几层接口啥的，尽量让它们表面上看起来没那么依赖。但实际上，我知道，那藤还缠在树上，只是从明面上挪到了底下。
以后再改东西，还是得小心翼翼，两边都得沟通生怕一不小心又扯着对方了。
这事儿给我的教训就是，一开始图省事、图快，后面就得加倍还债。 清清爽爽的结构，哪怕开始慢一点，后面维护起来才真的省心。别老想着搞什么“藤缠树”，看着好像挺紧密，实际上脆弱得很，一动就可能两败俱伤。还是各自独立生长，保持点距离比较
