少有人走的路链接：https://zhuanlan.zhihu.com/p/648004207
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
近期了解了不少关于压缩算法和程序设计的大佬文章，突然发现这两个内容是可以在某个角度达成一致的，因此写此文对想法进行记录，希望给大家带来一定的启发。
首先，非常感谢大佬们愿意花费自己的宝贵时间，分享珍贵的经验。互联网之所以伟大，就是因为有了无数大佬的奉献！在此致敬。
因为还有工作要赶，因此本文可能会略显简陋，我希望用最短的方式能够表达清楚我的想法。我没有计算机和数学的背景，因此如果有不严谨的地方烦请指正！感谢！
---
人脑的认知能力的有限性，迫使我们发展出了语言这一符号学的抽象工具来帮助我们认识世界。“语言的边界就是思想的边界”，充分揭示了人类本身必须依赖抽象工具来处理复杂事务的窘迫。因而，通过某一种方式降低事物的复杂性，是从根本上我们需要面临的挑战。
如：
“发出巨大噪音用于在两地快速穿行的铁皮大鸟”-->“飞机”
又如：
“两个由棉织物组成用于蔽体的管型柱状物体”-->“裤子”
同样从抽象的角度来说，程序设计的原则和信息论里面的压缩算法也是人类为了对抗“复杂性”而借助的“工具”。虽然他们实质上并不能简单地进行类比，不过在关于“复杂性”这一问题上，他们在一下几点是可以进行对比思考的。
压缩算法的目的是用更少的步骤表达相同的信息。
如：
10000 --> 1 + 0 * 4，是一种最简单的压缩算法
再如：
alpha_alpha_alpha_beta_beta_beta_sigma
-->
0_0_0_1_1_1_00 + (alpha:0, beta:1, sigma:00)
Huffman 树这种给可枚举内容编码的方式。
类比于程序设计里面的复用的目的是减少代码的重复。
从减少重复的角度来说，复用就是用更少的步骤表达了相同的信息，无论是面对对象编程还是函数式编程。
如：
我们创建一个包含 Eat Run Speak 方法的基类 Animal，通过继承的方式可以得到一个 Dog(Animal)，重写其中的 Speak 方法为 print("Bark!") 来改变内容，还有 Cat(Animal)，print("Meow~")。如果不借助OO继承的特点，创建一条狗和一只猫可以被表示为：
Dog: Eat() Run() Speak{"Bark!"}
Cat: Eat() Run() Speak{"Meow~"}
而通过继承，我们可以表示为：
Dog(Animal): Speak{"Bark!"}
Cat(Animal): Speak{"Meow~"}
其中一些基础通用的信息已经通过 Animal 来复用了，我们通过更少的“语言”表达了相同的信息。
总之，无论是压缩算法还是程序设计，有一个关键的问题是我们需要回答的：
“一个操作，有没有降低问题本身的复杂度？”
如果一个事情已经足够简单，那么继续增加抽象操作只会徒增负担。比如Python里有时明明可以通过几个if语句来清晰地描述逻辑关系，非得连套多层一行的if表达式+列表生成式。
我还想进而提出第二个问题：
“为处理复杂度而引入的工具，是否引出更多复杂度？”
在压缩算法领域内，一个压缩率越高的算法，其压缩和解压缩的速率相对就越慢，最终压缩算法的选择是对压缩解压缩速率和压缩比的权衡取舍。在程序设计上，对于类的使用也只有在正确使用的情况下，才能友好地帮助我们更好地进行编程。
回到我们的目的“以最低成本处理复杂事物”上，我们有：
cost_raw = return_deal_time(raw_info)cost_1 = return_deal_time(compress_method_1(raw_info)) cost_2 = return_deal_time(compress_method_2(raw_info)) # ... ...cost_n = return_deal_time(compress_method_n(raw_info)) cost_list = [] # ... ...for cost_i in cost_list:
if cost_i > cost_raw:
print("Bad method.")
else:
print("Not bad.")这不是一个难以理解的目标函数，如果我们为处理复杂度而引入了更为复杂的系统，则显得过于冗余。
正如大佬在文中所说，对微服务、对象、函数的滥用，都是违背了其创造起初的目的的。一套工具的发明是为了解决问题，而不是为了维护其自身的存在。（这种被发明出来为解决某个问题但随后其目的却转变为维护其自身存在的东西一般有两个：金融和政党）
直到我的客户开始极致的追求微：为了小而小。完全不考虑微服务究竟要解决的是什么问题，带来的又是什么问题。而社区内又一片热捧，几乎每个人都在谈它的好处，却鲜有人谈它带来的问题。
所以一些不分上下文、应用场景，讨论OO、FP的优劣的发言，属实有点逆天。玻尔在他的书《整体性与缠隐序》里面大概是这么批判这些人的，即语言符号系统只是我们了解世界的工具，有些人却把工具当作世界其本身。
抛开这种工具卫道士的现象不谈，我还看到一个观点是这样认为的：
“复杂性不会消失，只会转移。”
很显然这句话具有误导性，如果该句话意指复杂性就像“热量”一样，只会“扩散”，不会”消失“，因而对复杂度管理的任何尝试只是徒劳之举，那么这句话里的“不会消失“就是错误的。因为相同的”热量“，其富集程度也有区别，正如”复杂度“，管理复杂度本身的”复杂度“，也有区别。
绕回来了！终于想起了我们的标题，为什么前辈们总结出应对复杂度的方法之一是”高内聚，低耦合“，正是于此！
小结：
以上内容是我的一点感悟，用以记录。如果给到其他朋友启发就再好不过啦~
---
参考文章：
