构建meteor应用程序_高效设计和构建应用程序的13个技巧

构建meteor应用程序

I've been thinking a lot lately about all the small utility apps I've programmed over the years and how I could have designed them better.

最近，我一直在思考我多年来编写的所有小型实用程序应用程序以及如何更好地设计它们。

I loosely define a utility as any project designed to solve a singular and specific problem for a certain situation or business process.

我将实用程序广义地定义为旨在解决特定情况或业务流程的单个和特定问题的任何项目。

For example, I built a small PHP application that accepts an export from an ecommerce store and parses the data into another format needed for a specific business process.

例如，我构建了一个小型PHP应用程序，该应用程序接受电子商务商店的导出并将数据解析为特定业务流程所需的另一种格式。

我如何更好地设计这些？ (How could I design these better?)

I normally build a utility by having an idea of a problem to solve, and I jump right in to an editor and start typing.

通常，我会通过解决问题的想法来构建实用程序，然后立即进入编辑器并开始输入内容。

Some time later, I find myself wanting to steal functionality from old utilities, but when I go to reuse some code, I find out how badly I programmed the thing! Generally I don't spend a lot of time on small utilities, so they are programmed without classes, namespaces, or even OOP. Procedural FTW!

一段时间后，我发现自己想从旧的实用程序中窃取功能，但是当我去重用一些代码时，我发现自己编写该程序有多糟糕！ 通常，我在小型实用程序上不会花费很多时间，因此对它们进行编程时无需使用类，名称空间甚至OOP。 程序性FTW！

It's made me think that I should be more organized, even in tiny projects.

我认为即使在很小的项目中，我也应该更有条理。

Here are some issues I now consider before starting any new project.

在开始任何新项目之前，我现在考虑一些问题。

1)基本要求！ (1) The basics are required!)

Regardless of how tiny the utility is, practice good programming! Use proper source formatting, naming conventions and commenting. Another developer should be able to see what's going on in the code with little effort.

无论实用程序有多小，都请练习良好的编程 ！ 使用正确的源格式，命名约定和注释。 另一个开发人员应该能够轻松地查看代码中正在发生的事情。

Avoid procedural coding where possible.

尽可能避免过程编码。

I no longer allow myself to write sloppy code, even if the project is tiny or of limited use.

即使项目很小或用途有限，我也不再允许自己编写草率的代码。

2)定义项目 (2) Define the project)

It doesn't matter if the utility has a single function to perform: it should be well defined before coding begins. The definition of the app will include basic declarations, like who will use it, what data it will expect, and what output it's supposed to give.

实用程序是否具有单个功能即可执行： 在编码开始之前应明确定义它。 该应用程序的定义将包括基本声明，例如谁将使用它，它将期望什么数据以及应提供的输出。

Define data sources, security concerns, and whether the app will grow with more functions over time.

定义数据源，安全问题，以及随着时间的流逝，应用程序是否会随着更多功能的增长而增长。

Where will the utility be hosted?

该实用程序将在哪里托管？

The more detailed the definition, the easier it is to pick tools and stay in scope while programming it. This is especially true if you're programming for someone else!

定义越详细，编程时就越容易选择工具并保持范围。 如果您正在为其他人编程，尤其如此！

3)其他人会努力吗？ (3) Will others work on it?)

If other programmers will be involved, increase your documentation and commenting. Use source control, and focus on separation of concerns in your classes and methods.

如果需要其他程序员参与，请增加文档和注释。 使用源代码控制，并专注于类和方法中关注点的分离。

If no programmer will ever need to read your code or work on it except you, keep to the basics and don't overwhelm yourself. Just make sure you can still make sense of it!

如果除您之外没有程序员需要阅读您的代码或对其进行处理，请坚持基础知识，不要淹没自己。 只要确保您仍然可以理解它！

4)源代码控制？ (4) Source control?)

Depending on the context of the utility—such as if it is an internal project for an organization that will own the work—the code may be hosted in a public repository. If so, increase documentation; add a readme.md file; add DocBlocks to define ownership of the code, and use Semantic Versioning.

根据实用程序的上下文(例如，如果它是拥有该工作的组织的内部项目)，则代码可以托管在公共存储库中。 如果是这样，增加文档； 添加一个readme.md文件； 添加DocBlocks来定义代码所有权，并使用Semantic Versioning 。

If there are concerns about intellectual rights and who owns the code, this would require you to throw a license in there.

如果您对知识产权以及代码的所有者感到担忧，这将要求您在其中扔许可证 。

5)我需要长期维护吗？ (5) Do I have to maintain it for the long haul?)

If you foresee future development, assume that others will work on the app, and that it therefore needs source control, improved documentation, and a license attached.

如果您预见到未来的发展，请假定其他人可以在该应用程序上工作，因此需要源代码控制 ，改进的文档以及随附的许可证 。

