php框架手册_无框架自卫手册

php框架手册

当您与Framework粉丝进行讨论时，可以使用以下一些论点（隐喻地）将其淘汰。

“我只需要三本书，而不包括整个图书馆的员工。” —安装框架后的开发人员

许多开发人员使用框架来构建他们的应用程序。 这本身不是一件坏事。

他们为您提供不必选择的特权。 范式，语言，哲学，风格，模式。 一切都已包含并修复。

框架支持快速的应用程序开发，或者，我喜欢这样讲，它是专注于一次性学习的原型开发（尽管RAD绝对比TLFPD更酷）。

但是，当事情变得严重时会发生什么呢？ 当您的项目根据代码库，功能，标准和开发人员的规模进行扩展时，会发生什么？

在构建RAD应用程序时进行的权衡将显示在其积压的所有技术债务荣耀中。

不仅。

在采用框架的那一刻，您已经委派了有关项目的最重要的决定：

• 质量标准;
• 编码风格；
• 应用模式；
• 域逻辑形状；
• 数据表示；

… 等等。

是的，是的，我知道。 好的框架是完全可配置的。 但是一开始，没人会在意这一点，因为这是框架的全部重点：您只想开始编码 。

而当您要更改不确定性时，已经来不及了。

框架支持快速的应用程序开发，或者，我喜欢这样讲，它是专注于一次性学习的原型开发（尽管RAD绝对比TLFPD更酷）。

但是，在所有关于不使用框架的争论中，我要特别谈谈三个：

• 当您不使用Framework时，您并不需要重新发明轮子。
• 框架引入了巨大的混乱表面；
• <Framework> Software Developer废话必须结束。

这三点非常重要，以致您可能会想到，在一般框架中通常会忽略它们，而在框架中则不会进行讨论。

当您无框架时，您不会重新发明轮子

没有框架并不意味着您必须从头开始编写所有内容。

框架迷们往往会忘记，有一些包装精美的工件称为库 。

你猜怎么着？ 他们钟爱的框架也使用它们！

我们到底在说哪个轮子？

作为项目的所有者，只有您自己知道您是要建造踏板车，拖拉机还是跑车。

您有责任选择适合您需求的车轮。 可能还有轮胎的尺寸，材料和螺丝的质量。

框架引入了巨大的混乱表面

我找到了一个公式来解释这一点：

混乱的机会=（框架面积x团队规模）/强制约束

框架面积（即公共组件的数量）越大，团队规模和异质性越大，将项目融入框架技术的变化就越大。

<讽刺>

您的项目需要一个事件发布者。 该框架具有消息传递系统。 让我们满足您的需求，使其适合框架功能！

如果框架中已有某个组件执行的功能甚至与您所需的功能相似，为什么还要评估其他库？

如果您已经有鞋子和墙壁，为什么还要去买开瓶器呢？

</ sarcasm>

相反，通过在用例的上下文中对库进行评估来选择库，这大大降低了这种可能性。

另外，在大型团队中，图书馆的引入比较容易控制。 快速检查依赖项列表即可。

当任何人都可以引用一个类并立即开始使用它时，请尝试在整个代码库中做到这一点。

换句话说， 框架是苛刻且高度熵的 。 甚至没有注意到，它们就停止为您工作，而您开始为它们工作，主要是为了避免事情失控。

<Framework> Software Developer胡说必须结束

好吧，认真

将自己标识为<Framework>软件开发人员没有荣耀。

也没有骄傲。

您将在3-5年内（Javascript为6个月）做什么？ 更改您的职务，因为框架过时了，而且一遍又一遍吗？

对不起，我对你有个坏消息。

您积累的关于框架最私有的内部部分的所有知识将很快变得无用。 您会忘记它为下一个框架腾出空间。

您是否还记得500美元的认证令您感到骄傲，以至于您将其挂在办公室的墙上？ 您最终将把它扔进垃圾桶。

在这方面，招聘也是一个很大的大问题。

我经常收到担任Laravel / Angular / React Developer职位的职位。

我该怎么回答？

“对不起，我只是一个了解业务并试图以更不可知论的方法解决问题的开发人员。”

招聘人员（至少其中许多人）不了解区别。 他们仅代理客户的请求。

请不要再要求他们雇用<Framework>开发人员，如果您是其中之一，请不要再这样标识自己。

您只是在浪费时间来积累从长远来看不会有用的知识。

结论

如果您是框架迷，并且做到了这里，那就恭喜。 我没想到这一点。

以您的名义，我会承认，在很多情况下，相比于库选择，框架更受欢迎。

但是这些是少数。

我个人的启发是：如果一个项目在战略上不相关或范围很简单，那么框架可能是有意义的。

对于其他所有内容，只需使用您真正的Craft.io即可。

翻译自: https://hackernoon.com/the-frameworkless-self-defence-manual-e9569b4924a6

php框架手册