软件工程里没有那么多的新东西，要从更高一级的层面去反思技术的演进，去了解技术的历史，分析推动技术演进的背后因素，以及当前技术的优缺点和瓶颈，也就可以猜测技术以后的几个大概的演进方向。软件工程的核心是抽象，现在我另外觉得不管是业务开发还是底层框架开发，软件工程开发环节的本质是逻辑的组织与表达。简单的逻辑是人脑瞬间就能组织出来的，如A箱子里有10个糖，B箱子里是空的，如果我想平均分，那么这个逻辑自然就是从A箱子里拿出5个放到B箱子里。复杂点的逻辑就是普通的人脑所不擅长的了，而且这种复杂往往有两种，一种是质上的复杂，这就只能靠少数聪明的大脑才能把这种逻辑组织出来，也就是“算法”和“数据结构”，另一种是量上的复杂，即由于组织起来的逻辑虽然简单，但是数量非常庞大，这种逻辑虽然能组织起来，但是在表达上存在问题，即普通的人脑很难理解这种逻辑，尽管这种逻辑是走的通的，但是对于工程项目来说，别人甚至自己事后都很难理解的问题是很严重的，这时候就需要“设计模式”来对在量上比较复杂的逻辑进行更合理的组织，从而让其表达的更易让普通的人脑理解。现在总结一下，软件工程里最核心的东西或者说工具就是：“简单逻辑” + “算法” + “数据结构” + “设计模式”，我觉得这是软件工程从诞生到现在从未改变的东西。（插句题外话，“简单逻辑”是普通人都有的能力，“算法”和“数据结构”需要的是数学能力，“设计模式”需要的是抽象能力）

而这几十年软件工程行业一直在快速发展，改变的只是“场景”，或者说是由于“场景”的推动，催生出了操作系统、数据库、开发语言以及业务层面的各种框架、库、编译器，他们全都是基于那4样最核心的工具创造出来的，只是不同的“场景”让开发者给它们穿上了很多层不同的外衣。并且，这种场景的变化也会催生出新的场景，无穷无尽，所以说“场景”才是推动软件工程发展的动力。但是现在这种变化是越来越细、越来越小，以至于现在业务层的各种层出不穷的框架、工具其实只是在原先的基础上把最外一两层的外衣进行个替换或者裁剪，然后就创造出了所谓的新东西，其实从本质上讲没有新的东西，甚至是绝大部分的内容都没改变，改变的只是相对表层的一点东西，但正是表层的这一点改变，往往带来的使用上的很大的变化。 而这种使用上的较大变化让一些人感觉学不动了。其实，只要我们理解到了这个层面，就会发现透过表象看清本质，需要重新了解的部分并不多，关键在于理解“场景”，知道为什么要这么变化，并且反思这种变化带来的利弊，以及客观瓶颈，如果这么做，也许还能走在“场景”前面，可能对未来的技术技术迭代都能接受的理所当然。

说到这，可见对“场景”的准确深入的理解的是非常重要的，但是我还没具体的解释我所表达的“场景”是指什么？对于业务开发而言，这个“场景”就是指业务领域里的用户需求，而要深入准确摸清用户的需求，不能单纯的指望用户去表达，重要的是要掌握相关的业务领域知识。对于造各种轮子而言，这个“场景”就是各种性能要求或是开发者的使用体验，而要搞清这种需求，需要的可能是对客观硬件或是设计理念的理解。