现在都在谈论全面学习代码的事情，这是件极好的事情。
比如你今天的工作是统计信息的录入，如果你恰好学会了脚本处理，你可以花1小时写个脚本简化流程，1小时录入信息。四舍五入的话等于偷懒一整天。
我们这个行业是一个伟大的行业，在工作意识上，我们是十分主张偷懒的，而且越懒越好，越懒越遭人夸。
如果你想学习这个技能请去看《Python：从入门到修禅》。笔者这里就不献丑了。
话归正题。今天想说的是关于耦合性。为了满足学霸的准确定义的需求，我这里抛出百度百科的定义。
耦合性(Coupling)，也叫耦合度，是对模块间关联程度的度量。耦合的强弱取决于模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。模块间的耦合度是指模块之间的依赖关系，包括控制关系、调用关系、数据传递关系。模块间联系越多，其耦合性越强，同时表明其独立性越差。软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。划分模块的一个准则就是高内聚低耦合。
对于一个初学者，和非从业者这些定义看完只会让你脑袋发涨，对我等阅读障碍症患者尤甚。那么如何简单理解呢。
1.什么是耦合？
为了简单理解，我举出一个例子。
我们公司的同事都爱下班后一起玩《守望屁股》（一款暴雪的网络游戏）。但是从效果上看分为2派：
- A派，沉迷屁股无法自拔，在不忙的时候，经常通宵。
- B派，因为3D晕眩问题，或者因为要陪女朋友逛街没有时间沉迷。喜欢把屁股作为消遣。
有一天公司需要开发一个紧急项目，所有工作人员集体闭关1个月做开发。结果也会不同：
- A派的人在寂寞的夜想玩守望屁股而不得，浑身难受，甚至影响工作进度。
- B派的人因为不沉迷，会找些其他的事情作为消遣。比如晚上和女朋友通电话，站在鄙视链的高处虐狗。
这个例子的主题就是依赖关系的程度，如果太过于依赖某个东西，当它突然变化时会给你造成很大的损伤。
我第一次认识到这个问题，是在总结工作的过程中想起来的。笔者是个程序员，因为近一年换了工作，已经长期不和产品相爱相杀了，忽的怀念那段日子，就在脑袋里面咂摸了咂摸，想起了原来互撕的各种理由，其实很多地方自己也不占理。
人就是这个样子，在当时死不退让；过去后再回头看，你好我好大家好。
其实当时很多问题都可以归咎到自己代码依赖性太强，一旦需求有相关更改，牵连的东西太多导致工时延长严重。当然如果产品遵循需求足够明确，在一个迭代中不更改需求，这个延长deadline的问题也可以避免来着。
2.耦合的程度越低，你越幸福
就像上面的例子，你对别的东西依赖越少，你越自由，甚至越幸福。
比如说工作。每个人都对工作有着莫大的期许。靠它吃穿，靠它养房养车，靠它赢得认同感。你会说谁都会对工作有依赖，没错，谁都会。就像刚才说的这是个程度问题。在代码中模块和模块之间也会有依赖，但是合适的程度让人舒适，依赖过度会让人痛苦。
或许你也有这种经历，正在经手的项目根本离不开你，如果时间短还好，偏偏这项目一年半载的还弄不完，这绝对会影响你的生活舒适度。
如果出现这种情况，应该尽快“解耦和”，这是编程用语，也就是减少依赖。
把手头的事情先按时间分个先后，再按先后分个优先级，看看哪些是一定要现在自己做的，哪些可以分出去给别人做。
当然，这个依赖还可能是各个地方，
比如是你房间里面占地方又舍不得扔的东西。
比如是你曾经考试失利，每次考试都会想起来的糟糕回忆。
3.减少依赖这件事并不是一蹴而就的
没错，经验主义往往不适用于那些不清楚实际情况的人。
我发现没有这个优化意识，或者实际经验的人一定会先经历加强依赖的过程。
这会让你吃些苦，如果实际情况是工作的话，那就少不了要加班了。就像笔者，为此曾经经历过几个不眠之夜。
直到你能意识到这个东西压在你身上有点重了，或者极其幸运有人提醒你这个过度依赖已经发生了。
什么时候加强依赖，什么时候减少依赖没有什么经验可言，如果非要说就应该是：在正确的时间做正确的事情。
生活中的“低耦合”是一种自由的体现，也是幸福的一种体现。
