---
title: "程序设计的哲学"
author: "Perrin Yong"
author_profile: https://www.pystone.net/profile/
published_by: "Perrin Yong"
canonical: https://www.pystone.net/notes/philosophy-of-programming/
type: note
content_role: unspecified
visibility: public
id_stability: rename-stable
source_path: "10-计算机、信息技术与工程/03-软件工程与质量保障/软件体系结构与设计模式/程序设计的哲学.md"
content_hash: cd12c8f32f8362f8afc4a4894b35f91b5e1f654a431b7ff13529a6321a558e4a
knowledge_version: 224c990773de.5fa8af6e39fa
site_commit: 224c990773de166d23a886306577dd90379529ce
notes_commit: 5fa8af6e39fa3891d1b9b4832bfa6c4e0ecaaf0a
---
# 程序设计的哲学

> 创建时间：2024/1/13 20:43

#

耦合高的一组逻辑模块，如果遇到需要剥离其中的一部分逻辑，方便在其他地方复用，修改起来经常比较困难，经常需要仔细读懂老的流程，一点点逐步改完。耦合情况复杂，模块的职责没有分清楚，牵一发而动全身是时常发生的事，而且更加可能引入新的错误。所以碰到经常变动的模块，最好是提前做好设计，做好抽象，提前做好隔离。

拆分必然会带来沟通成本，不论是人与人的沟通还是模块之间的沟通。分得很细碎，沟通成本就变得比较突出。
耦合越低，抽象层次越多，则代码更加不容易被别人理解。又因为别人阅读困难，有时无法理清流程，修改起来犯错就在所难免。有些解耦合的方案甚至只能让第三方人员只有在调试的时候才能稍微理解下流程！这对于一个目标上线的项目来说，维护成本是很大的。我经常看见一些几乎整个项目生命周期不用变的模块代码，耦合被解的“很漂亮”。这些代码后期没有遇到任何调整，却附加了很多维护阅读成本！
耦合低有好有坏，我们需要甄别当前处于哪个场景，是否收益大于付出。要明确自己的目标，解耦合只是你达成目标的一种有成本的方式途径，不应该是你的根本目标，不能为了解耦合而去解耦合。在"会被"频繁修改的地方，注息解耦合，比如新手引导模块。在没有频繁更新的模块中，耦合高也并不代表不好分离，不好维护。反而合理的职责划分、封装，适当的耦合度还能帮助后人较快上手这段代码。比如C#的List<T>，跟我们的业务逻辑代码耦合度相当高，但是这个绝大部分情况下都不影响我们重构维护。只要划分好了职责，做好了封装，分清了变化的和不变化的，那么我们就能找到一个很好的平衡点，既方便后期扩展，又通俗易懂好维护。
耦合高之于耦合低就好比一体机电脑和组装电脑。对很多没DIY需求的人来说，一体机电脑稳定又省事，售后方便，用他五六年都没问题。对于喜欢DIY的用户来说，当他知道自己要升级哪些零件，或者想搞个好点的显示器之类的时候，选择组装电脑的多。相反，如果没有DIY需求的用户去买了组装机，那么电脑组装、电脑维修对这个用户而言是个不小的负担。比如组装机零件坏了，得把相关的零件发给不同的商家维修或者自己去换一个类似的新的可以替代的零件，整机就只用发给唯一的一个品牌的售后中心，自己不用关心这么多细节。耦合高并不能作为软件质量差的评判依据，耦合低当然也并不代表软件质量好，一切从需求出发，实事求是。

转自：https://zhuanlan.zhihu.com/p/33763401

## 程序设计的哲学
一切封装都是以丧失灵活性为代价的。 你通常需要用许多库， 他们支持的矩阵类型各不相同。 到头来还是发现裸指针这种危险的东西最通用最灵活。 就拿 LAPACK 来说， 你封装出来的 API 要么没有原来的那么灵活， 要么非常复杂。 这也是为什么做数学和物理的人通常比较 old style， 不喜欢过多纠结语法， 而是只选最基本的来用。 例如直接用裸指针和 LAPACK 接口。

https://www.zhihu.com/question/267156650/answer/774590455