以解耦的思路解决问题

  平日里做软件开发，期间少不了会涉及到很多技术领域的难题攻克。完善组织代码完成业务开发的比重远比攻克难题来的多。但攻克技术难题是一时的或者阶段性的，不会一直都是，否则项目就永远没法如期交付或者结束版本开发了，要么或许那就是一个研究性项目了。
  行业里可能有很多开发者自称有多年开发经验，熟练使用这样那样的第三方框架，如果把能力高定义为仅仅熟练使用第三方框架上，未免显得不成熟，更何况很多时候第三方框架不是万能的，不能帮你解决实际的繁杂业务代码问题，再说第三方框架毕竟是别人的思想和解决方案的沉淀。
  可能很多朋友感觉写业务代码比较枯燥，得不到成长，天天跟产品经理打交道，天天在堆if else，整天感觉活多、事杂还加班。其实，我想说的是写业务代码也可以很有意思，再好的库代码也是由业务代码提炼出来的，主要看你能否以解耦的思路考虑并解决问题。
  可能很多人认为那不是设计模式干的事情么。对！设计模式是对解耦的最大的提纯。我估计很多人都想过并且试过在自己项目里套用设计模式，不过套的好不好就难说了，如果是硬套会使你感觉变得四不像，扩展性变得更差了，何谈解耦。
  在做解耦工作前你必须先了解什么叫耦合，耦合是指两个或两个以上体系工作相互作用相互影响的现象，当然在你没有意识到它们有耦合存在前是意识不到有2个体系存在的，也无从谈及解耦。解耦的目的是为了将强关联变成弱关联，将一个复杂的体系拆解成可以更加独立工作的模式，从而让复杂度不会随功能增加而增加。 软件开发原理本质上生活经验的一个缩影，当然也可以反过来影响生活（作为一个开发如果升华到这个层面，想必可以做更多开发之上的大事了）。
  说到缩影与反推，我举一个小例子：当年大家大一入职的时候都要军训吧，每个班级学生都由一个教练带着进行训练，不管是每天早上第一次入队还是中场休息再归队应该都没有跑错队伍吧，一个班级少说也有几十个同学，全是生面孔，一下子全部记得不容易，但教练就一个，只要听到自己班级教练的声音或者看到他的声音就能知道自己百分之百没有跑错队伍，而且每次集合教练就管叫数，他不管有没有调包，因为压根不可能认得所有人，这种维持关系办法的缩印就是在数关系型数据中的外键约束，教练是主键，他也是班级每个同学心中的外键，在数据库设计中，维持好外键约束再多的数据关联关系都不会乱。
  可能有人想问怎样才算真正理解了解耦，而不用生搬硬套设计模式，我的回答是当你将一件本来非常耗时耗力的工作以事半功倍的结果搞定了并且连自己都不知道属于哪种设计模式，当你进入这个阶段说明你已经知道如何解耦了，只是跨出了第一步。当然解耦是一种思考方式，是一种思想，解耦的办法有很多，具体问题具体分析，平日的开发工作中，希望大家尽可能以解耦的思路考虑、分析、解决问题，积少成多，你得到的会越来越多。