聊聊工作中遇到的——耦合

今天呢，主要聊聊系统耦合发生在身边的事。我呢，那一年刚毕业，2015年，去的是一家创业型公司，就叫这家公司为 JK 吧，只是一个缩写，毕竟还是不要用真实的公司名称来举例啦。

介绍下 JK 公司，医疗行业，融资 A 轮，技术团队，30 多人吧，业务可能还有个二三十人，这是当时到公司的状况。刚毕业，进到写字楼，看见公司的大牌子，还有那在灯光的照映下闪闪发光的公司名字，还是很向往，很憧憬的，以为那就是我的追求，是今后人生奋斗的目标。

公司有商城系统、还有个管理系统、还有 app 端的接口、管理后台的接口（各种统计查询）

部署
垂直架构，nginx + Tomcat，oracle 数据库

技术框架
Struts2、hibernate、spring、SVN、eclipse

是的，技术上就这些东西，没有别的更复杂的了啊。相比同一年，用 struts2 的公司就已经很少了，hibernate ？ 那个时候，用的更多的技术就是 spring MVC spring mybatis。当然，我并没有去用必须用哪个技术的习惯，毕竟，技术是为了解决业务而存在的。但是，不得不面对的问题是，招人！！

拿我们系统来说，商城系统，后期招来的人，每个人都在吐槽，吐槽 struts2 吐槽 hibernate，我承认，不是技术不行，是人不行，大多数人把更多精力用在了研究 spring MVC mybatis 上了，这就导致了，招人难，维护成本提高。甚至有的人一听到用的是 Struts2 ，二话不说，直接就 liao（跑）。你要非要招牛气的很的人，人力成本也要上升的啊。所以说，技术选型真的很重要，初始阶段，一定要跟随潮流，社区活跃度，相匹配的市场人才，不然，这些都是隐形的成本，在消耗公司的财富。

在公司里面，系统是传统的 MVC 结构，在业务层然后用各个包区分开的，比如，项目名：JK。传统架构的布局，JK 下面有 controller、service、po、dto、util。然后 controller 下面又有 shop 包，sys 等等，表示商城的代码和各个系统的代码写在不同处。service 也同样如此，但是再往下，那又是一个大杂烩，所有系统都写在一起的代码，一个类几千行代码那更是常事。而这样“庞大”的项目再系统启动的时候，常常要一分多钟，甚至更长的时间。那是因为系统在启动的时候，会去读库，将库里面的数据放到 map 中，系统并没有用什么分布式缓存，redis啥的，都是放在 map 中存放的。可以说是一个很简单的系统了啊。

而整个系统又都是写在 JK 项目下的，那个时候，记得最有意思的事情就是，常常这面改完代码，SVN 提交上去了，那面就喊，谁谁谁是谁，和我代码冲突了，那个谁谁谁写的代码怎么把我的代码覆盖了啊。这种事是常有的事。哈哈。很是热闹。而造成这个事情的原因呢，那肯定是代码的耦合度太高了，你想想啊，几十人的团队，你改了一处代码，而你又只知道你的那部分，你怎么知道改了之后对别人的有没有影响，是吧。要么，你就只能像盖房子一样，在代码里面充斥着大量的if else，从而使你的代码更加晦涩难懂。系统的耦合，是万恶之源啊，更像是一个慢性疾病，慢慢的侵蚀着你的系统，直到有一天，你发疯，靠，这是谁的代码，哎呦天，我都醉了，而体现在成本上，则是时间的成本，这种情况（耦合的副作用）短时间半年就能体会到，长时间，一年也足够能体验的到了啊。到时候，改一个接口，问多长时间，这个得两天吧，咋这么长时间？接口太复杂了，而且改完了，都不知道会不会把别的系统给影响了啊。哈哈哈哈。。自作孽啊。**耦合造成的维护成本，增加了没？增加了吧，无形中，公司是不是又少了一笔钱？**再继续说，你长时间在这种工作环境下工作，你痛苦不，你去找领导，领导，咱们得重构，重构要时间不？金钱就是生命啊，企业企业，让你重构锻炼技术来啦？领导还害怕啊，万一重构不好咋整，这个锅谁能担得起，算了，就这样子吧，你心情不好了，离职，我要离职，离职了，同事看见你离职了，兄弟，走啦？走了，换了一家公司，比咱们公司好多了，那个公司用dubbo springCloud ，全是新技术，还有 mq 啥的，于是呢，可能又要走了一批人了啊。。。。

总结下来，代码耦合–>维护成本增加–>开发周期变长–>程序员变得不开心（吵嘴架，甩锅）–>一个人离职–>带动大批同学离职–>招人成本提高–>新员工适应工作环境–>适应的好就留下，不好，就又走了，你说，解耦重要不重要啊。

技术为业务而存在，并因为解决业务场景产生的问题而实现自身的价值。由此可见业务的重要性。创业公司为业务的野蛮生长并没错，错的是给自己留下了太多的坑。甚至可能，在未来，就是因为你的系统才导致大批量的用户的流失。

系统慢–>用户流失
工作氛围差–>团队缺少核心竞争力