编程的几个思想
封装
编程中，我们会遇到各种各样的复杂数据和情况，如果对此不作为，复杂度会随着代码、项目的功能的增加直线上升到无法管理。就好比一堆杂乱的事物，乱摆乱放，最后如同垃圾堆一样。
我们需要使用 封装 的思想，将复杂的事物变得 “简单”。就像网购的快递一样，快递小哥用长方体纸盒把你买的东西装了起来 ，成千上万的盒子在城市里穿梭，不需要关心你买的东西的大小、重量、类型、收货人、收货地址、手机号，只用关心纸盒的类型和快递单，甚至在很多地方已经有了智能、自动化的物流系统。
从上面我们可以知道，封装的好处：
- 可以 让你不用关心任何你不需要关注的细节。
- 使系统井井有条。
当我们敲代码的时候，好的封装实际上是可以化腐朽为神奇的，它可以将杂乱如同垃圾堆一般的成堆代码 变成一个井然有序的系统，当你调用系统时你会感受到美妙——你不用关心任何你不需要关注的细节。
但是 “将杂乱如同垃圾堆一般的成堆代码 变成一个井然有序的系统”，并不是只靠封装就可以达到，当杂乱的代码被我们封装成 一个一个的模块后，相比原来的杂乱的代码，有一定的提升，但是，假如这些 代码 互相之间的调用和依赖混乱，那只是将 杂乱的代码 变成 杂乱的模块，当代码、功能日益增加，整个系统也会趋近于垃圾堆的样子。
这时我们就需要解耦。
解耦
我们需要将模块之间的调用、依赖关系用更优雅的方式定义，甚至我们需要通过拆分、合并模块来找到更优雅的模块间调用、依赖关系，其实重构有的时候也就是一个打散重装的过程，以获得更好的 模块间调用、依赖关系，以达到解耦的效果。例如我们经常将一个长达五百甚至上千行的代码，拆成上十个文件（比如7sdream 的 zhihu-py3 的第一次重构，想当年我还见过那个整个项目就一个 一千多行的 .py 文件233），其实这就是一个拆分重组文件的过程。
在现代项目中，仅仅是简单的通过拆分重组文件解耦也不够了，当模块众多到快爆炸的时候。我们需要使用系统这种级别的封装，比如框架，比如架构模式，有的时候，增加中间层也常常是我们解耦的有效手段之一。对于 web 开发者，非常值得一说的就是通过 http 协议发送 ajax 请求，它是传统前后端分离的界限，前后端分离里 前后端交互的方式 是 前端系统通过 ajax 请求 从后端系统的 api 接口获取数据。整体上来看，前后端交互的方式 就有解耦和封装的意思，并实实在在提高了复杂应用的质量（可维护性、可变性），对于开发人员的开发效率也提高不少。如果不相信，你可以想想你大学写的 c 语言版聊天程序就知道了，总之那些就是把前后端代码彻底糅合在了一起的代码，甚至都不分前后端，编写、维护那些东西可真是灾难。就如同之前是揉在同一个文件的代码，现在就是糅合在同一个系统里。就好比现代 GUI 程序 都有 MVC 分层，这些(简单的)架构模式既是抽象也是解耦的体现。复杂的架构模式的初衷其实也是与此相同，比如现在流行的 MVVM、react + redux、基于 node 的前后端分离 如何评价淘宝 UED 的 Midway Framework 前后端分离？ - 互联网 - 知乎 等等。
解耦的好处：
- 高效开发。
- 大大提高代码的可维护性、可变性。
复用
DRY 原则：don’t repeat yourself。
我们经常会将 一些被经常使用的常量 提取出来，这么做的好处一个是避免重复，另一个就是防止 以后常量改动的时候，我们需要将 几处甚至十几处 分散到各个文件的常量改变，这绝对是灾难性的，你要知道少改一处或者多改都将引入新的 bug，而这又是多么容易就会发生啊。
同样是这个原因，我们可以推广到 代码块、函数、模块甚至系统上。
这也是 don’t repeat yourself。 DRY 原则的一个重要原因。
其次对于代码规模更大的 复用，还有 高效开发的显著优点，从 qt、react-native、weex 等层出不穷的跨平台轮子可以看出，跨平台复用从来是我们程序员最热衷的事之一。
复用的好处：
- 保证了一致性、正确性，并且易于修改
- 提高了开发效率
从写好函数开始
函数是封装、解耦、复用的最小单元，提高封装、解耦、复用的能力，先从写好函数开始，千里之行始于足下。