5种最佳实践心得

Every developers strives to write clean, maintainable, and functional code, whether they hack on the server side or dabble on the client side. Over the last few decades of the web, we've learned from some of our early mistakes and formed a site of always changing best practices. These best practices usually keep us out of trouble but some of them are taken way too literally, to the point where developers become too rigid and borderline crippled by them. Truth be told, with these best practices are mostly good to follow, they're broken not out complacency but by necessity. Here are five best practices that aren't quite as realistic as we'd like to think.

无论是在服务器端入侵还是在客户端涉猎，每个开发人员都努力编写干净，可维护且功能强大的代码。 在网络的最后几十年中，我们从一些早期的错误中吸取了教训，并形成了一个不断变化的最佳实践的站点。 这些最佳做法通常会使我们摆脱麻烦，但其中一些做法实在太过分了，以至于开发人员变得过于僵化并被它们所折磨。 实话实说，这些最佳实践在大多数情况下都是可以遵循的，它们并不是出于自满，而是出于必要。 这里有五种最佳实践，它们并不像我们想的那样现实。

“不要将全局变量添加到window ” ("Don't Add Globals to window")

JavaScript developers go to great lengths to encapsulate their code, like creating classes, closures, and modules. I agree with the mentality that you should avoid globals, but sometimes you simply have to. I recommend creating one global object named after the project name (Dojo Toolkit uses dojo and Groupon's Groupon object) and tagging properties on that. Creating an army of globals can get you into trouble but adding a few globals to window is just fine, if not unavoidable. As long as you know the environment your code will run in, you won't run into naming collision problems.

JavaScript开发人员竭尽全力封装他们的代码，例如创建类，闭包和模块。 我同意您应该避免使用全局变量的想法，但有时您只是必须这样做。 我建议创建一个以项目名称命名的全局对象(Dojo Toolkit使用dojo和Groupon的Groupon对象)，并在其上标记属性。 创建一支全球军队可能会给您带来麻烦，但是即使不是不可避免的，在window添加一些全球人员也很好。 只要知道您的代码将在其中运行的环境，您就不会遇到命名冲突问题。

“添加到本机原型是不好的” ("Adding to Native Prototypes is Bad")

The early JavaScript frameworks like Prototype and MooTools first gained popularity because they empowered native object prototypes. No longer did you write globally available functions to modify instances of String, Number, Array, Object, Function, etc -- you could pin methods on the prototype for each so that every existing and future instance had those methods; a total boost to productivity and code efficiency. Then after a few new naming collusions due to standard and proprietary web and browser API implementations, developers turned on the practice, to the point where the thought of adding a method to a native prototype meant you should turn in your developer credential badge.

诸如Prototype和MooTools之类的早期JavaScript框架首先受到欢迎，因为它们为本地对象原型提供了支持。 您不再编写全局可用的函数来修改String，Number，Array，Object，Function等的实例-您可以将方法固定在原型上，以便每个现有实例和将来的实例都具有这些方法； 全面提高生产力和代码效率。 然后，由于标准和专有的Web和浏览器API实施而引起了一些新的命名冲突之后，开发人员开始使用该做法，以至于想到向本机原型添加方法的想法意味着您应该上交开发人员凭据徽章。

Much with adding a global to the window, adding methods to a native object's prototype is fine done correctly. Name your new method properly (i.e. don't give your method a common name) and you'll be just fine. I'm not telling you to do this a lot, I'm simply saying that adding a method to a prototype isn't going to bring your career to a screeching halt.

正确地在window添加一个全局window ，向本地对象的原型添加方法就可以了。 正确命名您的新方法(即，不要给您的方法起通用名)，就可以了。 我并不是要告诉您要做很多事情 ，只是说在原型中添加方法不会使您的职业陷入停顿。

“从不使用UA嗅探” ("Never Use UA Sniffing")

User agent sniffing has gotten a rotten name because it was originally used to sniff features, and we know how badly that turned out. Believe it or not though, UA sniffing is still used by most large websites to detect mobile and then forward users to the mobile version of a site. And you know what? It's reliable and in the best interests of our users. I've been asked "What if the user spoofs the user agent?" My reply is "Then they get whichever site view that comes with it, so who cares? They've done this on purpose and if they get a dysfunctional site it's their problem." As long as you provide a link to the desktop version of the site, you'll be just fine.

