体检系统前端源码

by Ewa Mitulska-Wójcik

伊娃·米图尔斯卡(EwaMitulska-Wójcik)

给您的前端进行健康检查 (Give your Front End a Health Check)

You’ve built out all your user stories and your app is working. Now’s it’s ready to submit as done, so you can move on with your life.

您已经建立了所有用户案例，并且您的应用正在运行。 现在可以完成提交了，因此您可以继续生活。

Not so fast!

没那么快！

You need to give your code a health check first.

您需要先对您的代码进行健康检查。

A professional singer wouldn’t start singing until she’s checked both her mic and her speakers. You shouldn’t deploy until you’ve checked your front end, back end, and everything in between.

一位专业歌手只有在检查完麦克风和扬声器后才能开始唱歌。 在检查完前端，后端以及介于两者之间的所有内容之前，请勿部署。

I’m an impatient person, but coding makes me slow down. Being a developer teaches me to think at least twice, ask questions until the code works, and wait a moment before celebrating success.

我是一个不耐烦的人，但是编码会使我慢下来。 作为一名开发人员，教会我至少要三思而后行，提出问题，直到代码生效，然后稍等片刻，庆祝成功。

Iteration is the key because good product is never done. The key is to iterate on the versions you are proud of, and not on those that are far from ready to go live.

迭代是关键，因为永远不会完成优质的产品。 关键是迭代您引以为傲的版本，而不是迭代尚不可行的版本。

So treat this as a final checklist before going live.

因此，在上线之前将其作为最终检查清单。

1.ReactSwift (1. Be responsive)

How does your app behave when you resize the browser window? Where do you have your breakpoints in code? Is it fluid enough to fit all sizes without bigger problems?

调整浏览器窗口大小时，应用程序的行为如何？ 您的代码断点在哪里？ 它是否具有足够的流动性以适合所有尺寸而没有更大的问题？

There are an endless variety of screen sizes. It’s impossible to have all of the devices within reach but, it’s easy to emulate their behavior.

屏幕尺寸不尽相同。 不可能将所有设备都伸手可及，但是很容易模拟它们的行为。

Spending some time in Code Review Room, I’ve noticed that many people focus on developing for desktops when they should actually be testing their app on mobile devices first.

我花了一些时间在Code Review Room中 ，我注意到许多人实际上应该首先在移动设备上测试其应用程序时专注于为台式机开发。

Browser tools allow us to emulate the display on various screen sizes and orientations. Use them, they are free.

浏览器工具使我们可以在各种屏幕尺寸和方向上模拟显示。 使用它们，它们是免费的。

In Chrome, you can go to a debug view by right clicking any element on the page and selecting “inspect element”, then going to mobile view and emulating different devices.

在Chrome浏览器中，您可以通过以下方式进入调试视图：右键单击页面上的任何元素，然后选择“检查元素”，然后进入移动视图并模拟不同的设备。

2.考虑特殊情况和应用状态 (2. Consider special cases and app states)

Empty, error, success, waiting, 404 page, or duplicated button clicks while waiting for API response — how does your app react to them? Do you care about these states that are far from ideal situation you coded for? Do you have helpful feedback to your users for when they encounter these? Have you tested for these special cases? Do you listen and respond in your app, or do you do all the talking?

在等待API响应时出现空白，错误，成功，正在等待，404页或重复的按钮单击-您的应用如何对此做出React？ 您是否关心这些与您编写的理想情况相去甚远的状态？ 您的用户在遇到这些问题时是否有有用的反馈？ 您是否针对这些特殊情况进行了测试？ 您是在应用程式中聆听和回应，还是所有谈话内容？

Design, code, and test for all states. Checking user flows can help you a lot to get rid of these easily forsaken points and dead ends. Simply test your work with some users, or at least do it on your own.

设计，编码和测试所有状态 。 检查用户流可以极大地帮助您摆脱这些容易遗忘的问题和死胡同。 只需与某些用户一起测试您的工作，或者至少自己完成。

