如何”比 为什么”老得快
“如何”比“为什么”老得快
原文：https://medium.com/hackernoon/how-ages-faster-than-why-712e25c9eb3b
我以前在 2015 年写了很多 Angular back。但是最近，JS 社区在很大程度上已经从 Angular 1 转移到了其他库，反过来，我的项目也是如此。我内心深处一直知道技术——以及随之而来的知识——会过时，但这是我第一次亲身经历。我想知道:我的角度知识的哪些部分现在已经过时了？哪些部分是长久的？最重要的是，面对那些转瞬即逝的框架和库，我如何确保我作为一名工程师总是变得更好？
短暂的知识
让我们从识别转瞬即逝的知识开始——那种 10 年后对我们没有帮助的知识。这将是一个框架的 API 和语法，就像 Angular 的单向和双向绑定的语法，或者如何发出指令的机制。了解 Angular 及其 API 的本质细节对于在 Angular 代码库中高效工作是必要的，但是在任何其他代码库中都没有用。我把这种类型的知识称为“如何”，就像“我如何在角度上做 X？”。
也是那种很容易获取的知识。挑选一个框架的关键词很容易——只要谷歌一下，从 StackOverflow 复制粘贴，到处做一些基本的模式匹配，我们就完成了。因此，这类知识不仅转瞬即逝，而且因为太过普通而变得没什么价值。公司不会为这类知识雇佣高级工程师。
持久的知识
更持久的知识是“为什么”。Angular 为什么存在？为什么它有这样的功能？它试图解决什么问题？
像 Angular 这样的框架可能寿命很短，但是它们解决的问题存在的时间要长得多。Angular 的建立是为了解决编写、维护和迭代复杂 web 应用程序的问题。任何有助于我们解决这个问题的知识在很长一段时间内都是有价值的。事实上，把“网络应用”换成“软件”并不是什么难事，突然之间，我们遇到了一个会持续整个职业生涯的问题！这就是我们想要的那种知识——持久的知识。
深潜
不幸的是，问“为什么”并获得那些持久的知识并不总是容易的。特定功能背后的背景和动机是一种很难获得的知识，但它非常值得努力。我们来看一个例子。
比方说我谷歌“我为什么要用 Angular”。我可能会遇到这样的原因:
- MVC 和关注点分离
- 双向数据绑定
- 依赖注入
如果我不知道什么是 MVC 和依赖注入，以及为什么它们是好的实践，那么我只会剩下更多的问题。为什么我需要依赖注入？为什么关注点分离是有用的？
所以让我们继续挖掘(免责声明——这是超级简化的):
- Angular 使用依赖注入…
- …依赖注入对于编写单元测试很有用
- …单元测试对于维护和迭代软件非常有用
明白了！现在我了解了依赖注入，这是一种通用的设计模式，在 Angular 的生命周期中对我很有用。这些知识还帮助我更好地理解如何以及何时使用那个角度特征，以及何时可以忽略它。我们今天的棱角工作的实用知识，和未来持久的设计模式知识。双赢！
一般来说，问为什么是一个递归的过程，就像安装软件依赖一样。我们必须遵循所有的递归依赖，直到它们全部解决，否则我们会以失败的软件而告终——或者在这种情况下，不完整的理解。我们必须不断深入挖掘，直到找到我们了解其价值的层。孩子们直观地知道这一点！
你大脑的依赖树
下面是我如何(简单地)想象“为什么有角度”的知识依赖树:
Angular
├─┬ MVC
| ├─┬ Separation of concerns
| | ├── Software Maintainability
├─┬ Dependency Injection
| ├─┬ Unit Testing
| | ├── Software Maintainability
| | ├── Development iteration speed
├─┬ Two way data binding
| ├─┬ Reconciling state
| | ├── Reducing bugs在顶层，我们有最专业和最快速的解决方案:像 Angular 这样的框架。更深一层，我们进入不同框架中常见的特定模式:DI、MVC 等。随着我们深入，我们进入更基础的软件工程实践，等等，直到我们到达软件工程中的核心问题。
我喜欢这种可视化，因为它揭示了更深层次的概念是什么:构件。一旦我们深入到使用 MVC 的框架中，了解了 MVC 是什么，那么我们将把这种理解带到我们将来使用的任何其他 MVC 框架中。这就像当一个包管理器安装了一个新的包，并且发现一个已经安装的依赖项，它可以重用它。
拥有更多的构建模块不仅能让我们学得更快，对创新新的解决方案也是必不可少的。几乎每一款新软件都是受到之前许多其他想法的启发。一个例子是 redux ，它的灵感来自于 Flux 、 CQRS 、 Event Sourcing ，可能还有更多(可能是 Clojure atoms )。我们站在巨人的肩膀上，不仅仅是因为使用了他们开发的软件，还因为理解了他们引入的理念。
个人反思
我经常发现，在做一个项目时，阻力最小的方法就是查找我到底需要什么，粘贴进去，然后发送出去。但现在我意识到，半盲目地完成项目对我的个人成长来说不是最好的主意。
回顾过去，我本可以通过以下方式从我的角度体验中获得更多:
- 在 Angular 所解决问题的背景下理解它的决策
- 问为什么不怕跟着兔子洞走
- 理解角度特征背后的动机和权衡
我们应该学习框架，不仅仅是为了构建东西，而是为了学习新的想法，因为一旦框架不再使用，剩下的就只有想法了。但是，当一个框架没有教给我们任何新东西时，我想起了艾伦·珀利斯的名言:
“不影响你思考编程方式的语言[或框架]是不值得了解的。”
即使框架来来去去，我们仍然可以学习它们背后的思想，成为更好的工程师，只要我们足够深入。
黑客中午是黑客如何开始他们的下午。我们是 @AMI 家庭的一员。我们现在接受投稿并乐意讨论广告&赞助机会。
要了解更多信息，请阅读我们的“关于”页面，在脸书上点赞/给我们发消息，或者简单地说， tweet/DM @HackerNoon。