用户代理嗅探之所以臭名昭著，是因为它最初是用来嗅探功能的，我们知道结果是多么糟糕。 信不信由你，大多数大型网站仍然使用UA嗅探来检测移动设备，然后将用户转发到该网站的移动版本。 你知道吗？ 这是可靠的，并且符合我们用户的最大利益。 我被问到“如果用户欺骗用户代理怎么办？” 我的回答是：“那么他们将获得随附的任何站点视图，那么谁在乎呢？他们是故意这样做的，如果站点功能不正常，这就是他们的问题。” 只要您提供该网站的桌面版本的链接，就可以了。

“可以从CDN加载[JavaScript库]，因为用户可能已经已经加载了它” ("It's OK to Load [JavaScript Library] From CDN Because the User will Likely Have Loaded it Already")

This one really burns me, especially after my trip to Brazil to promote Firefox OS. Yes, loading utilities from CDN is fast and, provided enough people use the CDN, there's a decent chance the user has the code cached, but it isn't that simple. Assuming a site has jQuery cached, for example, is risky because there are numerous versions and subversions and subsubversions being used at any given time. If the user doesn't have an unlimited data plan (which isn't offered in most countries), they could be paying quite a bit for each site that uses a JavaScript library or site which loads large files, CDN or not. When I went to Brazil, I would have to pay 20 cents for just jQuery if I went to a site using it. Long story short: assuming users don't pay a penalty for a CDN-hosted resource is a bad, bad mentality.

这真的让我很伤心，尤其是在我去巴西推广Firefox OS之后。 是的，从CDN加载实用程序速度很快，并且只要有足够的人使用CDN，用户就有很大的机会缓存了代码，但这并不是那么简单。 例如，假设一个站点缓存了jQuery是有风险的，因为在任何给定的时间都在使用大量的版本，子版本和子版本。 如果用户没有无限数据计划(在大多数国家/地区都未提供)，则他们可能会为每个使用JavaScript库的网站或加载大文件(不包含CDN)的网站支付大量费用。 当我去巴西时，如果我去使用jQuery的网站，我将不得不为jQuery支付20美分。 长话短说：假设用户不为CDN托管的资源支付任何罚款，这是一种糟糕的心态。

“像素完美是必须的” ("Pixel Perfection is a Must")

Quality designers and developers tend to be perfectionists, that's why they do well. We do, however, get caught up in pixel perfection when we translate from design to working page -- likely because pixel perfection is achievable. The problem in focusing on pixel perfection is that the obsession leads to a lot of time that isn't enhancing the user experience, it's enhancing our ego. Of course other designers and developers will come to the site and notice the odd width or height issue, but 90+% of users would prefer we make performing a given task easier, not ensuring each column measures precisely. Of course I'm not advocating you create "landmine" sites with pixels off everywhere, but sometimes you need to file a bug to fix later and keep making your site more usable, accessible, and fun!

质量设计师和开发人员往往是完美主义者，这就是为什么他们做得很好。 我们这样做，不过，拿在像素完美捕捉，当我们从设计转化为工作的页面-可能是因为像素完美是可以实现的。 专注于像素完美的问题在于，这种痴迷会导致很多时间并不能改善用户体验，反而会增强我们的自我意识。 当然，其他设计人员和开发人员也会来到该站点，注意到宽度或高度的奇数问题，但是90％以上的用户希望我们使执行给定的任务更加容易，而不是确保每个专栏都能准确地进行测量。 当然，我并不是在提倡您创建“地雷”网站，但到处都是像素，但是有时候您需要提交一个错误以进行修复，以保持网站的可用性，可用性和趣味性！

It's important that we don't lose sight of practicality when we try to stick to best practices. We can look sternly at a certain practices but what's most important is that we create functional, usable web sites. Never accept a rule without questioning its total validity and never be afraid to step outside rigid trains of thought!

重要的是，当我们坚持最佳实践时，请不要忽视实用性。 我们可以严谨地观察某些实践，但是最重要的是我们创建功能可用的网站。 绝对不要质疑规则的总有效性，也不要害怕走出僵硬的思路！

翻译自: https://davidwalsh.name/get-over