站在大师的肩膀上 - 学习那些伟大的编程思想_一些伟大的编程思想(1)

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

一个模块/类/方法，应该只有一个职责，只实现一个功能。

这样逻辑简单，易于编写，易于维护；当我们要实现更复杂的功能时，可以组合多个这样的简单的功能。

是不是很熟悉？没错，这也是 UNIX 哲学。

Open/Closed Principle - 开闭原则

程序应该对扩展开放，对修改关闭。

简言之，我们可以在一个已有的功能上，增加新的功能，但是不要修改这个已有的功能。
这应该是开发新功能最稳妥的方式了。

Liskov Substitution Principle - 里氏替换原则

子类型可以代替父类型。
当一个模块依赖某个类型，我们可以使用这个类型的子类型代替这个类型，系统仍然正常运行。
这个跟 OOP 中的继承、多态紧密联系。

Interface Segregation Principle - 接口隔离原则

不同的功能，应该由不同接口定义。
每个接口尽可能声明最少的方法。
减少耦合。

Dependency Inversion Principle - 依赖反转原则

上层模块不应该依赖下层模块的实现细节。

两者都应该依赖抽象。
抽象不应该依赖细节，细节应该依赖抽象。

UNIX 哲学

软件的功能应该尽可能简单，专注于做好一件事。小即是美。
在 UNIX 中，有各种优秀的工具，它们大都专注于做好一件事。
我们可以编写脚本，组装这些工具，完成更加复杂的功能。

Hyrum’s Law (The Law of Implicit Interfaces)

隐式接口定律：
当你提供一个 API 给外部系统使用时，不止你的接口文档，你的响应中的一切细节，都会被外部系统依赖。
举个例子，我们对接支付系统，调用支付接口报错。我们会根据支付接口返回的响应码 code，甚至是返回的 msg，判断是什么错误、然后再决定我们该做什么处理。
相信很多朋友都处理过这种情况，这说明了 API 的设计不是一件简单的事。好的 API，需要下很多的功夫去设计。

Brooks’ Law

《人月神话》作者提出的论断：

Adding human resources to a late software development project makes it later.
向一个延期项目增加人力，只会令这个项目更加延期。

在项目已经延期的情况下，增加人力，新来的人要熟悉项目，新人和老人要沟通，这些都需要额外的时间。
最终的结果就是，项目又往后延期了。（想想我们有没有遇到过这种情况？）

帕累托法则（八二法则）

这个法则有多种表述：

• 20% 的时间可以解决 80% 的问题。（剩下 80% 的时间解决最难的 20% 的问题；举个例子，在编程中，我们 80% 的时间在调试）
• 20% 的工作产生 80% 的收入。
• 20% 的功能可以满足 80% 的使用需求。（开发一个产品，实现基础功能，就可以满足大部人的需求了；那些花哨复杂的功能，只有少数人需要。）

八二法则对我们的启示：集中精力解决最重要、最基本的问题。

Moore’s Law

The number of transistors in an integrated circuit doubles approximately every two years.
集成电路上的晶体管数量，大约每两年翻一倍。

没错，作者的原话是 每两年 翻一倍（不是18个月）。
谁能想到这个论断，对计算机行业的发展，产生了多么重大的影响呢？

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

**

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取