pith角度 roll角度_角度最差的部分

最新推荐文章于 2024-09-27 10:11:28 发布

weixin_26723981

最新推荐文章于 2024-09-27 10:11:28 发布

阅读量288

点赞数

文章标签： python java 人工智能

原文链接：https://medium.com/javascript-in-plain-english/the-worst-part-of-angular-1db587453fee

版权

pith角度 roll角度

更正 (Correction)

Comments on this article have made me aware that template type-checking does happen, but not by default. You have to opt-in to it on in your tsconfig.json: https://angular.io/guide/template-typecheck. That’s to some degree the latter 2 of the 3 C’s discussed later in this article. The first C can come from the IDE extensions for Angular, also opt-in. These are only nice if the project founders (which may or may not be you) opt-in.

对本文的评论使我意识到确实会进行模板类型检查，但默认情况下不会。您必须在tsconfig.json中选择加入： https ://angular.io/guide/template-typecheck。在某种程度上，这就是本文稍后讨论的3 C的后2个。第一个C可以来自Angular的IDE扩展，也可以选择加入。仅当项目创建者(可能是您，也可能不是您)加入时，这些才是不错的选择。

Read on to the “My Experience” section later on in the article. This strictness being opt-in bit me in the “behind” on a particularly troublesome project I inherited, which is where the motivation of this article comes from.

阅读本文后面的“我的经验”部分。在我继承的一个特别麻烦的项目的“背后”中，我选择了这种严格性，这就是本文的动机所在。

So, at the very least, enjoy an article about the importance of interfaces/modularization in software engineering. Oh, and make sure to turn on type checking in your Angular app.

因此，至少，请享受一篇有关接口/模块化在软件工程中的重要性的文章。哦，请确保在Angular应用中打开类型检查。

角并不全都可怕 (Angular Is Not All Awful)

I’ve worked with Angular professionally, some good and bad codebases. I have to say, most of Angular is fine. It has a component model, dependency injection, a neat introduction to RxJS and reactive programming, and decent support for web components. Some of the concepts and structures are similar enough to Spring that some of my junior backend colleagues were able to find their way around the codebase — which is valuable in-and-of-itself.

我曾与Angular一起专业地工作过，有一些好的和坏的代码库。我不得不说，大多数Angular都很好。它具有组件模型，依赖项注入，对RxJS和React式编程的简洁介绍以及对Web组件的良好支持。一些概念和结构与Spring相似，以至于我的一些初级后端同事都可以在代码库中找到自己的方式-这本身就很有价值。

Angular also holds a place in the history books. AngularJS (version 1) was a big deal when it came out — or so I’m told. Version 2 was a major driver behind the broader adoption of TypeScript, for which I’m thankful. The transition to a componentized design approach was a gamechanger for the field. We should not look at it with total disdain.

Angular在历史书籍中也占有一席之地。 AngularJS(版本1)问世时意义重大-有人告诉我。第2版是TypeScript广泛采用的主要推动力，对此我深表谢意。向组件化设计方法的过渡是该领域的游戏规则改变者。我们不应完全不屑一顾。

Angular does continue to be in common use, and I don’t think that’s entirely a bad thing. I’m not here to bash on Angular.

Angular确实仍然很普遍，我不认为这完全是一件坏事。我不是来这里抨击Angular。

But, there is at least one thing horribly wrong with Angular. And I don’t think it’s easy to fix.

但是，Angular至少有一件可怕的错误。而且我认为修复起来并不容易。

No, I’m not talking about the boilerplate, the learning curve, the performance, or the upgrade process. My beef with Angular is far more fundamental and perverse.

不，我不是在谈论样板，学习曲线，性能或升级过程。我的Angular牛肉要更基础，更反常。

Angular fails to enforce its most important contracts, causing falsehood to slither into the heart of any Angular project.

Angular未能执行其最重要的合同，从而导致虚假信息渗入任何Angular项目的心脏。

接口和模块 (Interfaces and Modules)

Believe it or not, writing code is easy. Chances are you’ve pulled together a “throw-away script” to solve a quick problem; some of the best times I’ve had as a programmer was writing Python scripts to parse logs or play with CSVs. If writing code was easy, how is it that we have the phrase “throw-away code”? Q.E.D.

信不信由你，编写代码很容易。您很有可能整理了一个“扔掉的脚本”来解决一个快速的问题。我作为程序员遇到的一些最好的时光是编写Python脚本来解析日志或与CSV一起玩。如果编写代码很容易，那么我们怎么拥有“扔掉的代码”这个短语？ QED

So, what makes software development hard?

