连载 | 第2篇：不要盲目迷信NB的设计模式
各种架构模式走马换灯
2006年，我进入游戏行业，彼时流行面向对象的程序设计：上手代码前，先设计一个类，把接口写好。
如果当时你还在用面向过程的方式编程，会被别人看不起，还会被讽刺：“你面向对象的思维方式还不成熟。”
2012年，随着Unity的兴起，组件化开发在游戏行业迅速火爆，一切皆组件！
“你写个组件就完事了”；“你这个没有用组件的思想”，熟悉的讽刺又来了。
2018年，又兴起了ECS架构，Entity, Component Data，System。Entity 实例，包含各种Component Data，Component Data，组件的数据，不含方法， System 完成特定功能的算法，数据来自Entity中的 Component Data。好高级啊,这个666。
但是大家有没有发现：ECS又回到了C的面向过程的模式，算法处理纯数据结构。
system 函数方法，Entity 纯数据实体，不就是C语言的函数+结构体么？！之前不是说面向过程不好么？怎么ECS又回归了呢？
“组件化开发过时了，你要用ECS。”
扯淡！我用C语言开发的时候，你还在读初中... ...
不要盲目迷信某种架构模式
当出现新的架构与设计思想时，我们首先要详细地了解它是什么，解决哪些问题，优势是什么，缺点是什么，本质是什么？
<u style="text-decoration: none; border-bottom: 1px dashed grey;">没有过时的架构思想，只有合适的。能简单解决问题的就是好方法。</u>
例如，你的游戏用组件化开发很快能完成，稳定，没有bug，又满足要求, 为什么要改成ECS呢？
Linux一切皆文件的设计思想和模式，一直没有变过。
C语言面向过程的设计方式，缔造了一个又一个经典框架和工具。GCC、Git、Linux、FFMPEG、Redis、Nginx等。
扎实的代码基础，扎实的OS底层基础，完整的知识体系结构, 才能让你驾驭这些设计模式。从解决问题出发，框架设计来源于解决问题，又回到问题中更好的解决问题。
任何设计模式思想，都要回归问题的本身。解决怎样的问题，优势是什么? 在实践中总结设计模式，然后用于实践中解决问题，而不是给自己思想上造成困扰，要达到无招胜有招的境界。
如何成长为架构师
1、先精通一门语言的核心机制和运行原理再触类旁通。不要一上来就讨论这个语言好，哪个语言差，先把你用的这个语言搞懂再说。比如, 局部变量分配在哪里? new 出来的对象内存分配在哪里？什么是垃圾回收, 什么是内存碎片，怎么引起的等等。
2、养成良好的编码习惯，写的代码能知道代码的结果。我们很多同学，写代码不规范，总是丢三落四, 自己写完代码后，说不出来结果是什么，出了问题，全靠调试器, 完全不知道如何去分析错误。要让自己养成每行代码下去清楚的知道结果是什么，能说出来这个实现的开销，时间复杂度，空间复杂度等, 做到每行代码心种有数的习惯。
3、在数据结构与经典算法不熟悉之前，不要漫谈架构。链表怎么设计, 动态数组怎么设计, 内存池怎么做, Hash表怎么实现, 树怎么设计, 图怎么设计, 某个算法的时间复杂度是多少？空间复杂度是多少？最短路径，AStar寻路, 排序等等。这些经典的算法和数据结构，必须掌握好，徒手就能实现。因为落地一个架构，最终就靠这些。
4、阅读开源代码, 学习优秀的架构设计。搭建完完整的知识体系以后，熟练了数据结构，精通了编程语言机制。这个时候可以（或：要）学习别人解决问题的方法与架构，可以阅读一些开源的框架与工具，绝不是某个师兄的NB的项目，而是真正开源有名气的，一直在用的框架，如Redis,nginx,Linux内核等相关行业真正的明星开源框架。
首先分析需求, 这个框架到底是解决什么问题的，先学习相关的理论知识和基础，了解这个框架的基本使用。
分析源码的目录结构，从问题出发，看看框架是如何展开来解决问题的，如何把问题转成架构，分而治之的。带着重点的问题，阅读框架是如何解决这些问题的，哪些数据结构用的巧妙，如何克服一些问题，哪些功能它实现了，哪些功能留个用户实现，如何开放接口给用户，这么取舍的理由是什么？随着不断积累与思考，你就能明白设计的思想和技巧。
最后, 当你能够驾驭数据结构与代码，有了完整的知识体系，能够从实际解决问题出发，选取最佳解决问题的方法时，你就能形成一个自己的设计与框架，并能组织好公司的团队，完成对应的项目功能和需求。至于什么模式，并不重要。
结语
黄猫黑猫，捉到老鼠就是好猫。
在设计上，能简便快捷地解决问题的方法，就是好方法，就是好模式。
关于学习的任何问题，都可在评论区提问。Blake老师已将身体锻炼棒棒的，争取翻每一位同学的牌子~
**学习交流群：https://jq.qq.com/?_wv=1027&k=5gY1e8B