Put yourself in users’ shoes by imagining various scenarios that may happen, and remember that this app is completely new for this person.

通过想象可能发生的各种情况，让自己陷入困境，并记住此应用对于该人而言是全新的。

Try incorrect data inputs, no input at all, misspellings, etc. Be imaginative and try to break your code! Better you do it before your users.

尝试输入错误的数据，根本不输入任何内容，拼写错误等。请发挥想象力，并尝试破坏代码！ 最好您先于用户。

3.优化您的表现 (3. Optimize your performance)

Google PageSpeed Insights does a great job in telling you what could be done better.

Google PageSpeed Insights在告诉您可以做得更好的方面做得很好。

If you want others to be able to read and review your code, don’t minify your JavaScript or CSS — it will make it hard for humans to read. However, you should do it for production code.

如果您希望其他人能够阅读和查看您的代码，请不要缩小您JavaScript或CSS，这将使人类难以阅读。 但是，您应该为生产代码执行此操作。

For production, you can also use tools such as Grunt to handle and other operations optimizations for you.

对于生产，您还可以使用诸如Grunt之类的工具为您进行处理和其他操作优化。

By using the tests such as PageSpeed, you can get quick opinion not only on performance, but also on usability issues. Test results provide you with ready suggestions for how to improve your code. Again, you don’t have to accept all, simply choose the suggestions that work for the goals you want to achieve.

通过使用诸如PageSpeed的测试，您不仅可以快速获得性能方面的意见，还可以快速获得可用性方面的意见。 测试结果为您提供了有关如何改进代码的现成建议。 同样，您不必全部接受，只需选择适合您要实现的目标的建议即可。

4.在所有可用的设备上进行跨浏览器测试 (4. Do cross browser testing on every device you have available)

Many of us have access to at least two different devices (a computer and a smartphone), and some of us even dual boot different operating systems. Browser emulation has its flaws, so when possible use the native hardware.

我们中的许多人至少可以使用两种不同的设备(一台计算机和一部智能手机)，甚至有些人甚至可以双重引导不同的操作系统。 浏览器仿真有其缺陷，因此请尽可能使用本机硬件。

You don’t have to write unit tests for a small app showing wiki entries or local weather to check if they work. Test driven development is a great practice, but not the easiest for fresh coders and it may be an excess of form for short code snippets.

您无需为显示Wiki条目或当地天气的小型应用编写单元测试，即可检查它们是否有效。 测试驱动的开发是一种很好的做法，但对于新手来说并不是最容易的事情，对于简短的代码片段而言，这可能是多余的形式。

What you have to be aware of though is that testing is a part of front end developer’s job, even if there’s a huge team of testers sitting next to you in the same room. Before you assign the ticket to other team member you have to make sure it works. Don’t assume, check.

不过，您需要知道的是，即使在同一个房间中有大量测试人员坐在您旁边，测试也是前端开发人员工作的一部分。 在将票证分配给其他团队成员之前，必须确保票证有效。 不要假设，检查。

With code, it either works or it doesn’t. There’s no maybe or I suppose.

使用代码，它要么起作用要么不起作用。 也许没有，或者我想 。

Cross browser testing can be time-consuming, but there are plenty of tricks to make it more efficient. For instance, each time you test, try using a different browser.

跨浏览器测试可能很耗时，但是有很多技巧可以使其更加高效。 例如，每次测试时，请尝试使用其他浏览器。

Since you test it while iterating over the project, you can test your code on various browsers many times during the creation of the app itself. Then, before launching the final version it’s much faster to make a quick browser health check, since majority of problems have probably already been discovered and fixed.

由于在迭代项目时对其进行了测试，因此您可以在创建应用程序本身的过程中多次在各种浏览器上测试代码。 然后，在启动最终版本之前，进行快速浏览器运行状况检查要快得多，因为大多数问题可能已经发现并解决了。