You may not be the person to maintain future versions if the app is internal to an organization. It's better to spend the extra time on these chores than for future programmers to dismiss you as a poor programmer.

如果应用程序是组织内部的，则您可能不是维护将来版本的人。 花费额外的时间在这些琐事上要比将来的程序员将您视为一个可怜的程序员更好。

If you write well-documented code, you may be able to come back later for a letter of recommendation. (You can't take company-owned code with you, but at least you'll have a letter confirming all your work was good!)

如果您编写了有据可查的代码，则稍后可以再次提出推荐信。 (您不能随身携带公司拥有的代码，但是至少您会收到一封确认所有工作都很好的信！)

6)我应该创建API，库还是不创建？ (6) Should I create an API, library, or neither?)

It's beyond the scope of this article to define APIs and libraries, but it's still a significant decision to make, because it will change the entire methodology of your coding.

定义API和库超出了本文的讨论范围，但仍然是一个重要的决定，因为它将改变整个编码方法。

Will the tool be standalone, or will you distribute it as a library, or do you want to allow others to access the functionality through an API interface?

该工具是独立的 ，还是将其作为库分发，还是要允许其他人通过API接口访问该功能？

If you go the API route, you'll want robust handling of all inputs and outputs, data validation, data conversion, security, HTTP routing, endpoints and so on. Encryption and authentication become a concern too.

如果您使用API​​路由，则需要对所有输入和输出，数据验证，数据转换，安全性，HTTP路由，端点等进行强大的处理。 加密和身份验证也成为一个问题。

7)CMF，后端，配置？ (7) CMF, backend, configuration?)

Does the utility itself require its own management interface, separate from the front-end context?

该实用程序本身是否需要与前端上下文分开的自己的管理界面？

Do you need a back end as a means of providing access for an administrator to control the utility?

您是否需要后端作为向管理员提供访问权限以控制该实用程序的方式？

The biggest problem is that any content management framework (CMF) is likely to give you a lot of bloat and features you don't need just to run a little utility. But then again, the CMF is likely to give you its own API and helper tools, which may come in handy.

最大的问题是，任何内容管理框架(CMF)都可能给您带来很多膨胀，而您只需要运行一些实用程序就不需要这些功能。 但话又说回来，CMF可能会为您提供自己的API和帮助程序工具，它​​们可能会派上用场。

Alternatively, you can store all configuration information in a single file that only admins have access to.

或者，您可以将所有配置信息存储在一个只有管理员有权访问的文件中。

In most cases, I just create a config.php file and place all the config data in there and edit manually without an interface.

在大多数情况下，我只是创建一个config.php文件并将所有配置数据放在其中，然后在没有界面的情况下手动进行编辑。

8)包管理？ (8) Package management?)

Package management is the cool kid, but that doesn't mean we need to hang out and be friends!

包裹管理是一个很酷的孩子，但这并不意味着我们需要出去玩并成为朋友！

It's easy to include a few libraries without using package management.

不使用包管理就可以轻松包含一些库。

I have only found myself using it when I need more than two or three modules, or if those modules are complex.

我只在需要两个或三个以上模块，或者这些模块很复杂时才使用它。

If you choose to use Composer modules (for PHP), then I also suggest building your utility within the rules of Composer so that your project itself can be managed via Composer. Use the PSR-4 spec, folder names, and naming conventions for classes and so forth.

如果您选择使用Composer模块(用于PHP)，那么我还建议您在Composer的规则内构建实用程序，以便可以通过Composer管理项目本身 。 使用PSR-4规范 ，文件夹名称和类的命名约定等。

9)前端框架？ (9) Front-end Framework?)

A complex front end might arise where the user is meant to perform many steps, upload files, fill out forms, review data, visualize data, etc. As the front end becomes more complex, you may consider using a front-end framework.

复杂的前端可能会出现，用户需要执行许多步骤，上传文件，填写表单，查看数据，可视化数据等。随着前端变得越来越复杂，您可以考虑使用前端框架。

By framework I really just mean a CSS framework like Bootstrap, Foundation, or even something bigger that includes more visual modules and JavaScript widgets, such as jQuery or others.

我所说的框架实际上就是一个CSS框架，例如Bootstrap，Foundation，甚至更大的东西，包括更多的可视模块和JavaScript小部件，例如jQuery或其他。

I usually find myself writing all CSS from scratch, but if the project grows too big, I'll do a rewrite on Foundation perhaps.

我通常会发现自己从头开始编写所有CSS，但是如果项目太大，我可能会在Foundation上进行重写。

10)我需要记录吗？ (10) Do I need logging?)

Will you require any kind of historical record of the actions taken by the utility? Will you need an audit trail of who did what, when, from where, and for how long?

您需要该实用程序采取的任何形式的历史记录吗？ 您是否需要对谁在何时，何地，从何处以及做了多长时间进行了审计的跟踪记录？