那么，什么使软件开发变得困难呢？

You might argue writing quality code is hard — and you would be right. Almost. You have to go a layer deeper and define quality.

您可能会认为编写质量代码很困难-而且您是对的。几乎。您必须更深入地定义质量。

Quality isn’t getting a computer to do what you want efficiently —though that can be a challenge at times. No, writing code for computers to read is easy; writing code for humans to read is hard.

质量并不能使计算机有效地完成您想要的事情，尽管有时这可能是一个挑战。不，编写供计算机读取的代码很容易；编写供人类阅读的代码很难。

The hard part isn’t writing, it’s reading. As code increases, reading complexity grows O(2^n) — exponentially. This is the fundamental problem of our profession; systems come out of programmers faster than they go in.

最难的部分不是写作，而是阅读。随着代码的增加，读取复杂度呈指数增长O(2 ^ n)。这是我们职业的根本问题。 系统从程序员出来的速度比进入系统更快 。

So, how do we reduce how much reading we have to do?

那么，我们如何减少要做的阅读量呢？

Easy. Break systems into smaller systems (“modularization”), then represent systems with interfaces — a set of expectations on how to interact with the foreign system.

简单。将系统分解为较小的系统(“模块化”)，然后表示具有接口的系统-有关如何与外部系统进行交互的一组期望。

All software systems are built on trust. Modules of a system trust the interfaces exposed by other modules. Interfaces hide the details of a foreign system so we don’t have to understand all the implementation details.

所有软件系统都建立在信任之上。系统的模块信任其他模块公开的接口。 接口隐藏了外部系统的细节，因此我们不必了解所有的实现细节 。

阳光下没有新事物 (Nothing New Under The Sun)

If you think about it, “trust in interfaces” isn’t specific to programming at all. It’s the basis of trade, law, engineering, government, communication — all of human civilization. You know what to expect at a checkout counter, at a restaurant, with a coworker, with an employer, or in a classroom because the interfaces are defined, making your daily life possible.

如果您考虑一下，“对接口的信任”并不是专门针对编程的。它是贸易，法律，工程，政府，通讯的基础-所有人类文明。您知道在结帐柜台，餐厅，与同事，雇主或在教室中会有什么期望，因为定义了界面，使您的日常生活成为可能。

It goes further: a synonym for “trust in interfaces” is faith: faith that other systems not only exist but will do what they claim; will keep their word; will fulfill their interface. I‘ll spare you the full preachin’, but let it be said that “separation into modules” and “keeping of interfaces” are ancient, wise, and highly revered practices going back thousands of years.

更进一步：“信任接口”的同义词是信念：相信其他系统不仅存在，而且会按照他们的要求行事；会遵守诺言将完成他们的界面。我会全力以赴，但是可以说，“分离模块”和“保留接口”是古老，明智且备受推崇的做法，可以追溯到数千年前。

Computers are new, but the principles of systems aren’t.

计算机是新的，但系统原理不是。

So a framework that screws up interfaces would be a pretty bad thing. Like, sacrificing the fundamental precepts of civilization (and arguably existence), bad.

因此，搞砸接口的框架将是一件很糟糕的事情。例如，牺牲文明的基本戒律(可以说是存在的话)是不好的。

管理界面和TypeScript (Managing Interfaces and TypeScript)

Typed systems are awesome at managing interfaces. What does that entail? Here are 3 C’s to help you remember: Communication, Compliance, and Change.

类型化系统在管理界面方面很棒。这意味着什么？这里有3个C可以帮助您记住： 沟通，合规性和变更 。

通讯 (Communication)

When you hover over a variable and see the type, or when you hit “.” and see the methods on an object, that’s the type system oozing interfaces into your brain through osmosis. Those “Intellisense” features trick you into reading interfaces very efficiently, provided courteously from typed systems and module interfaces.

当您将鼠标悬停在变量上并看到类型时，或单击“。”时并查看对象上的方法，这就是渗入渗透到您的大脑的类型系统。这些“ Intellisense”功能会诱使您非常高效地读取接口，这是由类型化系统和模块接口提供的。

Realize that an interface is more than the methods and types. An interface also includes behavior and expectations (a fact often forgotten by junior engineers), which can be conveyed through docstrings or documentation.

意识到接口不仅仅是方法和类型。 界面还包括行为和期望 (通常是初级工程师会忘记的事实)，可以通过文档字符串或文档来传达。

合规 (Compliance)

One common complaint among newcomers to strongly-typed languages is the difficulty in getting code to compile. Experienced engineers, however, celebrate this very same fact, and language designers try to do this on purpose. This isn’t a bug; it’s a feature of strongly-typed languages.