Browser developer tools and extensions allow you also to easily discover accessibility constraints before you push the project live. You can also use BrowserStack, which I’ve found helpful in doing cross-browser testing.

浏览器开发人员工具和扩展程序还使您可以轻松发现可访问性约束 在您继续进行项目之前。 您还可以使用BrowserStack ，我发现它对进行跨浏览器测试很有帮助。

I recently a nice accessibility checklist. If you want to dig deeper in the topic you may also like to check your apps with ARIA techniques, articles on designing for keyboard, or look through Simply Accessible archives.

我最近有一个很好的辅助功能清单 。 如果您想深入了解该主题，您可能还希望使用ARIA技术检查您的应用程序，有关键盘设计的文章，或者浏览Simply Accessible档案 。

5.保持警惕 (5. Keep your head on)

Double check the head section of your HTML, and make sure you have meta descriptions, a viewport set up for mobile, a title tag, and a favicon. Keep at least the basic meta tags, such as description and author. SEO rules change quickly, but an informative description can increase your likelihood of being clicked on a crowded search result page.

仔细检查HTML的头部，并确保您具有元描述，为移动设备设置的视口，标题标签和图标。 至少保留基本的元标记，例如描述和作者。 SEO规则变化很快，但是内容丰富的描述可能会增加您在拥挤的搜索结果页面上被点击的可能性。

If you’re serious about sharing your work, make it easy for others to collaborate. Keep your README.md file concise and explanatory. It’s how most people will view your project on GitHub, so don’t omit this file in your repo.

如果您认真对待共享工作，请让其他人轻松进行协作。 保持README.md文件简洁明了。 这是大多数人在GitHub上查看您的项目的方式，因此不要在您的存储库中忽略此文件。

If you code some small projects on CodePen, go to settings section and add a basic description of your pen and tags. This will allow your work to be easier discovered and understood by others.

如果您在CodePen上编写一些小项目，请转到“设置”部分，并添加笔和标签的基本描述。 这将使您的工作更容易被他人发现和理解。

Make sure you import assets and libraries appropriately. If you want to move your project from CodePen to another server, make sure that the external libraries, frameworks, and stylesheets you used in your pen are included.

确保正确导入资产和库。 如果要将项目从CodePen移到另一台服务器，请确保包含您在笔中使用的外部库，框架和样式表。

If you want just a copy for your Github and it’s a small project, you can simply export your pen to gist. To do this, use the export button in the bottom-right corner of Editor View.

如果您只想要Github的副本，并且这是一个小项目，则只需将笔导出到要点即可。 为此，请使用编辑器视图右下角的导出按钮。

6.代码优化 (6. Code optimization)

Keep DRY (don’t repeat yourself). Once done, have a look at the code once again. Maybe there are snippets which you repeat and they could be replaced by one smart function. Analyze your code once again and look what could be written better. The more you code, the wiser in DRY you become. It’s said to be a good learning code practice to come back to your own code after some time and refactor it. Give it a try.

保持干燥(不要重复自己)。 完成后，再次查看代码。 也许有您重复的代码片段，可以用一个智能功能代替它们。 再次分析您的代码，看看可以写得更好的代码。 您编写的代码越多，则在DRY中变得越明智。 据说这是一种很好的学习代码实践，可以在一段时间后返回到自己的代码并对其进行重构。 试试看。

Before finishing the project clean your toys.

在完成项目之前，请清洁玩具 。

All console logs are useful for debugging during creation but unwelcome for production code.

所有控制台日志都可用于创建期间的调试，但不适用于生产代码。

Make comments concise and clear for others reading your code, and preferably in English, unless everyone else on your team speaks the same language.

除非您团队中的其他每个人都讲相同的语言，否则其他人阅读您的代码(最好使用英语)时要使注释简洁明了。

