git 怎么解决分歧_一项著名分歧的令人失望的解决方案-优快云博客

git 怎么解决分歧

两位软件工程巨头不同意，其中一位最终同意了这一论点。但是，我发现该分辨率不令人满意。这是关于大卫·帕纳斯（David Parnas）和弗雷德·布鲁克斯（Fred Brooks）的；没有他们的贡献，软件将不会像今天这样。他们的分歧涉及塑造现代编程技术和开源的思想。

David Parnas撰写了一篇关于信息隐藏的论文，这是封装概念的前身。他比较了软件系统的两种模块化。在其中一个中，设计决策和数据结构对于整个应用程序都是可见的，而许多决策则隐藏在第二个应用程序中。第二种实现更容易理解和更改。

弗雷德·布鲁克斯（Fred Brooks）写下了永恒的经典：《神话人月》。它解释了为什么在项目中添加更多的程序员通常不会加快速度。其结果部分是由于增加了培训和沟通开销，而且还因为不可能将复杂的项目分解为整齐的独立任务。从布鲁克斯管理IBM开创性的OS / 360的时间开始，他就得出了自己的看法。开发中最有趣的决定之一是团队中的每个程序员都可以访问整个代码库。

布鲁克斯称保护程序员远离他人编写的代码的想法是“灾难的秘诀”。正如Brooks解释的那样，必须公开访问代码，因为很少会“完全且精确地定义”接口。因此，分歧在于信息隐藏的好处和公开共享代码的好处。在1995年，弗雷德·布鲁克斯（Fred Brooks）在其书的修订版中的标题为“帕纳斯是正确的，而我对信息隐藏是错误的”中承认了这一论点。

那么，为什么我觉得这个分辨率不能令人满意？开源没有建立共享代码的价值，我们不需要封装吗？我认为，两者都是正确的，而且冲突并不像看起来那样真实。也许是因为当时缺乏可用的协作工具和技术而引起的分歧。我断言，信息隐藏对于公开共享代码的成功至关重要，它绝非冲突。

今天，我们认为信息隐藏不是程序员的隐藏代码，而是封装的要求。实现细节不是对其他程序员隐藏的，而是对其他程序员的代码隐藏的。程序员来来往往，但是我们编写的代码仍然存在。程序员编写代码的责任不依赖于其他模块的实现细节。现在，许多语言都提供了使创建这些不必要的依赖关系变得更加困难的机制。

就像帕纳斯（Parnas）很久以前所宣称的那样，今天人们已经达成广泛共识，即不依赖于其他模块的实现细节的封装良好的代码更易于理解，使用和维护。开源的成功取决于我们编写其他人可以理解和改进的代码的能力。

信息隐藏和代码公开访问这两个看似相反的位置毕竟是互补的。