新手对强类型语言的一个普遍抱怨是难以获得代码进行编译。但是，经验丰富的工程师对此也很赞扬，而语言设计师则是故意这样做的。这不是错误；这是强类型语言的功能。

Strongly-typed systems will stop you from making stupid and subtle mistakes at run-time, catching slip-ups before they become problems. They do this by checking whether your system uses other interfaces properly — at least, the ones it can check.

强大的系统会阻止您在运行时犯下愚蠢的错误，并在出现问题之前及时发现错误。他们通过检查您的系统是否正确使用其他接口(至少是它可以检查的接口)来完成此操作。

The behavioral aspect of interfaces cannot be asserted through compilers and typed systems alone. That’s where automated testing comes in, which is a different article altogether.

接口的行为方面不能仅通过编译器和类型化系统来断言。那就是自动测试的地方，这是另一篇文章。

更改 (Change)

Sometimes, foreign systems change in ways requiring additional changes in your system. These changes may or may not be difficult to incorporate, but you must first find out that the changes are needed.

有时，外部系统会以需要对系统进行其他更改的方式进行更改。这些更改可能很难合并，也可能不难合并，但是您必须首先确定是否需要更改。

Without a compiler checking for interface compliance, you may not find whether an interface has changed in a dramatic way. A typed system does help a lot with detecting and managing change.

如果没有编译器检查接口的符合性，您可能找不到接口是否发生了戏剧性的变化。类型化的系统确实有助于检测和管理变更。

On the other hand, sometimes interface changes are subtle — maybe the function now takes meters instead of yards — which a typed system may not catch. A wise interface designer, if he/she must make subtle interface changes, will surface the changes in a big way so consumers don’t miss the subtle changes. In the units-change scenario stated above, perhaps the package developer changes the name of the function to force a big break instead of a minor break. However, in this scenario, backward-compatibility is more likely to be a proper approach, supporting both units without forcing changes for existing consumers.

另一方面，有时接口的更改很细微-也许函数现在需要米而不是码-类型化的系统可能无法捕获。明智的界面设计人员如果必须对界面进行细微的更改，将在很大程度上显示出这些更改，以使消费者不要错过这些细微的更改。在上述单位变更的情况下，程序包开发人员可能会更改函数的名称以强制较大的中断而不是较小的中断。但是，在这种情况下，向后兼容更可能是一种适当的方法，在不强制更改现有使用者的情况下支持两个部门。

角组件 (Angular Components)

Angular projects, ever since 2.0, use TypeScript. If you want to call one of your services, import a function, use a type, then the experience is great: Intellisense tells you how to use it, and TypeScript makes sure you’re using it right and continue using it right after upgrades.

从2.0开始，Angular项目就使用TypeScript。如果您要调用您的一项服务，导入一个函数，使用一种类型，那么体验就很棒：Intellisense会告诉您如何使用它，而TypeScript确保您使用正确，并在升级后立即继续使用。

When you need something injected, TypeScript and Angular DI scrape it together and plug it into your constructor. This is an awesome feature of Angular.

当需要注入某些东西时，TypeScript和Angular DI会将它们刮擦在一起，然后将其插入构造函数中。这是Angular的一个很棒的功能。

But not components. (At least, not by default: see the corrections section above)

但不是组件。 (至少不是默认情况下：请参见上面的更正部分)

Components are how you build UI, which is the whole point of the framework. Each component is a contained system with inputs and outputs for other components to contain.

组件是构建UI的方式，这是框架的重点。每个组件都是一个包含所有组件输入和输出的系统。

Unfortunately, the only way 2 components “touch” is not through TypeScript, but a partial HTML file managed by the Angular compiler. This means the interface between components goes without type checking.

不幸的是，两个组件“接触”的唯一方法不是通过TypeScript，而是通过Angular编译器管理的部分HTML文件。这意味着组件之间的接口无需进行类型检查 。

That’s the fatal flaw: no Intellisense, compliance checks, or change management for the bread-and-butter of Angular. But it gets worse.

那是致命的缺陷：没有Intellisense，合规性检查或Angular的变更管理。但情况变得更糟。

我的经验 (My Experience)

This Angular app was built by a separate team and handed over to me. It was a reporting app with reports you could run and visualize the results. Each report had a “report id”, which was a number. Except when you ran in Dashboard view, where the same components passed strings. But you couldn’t tell upon reading the code, because TypeScript swore it was one and not the other. This app was not type-consistent, which means the code lies to you.