Make sure there aren’t any console errors, and that all your assets load properly (for that check Network tab in your browser’s developer tools).

确保没有任何控制台错误，并且所有资产均正确加载(为此，请检查浏览器开发人员工具中的“网络”标签)。

You may want to use code validators for JavaScript, HTML, and CSS. Like with PageSpeed the key is to understand what is worth optimizing.

您可能需要对JavaScript ， HTML和CSS使用代码验证器。 与PageSpeed一样，关键是要了解值得优化的内容。

7.用户体验 (7. User Experience)

Quick UX health check of your project should include the basics like:

项目的快速UX运行状况检查应包括如下基本知识：

• Goals. Are the users able to solve their problems? Are their expectations met? Do they get what they came for to your app/website? What would a user tell the app is about seeing it just for a moment?

  目标 。 用户能够解决他们的问题吗？ 他们的期望达到了吗？ 他们得到他们想要的东西到您的应用程序/网站吗？ 用户会告诉应用程序有关仅一会儿看到它的信息？

• Dead-ends. Have you checked all possible paths your users can take? Are you helpful? Do you provide feedback just in time a user needs it?

  死胡同 。 您是否检查了用户可以采用的所有可能路径？ 你有帮助吗？ 您是否及时提供用户需要的反馈？

• Visual hierarchy. Is the hierarchy kept? Do you lead users eye? Is your call-to-action visible? Do you have too many items to focus on that fight for being the primary element on a given screen?

  视觉层次 。 是否保留了层次结构？ 您会引起用户的注意吗？ 可以看到号召性用语吗？ 作为给定屏幕上的主要元素，您是否有太多项目需要关注呢？

• Line width. Is your text easy to scan? Your lines should be no wider than 80 characters. And make sure your lines aren’t too narrow with too much padding.

  行宽。 您的文字容易阅读吗？ 您的行不得超过80个字符。 并确保您的行没有太宽，没有太多的填充。

• Readability. Is your text readable? Are the images of the right size? Is there contrast between elements appropriate?

  可读性。 您的文字可读吗？ 图像尺寸合适吗？ 元素之间是否有适当的对比 ？

• Affordability. Do your buttons look like buttons? Do your links behave like links? Will a user know that an element is clickable or tappable? Does your cursor turn into a finger pointer where appropriate?

  负担能力。 您的按钮看起来像按钮吗？ 您的链接的行为就像链接吗？ 用户是否知道元素是可点击的还是可点击的？ 光标是否在适当的地方变成了指针？

• Consistency. Are you consistent in your app? Or do you use 5 different colors to mark the same thing or do you have it organized?

  一致性。 您是否在应用程序中保持一致？ 还是您使用5种不同的颜色标记同一件事？还是将其组织起来？

• Microinteractions. Do you help your users to notice when the elements are hovered in desktop view? How do you mark interactions? Do you respond to what a user does in your app?

  微相互作用 。 您是否帮助用户注意到元素在桌面视图中何时悬停？ 您如何标记互动？ 您是否回应用户在您的应用程序中所做的事情？

• Sunlight check. How does your app behave outside in sunlight? Is everything readable?

  阳光检查。 您的应用在阳光下在室外的表现如何？ 一切可读吗？

• Screenreader test. Have you tried using your app with a screenreader? Is it possible to use it fully being directed just with Voice Over or another screenreader tool?

  屏幕阅读器测试。 您是否尝试通过屏幕阅读器使用您的应用？ 是否可以仅通过Voice Over或其他屏幕阅读器工具直接使用它？

• Proof-read your copy. Have you got rid of lorem ipsum texts? Are your alerts, warnings, etc. written in a human language, or do they still read like a developer in a hurry wrote them?

  校对您的副本。 您摆脱了lorem ipsum文本吗？ 您的警报，警告等是以人类语言编写的，还是仍然像开发人员急忙阅读的那样阅读？

8.关于Gitter的代码审查 (8. Code Review on Gitter)

