从实践中得到的一个示例：我参加一个西班牙公司的工作面试，在那里我必须通过在线编码的形式，在一个小时以内完成一个测试。这个任务是针对文档创建一个单页面应用程序。我使用JavaScript来完成这个任务，其中只使用了libraries模块。我甚至有时间去写一些测试。他们不能理解我是怎么在不使用框架的情况下实现路由的，以及复杂的交互元素和其它很多事情。他们都是在这个行业中混迹了10年以上的资深人士，但是他们只是学习了特定的解决方案，而非原则。
学习框架，你不得不重新学习，学习那些不断出现的新的解决方案，而且你的部分经验会最终变得毫无价值。但是当你学习原则――原则是不会变的。为了创建类，我使用一个五年前编写的类库，观察者模式的实现一直没有变化。每一个类库都只执行一个功能，并且执行的很好。我从来没有想过像框架那样，将一个组件替换成另外一个。因为观察者就是观察者，它是一个模式，而不是代码。我们可能会根据任务来组合不同的模式，但模式不会改变。另外一个原则是我们可以扩展代码，但不能修改代码。我们可以在网上，或者"四人帮"的书中找到对应的根据。在这个原则下，如果你哥框架或者类库有第二个，第三个或者第十个版本，一些功能会被删除，其它功能会被修改，这会造成一些产品bug。对于修改代码来说，唯一的好原因就是适配新的浏览器，但是公开方法无论在任何情况下都不应该被修改。
编程成为了市场的受害者。它们为我们提供一个"魔法"按钮，承诺可以解决我们所有的问题。但是结果呢，我们逐渐习惯去使用它，但并不能分解复杂的问题，将小麦从麦壳中分离出来。我会去使用框架吗？只有当编写一个将来无需维护的产品时，我才会用框架。但如果要在一个会持续至少一两年的服务中使用框架的话，则完全是一种自杀行为。在此期间，你将会编写更多的代码，比整个框架的代码还要多，并且不止一次面对框架带来的各种限制。你花费在编写各种变通方法的时间，可能会比不使用框架而去实现大量必要组件的时间更多。
你不是在发明轮子。实际上，你确实是在使用类库，但是你是根据真实的场景而非预定义的方式来组合它们。有人可能会说，框架也可以进行扩展。但是如果我想要根据我的API来获取Backbone模型，或者根本不获取它们，会怎样呢？或者我想从本地存储中获取它们？如果我们有复杂的更新逻辑，它依赖时间和标记，而我们应该在获取之后向另外一个服务器发送同一个模型池，又会怎样呢？你永远不会知道。我们应该在这种情况下使用Backbone吗？我们只会使用它的5%的功能，其余的都是各种变通方法和自定义逻辑。与此同时，在理解架构原则后，我们去创建一个解决方案来适应每一个任务，并让它可以应对需求变更，并不是一件很难的事情。
众所周知，程序员在大部分时间并没有在打字，而是在思考，在设计模式方面进行思考有助于提高效率。当我寻找一些有趣的架构解决方案时，我经常会阅读一些新的类库的公开方法。如果它的实现不是很清楚，我会查看代码，但是这里有一条原则，想法是最重要的。例如，我们可以在10分钟之内完成promises，但是它的效果如何，那就是我告诉你不要学习框架而要学习架构的确切的原因。
P.S.:这篇文章就是希望能引起争论。当然，框架有一定的优势，但是它会让人变成"傻瓜"。如果不使用框架，你不能解决问题，并且因此耽搁数天甚至数周，这就是一件很丢人的事情。事实上，如果我们集中注意力在正确的事情上，在架构解决方案上，就会变得非常简单。这就是我试着告诉你的事情。希望这篇文章能给新手带来帮助，也希望这里描述的方法能够让他们将来变成非常酷的程序员。
你曾经在大型的B2C项目中使用过框架吗？
Read full article from 别学框架，学架构 - 博客 - 伯乐在线
No comments:
Post a Comment