Again, if we're in a corporate environment and the utility is meant to be used by multiple people, a log may be necessary for tracking.

同样，如果我们在公司环境中，并且该实用程序打算供多人使用，则可能需要使用日志来进行跟踪。

Good logging libraries are available in package managers, so if needed, that could be a reason to use package management.

程序包管理器中提供了良好的日志记录库，因此，如果需要，这可能是使用程序包管理的原因。

11)我需要加强错误处理吗？ (11) Do I need hardened error handling?)

Most of the time I create utilities with no thought for error handling. I tend to program with all errors shown, and once everything works and there are no errors in my testing, I turn off showing errors at all.

大多数时候，我创建实用程序时不会考虑错误处理。 我倾向于编写显示所有错误的程序，一旦一切正常，并且测试中没有错误，我将关闭显示所有错误的功能。

You should think about whether you need complex error handling, front-end messages, undo features, back-button management, autosave versus save button, popups and modal windows, and whether this will be tied in to a logging system.

您应该考虑是否需要复杂的错误处理，前端消息， 撤消功能，后退按钮管理，自动保存与保存按钮，弹出窗口和模式窗口，以及是否将它们绑定到日志记录系统中。

Note that logging, auditing, error managing should be part of the early specifications. This should help you decide about using package management and frameworks right from the start.

请注意，日志记录，审核，错误管理应该是早期规范的一部分。 这应该可以帮助您从一开始就决定使用软件包管理和框架。

12)我需要额外的安全性吗？ (12) Do I need extra security?)

If your utility performs destructive data management or needs user authentication, then extra security is a no-brainer.

如果您的实用程序执行破坏性数据管理或需要用户身份验证，那么额外的安全性将是显而易见的。

I tend to think, as soon as you need robust security, then use a framework with these features built in. You can use a framework with no management interface like Laravel, Kohana, Slim, Silex, and many others. Or use a framework with an interface like MODX, ProcessWire, or Bolt. Just make sure the framework has the features you need.

我倾向于认为，一旦需要强大的安全性，就可以使用内置这些功能的框架。可以使用没有管理界面的框架，例如Laravel，Kohana，Slim，Silex等。 或使用具有MODX，ProcessWire或Bolt之类的接口的框架。 只要确保框架具有所需的功能即可。

Reinventing the wheel is just not necessary. Don't write your own logging, security, user auth, database abstraction, etc. Just use a framework at that point.

根本不需要重新发明轮子。 不要编写您自己的日志记录，安全性，用户身份验证，数据库抽象等。只需在此时使用框架即可。

13)它面向公众吗？ (13) Is it public-facing?)

One big question to ask is whether the tool is only to be used internally, or if you'll allow access from the general web. If the former, is it still open internally to an organization where dozens or hundreds of people will have a crack at it?

要问的一个大问题是该工具是否仅在内部使用，或者是否允许从一般网络访问。 如果是前者，它是否仍在内部对一个组织开放，在这个组织中数十或数百人会对此产生裂缝？

You'll have to make sure your endpoints are well defined, and that you protect any auxiliary files and scripts as needed.

您必须确保端点定义正确，并根据需要保护所有辅助文件和脚本。

If you suspect high traffic, then you're talking caching mechanisms, especially where databases or highly dynamic data is generated. We're also talking security, logging, auth, and so on.

如果您怀疑流量很高，那么您就在谈论缓存机制，尤其是在生成数据库或高度动态数据的地方。 我们还讨论安全性，日志记录，身份验证等。

I would say, as a general rule, if you are creating a small utility to provide to the planet-at-large, use all common libraries, tools, methods, documentation, and even a framework.

通常，如果要创建一个小的实用程序以提供给整个星球，我会说，请使用所有常见的库，工具，方法，文档，甚至是一个框架。

Don't mess around when it comes to handing out public access: all bets are off, so just do everything by the books with modern, well-tested modules and frameworks!

分发公共访问权限时不要乱扔：所有赌注都没有，所以只要使用经过现代测试的模块和框架来完成所有工作即可！

你呢？ (How about you?)

These are some of the things I think about before I pop open Sublime or Netbeans to start a project.

在我打开Sublime或Netbeans启动项目之前，我会考虑以下这些事情。

Maybe you already have a set of common tools you use for utility apps? I'd love to know what those are, because large frameworks like Laravel or full CMF/CMSes may be overkill for utilities. Do you have some smaller micro frameworks that have just enough features to get a utility done quickly?

也许您已经有了用于公用程序应用程序的一组常用工具？ 我很想知道它们是什么，因为Laravel或完整的CMF / CMS之类的大型框架可能对实用程序来说是多余的。 您是否有一些较小的微框架，这些框架只有足够的功能来快速完成实用程序？

翻译自: https://www.sitepoint.com/13-tips-on-designing-and-building-apps-more-efficiently/

构建meteor应用程序