When you are ready with the previous points go to the Code Review room. Campers are lucky to belong to the community where everybody understands that you are fresh in coding. It’s OK if you make mistakes. We all learn by practicing, and gradually improve our code.

当您准备好了前面的几点后，请转到代码审查室 。 露营者很幸运能加入每个人都知道您在编码方面很新鲜的社区。 如果您犯错也可以。 我们都通过练习来学习，并逐步改进我们的代码。

Campers have various prior coding background, and are all at different points in Free Code Camp’s program. So finding help is quite easy.

露营者具有各种先前的编码背景，并且都在Free Code Camp的计划中处于不同的位置。 因此，寻求帮助非常容易。

Don’t ask too early. Ask for feedback later when your app has started to take on its own character and shape. Try to discover the answer first. Google and Stack Overflow are your first stops. Sure, if you get stuck with some problem jump in to the appropriate room and ask! That’s the part of Free Code Camp magic, isn’t it?

不要太早问。 当您的应用开始呈现自己的特征和形状时，请稍后再寻求反馈。 尝试先发现答案。 Google和Stack Overflow是您的第一站。 当然，如果您遇到一些问题，请跳到合适的房间询问！ 那是Free Code Camp魔术的一部分，不是吗？

Be precise about what you’re looking for. Asking precise questions leads you to better answers. Asking a general question like “Here’s my code. What do you think?” will get you a general answer. This can bring a lot of new ideas to light, and a fresh look that can be inspiring. However, a lot of design suggestions are pretty subjective (based on personal taste, and gut reaction after a few seconds), so don’t jump to the conclusion that you must refactor all your code just because one person said so. Ask for justification if you don’t understand what the other person meant. Repeat your question to get feedback from others, and sleep on the suggestions if you are not sure if the change is right for your project.

要精确地寻找你想要的 。 提出精确的问题可以使您获得更好的答案。 问一个类似“ 这是我的代码。 你怎么看？” 会给您一个一般性的答案。 这可以带来很多新的想法，并且可以激发灵感。 但是，许多设计建议都是非常主观的(基于个人品味和几秒钟后的肠道React)，因此不要得出一个结论，即您必须重构一个人的代码，因为一个人这样说。 如果您不了解对方的意思，请提出理由。 重复您的问题以获取其他人的反馈，如果不确定更改是否适合您的项目，请听取建议。

I love getting constructive feedback. It’s better to get a list of suggestions than bunch of praise. Kind words are sometimes needed, but informative comments full of empathy are better for making progress. As you progress, your motivation will become more intrinsic.

我喜欢获得建设性的反馈 。 获得建议列表总比赞美要好。 有时需要客气的话，但是充满同情心的翔实评论更能取得进步。 随着您的进步，您的动力将变得更加内在。

较大的项目，较短的列表 (Bigger projects, shorter lists)

Sitemaps, unit tests, functional tests, caching, analytics, appropriate file directories, checking if assets aren’t missing, print version css, SEO optimization… this list could go on for quite a while for sure.

站点地图，单元测试，功能测试，缓存，分析，适当的文件目录，检查资产是否不丢失，打印版本CSS，SEO优化……此列表可以肯定会持续很长时间。

But the more you code, the shorter the list seems to appear, because you will simply code better and internalize many of these considerations.

但是您编写的代码越多，列表出现的时间就越短，因为您可以简单地编写更好的代码并将这些考虑因素内部化。

I am a web developer in training. I am a Free Code Camper. I publish on Medium and tweet about UX and startups. I love useful solutions and friendly collaboration.

我是培训中的Web开发人员。 我是一名免费代码露营者 。 我在Medium和Twitter上发布了有关UX和创业公司的文章 。 我喜欢有用的解决方案和友好的协作。

翻译自: https://www.freecodecamp.org/news/give-your-front-end-a-health-check-952c857ecdb4/

体检系统前端源码