这个Angular应用程序是由一个单独的团队构建的，并移交给了我。这是一个报表应用程序，其中包含您可以运行并可视化结果的报表。每个报告都有一个“报告ID”，它是一个数字。除非您在仪表板视图中运行，否则相同的组件将传递字符串。但是您无法在阅读代码时就知道了，因为TypeScript发誓这是一个，而不是另一个。 此应用程序的类型不一致，这意味着代码对您不利。

Because this mismatch was not resolved early in the project, the subcomponents did various “fixes” to force it to work in both the Visualization and Dashboard views. I tried to fix the underlying issue by converting to strings early on, but then the “report id” to “report object” Map would have fatal misses because some components were doing cache gets by string and others by number. The fix for some components was not trivial, so it didn’t happen.

由于这种不匹配在项目早期并未得到解决，因此子组件进行了各种“修复”，以强制其在“可视化”视图和“仪表板”视图中工作。我试图通过尽早转换为字符串来解决潜在的问题，但是随后，“报告ID”到“报告对象”的Map会发生致命错误，因为某些组件正在通过string进行缓存获取，而其他组件则通过number 。某些组件的修复并非易事，因此没有发生。

Here’s a very quick example app on StackBlitz. See the “number” at the top right? See how the top-bar component’s TypeScript annotation says its a string? This is not prevented by default.

这是StackBlitz上一个非常快速的示例应用程序。看到右上方的“数字”吗？看看顶部栏组件的TypeScript注释如何说出它的字符串？默认情况下不会阻止此操作。

Ultimately, this was a symptom of a deeper problem: a lack of discipline in the original engineers. This reared its ugly head in an unclear component model, which is where this particular issue is derived. I can only hope an opt-out-of-strictness approach would have guided them back to the beaten path.

最终，这是一个更深层次问题的征兆：原始工程师缺乏纪律。这在一个不清楚的组件模型中抬起了丑陋的头，正是这个模型派生了这个特定问题。我只能希望选择退出限制的方法将引导他们回到人迹罕至的地方。

For comparison, consider React. Whatever you may think of JSX, the interface between components happens in your code files, meaning TypeScript interfaces are preserved. This means you can absorb and follow interfaces as a consumer of a component and enforce interfaces as a provider, building a layer of trust that solves the fundamental problem of software engineering: trust.

为了进行比较，请考虑React。无论您如何看待JSX，组件之间的接口都在代码文件中发生，这意味着TypeScript接口得以保留。这意味着您可以作为组件的使用者来吸收和遵循接口，并作为提供者来强制执行接口，从而建立可以解决软件工程根本问题的信任层：信任。

Even without TypeScript, React has a culture around using PropTypes to do checks at runtime (by “culture”, I mean it is a prominently promoted feature of the library, showing up in big ways in tutorials). Even LitElement has code around runtime converters and type hints for using components.

即使没有TypeScript，React也具有使用PropTypes在运行时进行检查的文化(通过“文化”，我的意思是它是该库的一个显着提升的功能，在教程中以很大的方式显示出来)。甚至LitElement都有关于运行时转换器的代码，并提供了使用组件的类型提示。

With Angular, it’s just another flag you might forget to set. One more take-away from my experience: when strictness is opt-in, the people who should opt-in, don’t.

使用Angular，这只是您可能会忘记设置的另一个标志。从我的经验中可以得出的另一点是：选择严格时，应该选择加入的人就不要。

Or, more generically: frameworks that rely on discipline (opt-in strictness) forgo trust. You can’t trust engineers to do it right at the start of a project unless guided by default. If they want to opt-out, then at least they consciously recognize the problem earlier, and then maybe my bad hand-me-down-Angular experience won’t be repeated.

或者更笼统地说： 依赖纪律(选择严格)的框架放弃信任 。除非默认情况下指导，否则您不能信任工程师在项目开始时就立即这样做。如果他们想退出，那么至少他们有意识地更早地意识到了这个问题，然后也许我不会重复我糟糕的亲身经历的角度体验。

Lying code makes your code harder to read. Broken interfaces mean the barriers between components have fallen, which means you have to read more components. Remember how reading is the hardest part of software engineering? It just got 10x worse.

说谎的代码使您的代码更难阅读。中断的接口意味着组件之间的障碍已经降低，这意味着您必须阅读更多的组件。还记得阅读是软件工程中最难的部分吗？ 更糟了10倍 。

Congratulations, a huge can of worms waiting to be spilled right into the heart of any Angular project you see.

恭喜，一大批蠕虫正等着您涌入您所看到的任何Angular项目的心脏。