软件架构之“道”和“术”哲学思考

有道无术，术尚可求，有术无道，止于术
道为事物规律，术为规律之用。有道者术能长久，无道者术必落空，学术先需明道，方能大成，学术若不明道，终是小器。

Hello~，断更了有一段时间了，笔者又回来啦。最近发生的两件“大事”让我们这些群众每天都有“瓜”吃hhh,剧情发展好像还挺魔幻， 友云：“最近我们都在为两件事操心，一件是中国最有钱，一件是美国最有权，话说你的KPI完成了吗其实在两位70多岁老人竞赛前笔者是押红方川宝赢的，经过几天数据惊心动魄地刷新，唉，最终还是凉凉了。另一件蚂蚁延迟上市之事，作为股民的大伙肯定有很多想法，反正笔者的红包是没了，唉，在风口浪尖上财富自由这个词总有那么几层意味。言归正传，笔者今天想聊一聊我对软件架构的哲学思考，这是一个超大的命题，即使某些前辈在软件领域摸爬滚打多年，也不敢说已经窥其一二，今日胡说一通，希望得到大家的指正，这也算是最近和某位某级从业软件多年的大佬聊地总结的一些心得。

emm,下面确实有 Bug ……

单一职责原则single responsibility
一个代码组件（例如类和函数)应该只执行单一的预设的任务。

开放封闭原则open close
程序里的实体项（类、模块、函数等)应该对扩展行为开放，对修改行为关闭。换句话说，不要写允许别人修改的类，应该写能让人们扩展的类。

里氏替换原则Liskov Substitution
里氏替换原则的内容可以描述为：派生类（子类)的对象可以在程式中代替其基类（超类)的对象。

接口隔离原则interface Segregation
指明客户应该不依赖它不使用的方法。接口隔离原则，拆分非常庞大臃肿的接口，成为更小和更具体的接口，这样客户将会只需要他们的感兴趣的方法，这种缩小的接口也被称为角色接口。接口隔离原则的目的是系统解开耦合，从而容易重构，更改和重新部署。

依赖倒置原则Dependency inversion
程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

以上的五个原则构成了著名的SOLID，除此之外，还有一个著名的高内聚低耦合原则，是指具有相似功能的代码应该放在同一个代码组件里。一个代码片段（代码块，函数、类等)应该最小化它对齐代码的依赖。这个目标通过尽可能少的使用共享变量来实现。“低耦合是一个计算机系统结构合理，设计优秀的标志，把它与高聚合特征联合起来，会对可读性和可维护性等重要目标的实现具有重要的意义。”该原则和我们之前提到的把复杂性封装在更低的层次上是一致的。对复杂性的封装就是高内聚。

行走在软件江湖

如果软件行业是个江湖，那我们程序员就是行走在江湖上的武林人士。每个人要做的就是找寻“道”，研习“术”，磨炼“器”。
“道”是价值观，是你的江湖理想，是你的追求。就像《神雕侠侣》时期守襄阳，信奉“侠之大道，为国为民”的郭靖
“术”就是你的内功心法和拳艺招数。数据结构和算法就像是内功，帮助你提高对战的效率。和各种其他方法就像是招数，你可以像是学了独孤九剑的令狐冲，仅凭招数就可以杀敌无数，但是要成为武林盟主，内功修养也是不可或缺的。
“器”是工具，各种语言、IDE，可以划分到“器”，工欲善其事，必先利其器，各位大侠行走江湖，免不了要选几样趁手的兵器，有人喜欢剑走偏锋，有人喜欢暴力砍杀。什么，你说你喜欢九齿钉耙者只能赞你一声：二师兄威武hhh。
江湖苦修非一日之功，希望各位大侠在软件江湖早日得道，成为武林至尊或者一方豪杰！

写到这里呢，笔者组建了一个高质量的技术交流微信群，欢迎各位江湖同僚们入群各显大招！
ps:若二维码过期可私信博主，博主拉你。