高度抽象的代码

Posted 2022-04-05 嵌入式Max

相信每个人都想写出冗余度低，架构简洁（简洁不代表简单，而是只取必要的），容易扩充的代码，因为这样的代码能够体现出一个程序员的编程功力，同时也可以提升系统的易用性与稳定性并体现出高价值。高度抽象的代码可替代性也是比较低的，因为其实现比较难，总体的来讲，高度抽象的代码是总体的架构追求方向。

抽象程度较高的代码有着以下的优点：

1. 每次扩展只需要写少量的代码即可完整的完成一个功能的添加。
2. 代码架构简洁凝练，用尽量少的语言实现相关的功能，代码冗余度比较低。
3. 隐藏实现细节，让人更加专注于自己的那块业务，避免各方严重耦合，复杂交织在一起。

当然也有其不知道是不是缺点的缺点：

1. 代码理解起来比较困难，当然对于作者来讲可能并不是很困难，但是对别的接手的维护者来讲是比较困难的。
2. 代码隐藏了很多的细节实现，让后来的人总是会有一种浮于表面的感觉，不利于快速理解和掌握整个系统的运行机理。

可以看到，我理解它们是有两个方面，一个是从维护、理解、学习的角度来看，一个是从使用、升级、应用的角度来看。数学从初中开始到大学，其抽象程度不断地提升，高中到大学，数学的阶层我觉得简直就是质的飞跃，抽象程度一下子从达芬奇变成毕加索。

抽象程度极高的东西，你会发现它的应用价值也相应变得十分的高，比如傅里叶变换、麦克斯韦方程组，它们的抽象程度已经不是说你懂一点逻辑学的东西就可以理解并掌握了，更需要的是一种思维上的次元转换。但是它们支配了现代世界信号处理、电磁学应用的方方面面，连我们的耳朵、眼睛都是自带超级傅里叶变换的。但是它理解起来真的是让人头秃，即使梁静茹也给不了我勇气去钻研到底，只能是会用一用，维持下生活这样子。

而编程、或者算法上的抽象，比如我印象比较深刻的卡尔曼滤波、红黑树，卡尔曼滤波的五个抽象到极致的构建条件就让我看的一头雾水，相对来讲，控制体系里面的 PID 还是稍微比较容易理解的，扯远了。红黑树的定义也是十分的让人摸不着头脑，虽说它可以从二三树来去推理理解，但是如若不知，直接刚红黑树，恐怕没人知道为什么要那样定义，为什么这样那样一波变形就可以完成插入平衡、删除平衡，我时常感觉这玩意儿设计的对我这种白痴极不友好，学不动啊。

但是换一个角度，它们是不是用起来爽的一批，还有设计模式，让你自己总结一个出来，或者去完善、修改下某个设计模式，简直难于蜀道难，南上加南，但是根据它们的方法论、思想实现一个系统就是比较好用的时候，虽然你理解其本质还是稍稍有点困难，但是用起来就是顺畅。

说回现在我面对的代码，自从架构改过一次之后，变得非常抽象，让人难以理解，刚入职的时候真的会被吓到，这简直就是在你只会用一些干柴从头到尾造出一艘会漏水的小木船的时候给你来了一艘055，让你去理解并维护它，颤抖吧。我这折腾了一两个月，才慢慢能够上手改一些代码，最关键是这次跟我校招时候不太一样，校招的时候是自下而上去理解一个系统的，这次是自上而下的去理解一个系统，这就有点冷酷无情了，一下子那么大的信息量会让人过载的。

总体而言，作为鸡贼的维护者来讲，我更喜欢抽象程度没有那么高的代码，维护起来简单得很，三下五除二，Bug 搞定，作为开发者我更喜欢写出来抽象程度比较高的代码，逼格高，可用性强，价值高。这就是个矛盾，所以我很不喜欢维护别人的代码，总归要跟着别人的思路来，这是比较痛苦的一件事。

---

想做的事情就去做吧