专栏名称: Fundebug
Fundebug为JavaScript、微信小程序及Node.js开发团队提供专业的线上代码bug监控和智能分析服务。
目录
相关文章推荐
前端大全  ·  从 DeepSeek 看25年前端的一个小趋势 ·  昨天  
前端早读课  ·  【招聘】字节跳动客服平台招高级前端开发工程师 ·  21 小时前  
前端早读课  ·  【第3455期】快手主站前端工程化探索:Gu ... ·  21 小时前  
歸藏的AI工具箱  ·  终于有给设计师用的 Cursor 了 ·  昨天  
歸藏的AI工具箱  ·  终于有给设计师用的 Cursor 了 ·  昨天  
前端早读课  ·  【第3454期】如何用语音学习编程的 ·  昨天  
51好读  ›  专栏  ›  Fundebug

写给前端工程师的10条实用原则

Fundebug  · 公众号  · 前端  · 2018-08-29 08:12

正文

译者按: 牛人都说自己是站在巨人的肩膀上,我们也要善于学习他人的经验。

  • 原文: 10 Things You Will Eventually Learn About JavaScript Projects

  • 译者: Fundebug

为了保证可读性,本文采用意译而非直译。另外,本文版权归原作者所有,翻译仅用于学习。

小编推荐:Fundebug专注于JavaScript、微信小程序、微信小游戏,Node.js和Java线上bug实时监控。真的是一个很好用的bug监控服务,众多大佬公司都在使用。

JavaScript编程简直就是一项冒险。当回顾工业界这10年来经过不成熟到专业的开发历程,我想每个人都会认同这个观点。

前端开发有很多丰富的选择性,充分的灵活性,以及大量发挥创造力的空间。不过,同时也要求我们自己需要有足够的知识,有一定的规划和自我约束。

一路走来,我们经历了jQuery,require.js,Angularjs,React,ExtJs等等。2018年的前端开发可以说是遍地开花。

在开发过程中,你会发现有一些 通用的范式 可以适用于各种复杂的项目。接下来我会介绍10个重要的范式,这些都是我多年来的个人经验。虽然都是个人的观点,我相信很多有经验的开发者都会认同。这一套规则适用于任何项目、任何框架、任何大小的团队。它可以减少开发者花在文档和重构的时间、甚至开发中的争吵。

1. 分而治之(Divide and conquer)

这个词大家并不陌生,但是很多人低估了这条规则的适用场景和能力。CommonJS,Webpack,和Node都支持我们把代码拆分到多个文件,我们为什么还需要分而治之的理念?

一致性 :当代码量越来越大,将项目拆分成一个个小的文件可以让查找和以来管理变得十分容易。并且文件命名要足够直观,反应了文件中代码做的相关工作。这样可以减少耗费脑力去查找代码结构的负担。

管理便捷 :代码足够模块化的拆分使得文件的移动和进一步拆分变得简单。如果你发现一个帮助函数在应用中另一个地方也需要用到,你可以创建一个名为 /shared 的目录,将代码放进去。这样方便共用,也方便查找。

2. 任何东西都要超级直观易懂

每一个变量、函数、文件名 – 就如同给你的孩子取名字一样认真去给他们取名字。

也许你今天通过把它命名为 x 节省了0.3秒的时间,但是在接下来的一个月你将会花2天的时间来搞清楚 x 到底指代什么,然后再花4天做重构。好好想想,不要担心命名太长。

避免使用一些奇淫技巧(即使已经足以让你申请MIT)
你的方案也许很聪明但是负责,导致的后果就是在将来,你或则团队里面的其他成员将会浪费大量时间去理解你写的那段代码兜里是如何运作的。 专注于用最直观简单的方法把事情搞定,甚至不需要文档或则评论

3. 不要使用魔法数字和字符串

和命名的原则一样,要直观易懂!不管你觉得可能多么简单的值,也要用一个有意义的变量名来声明。

在大多数情况下, 任何你声明的值很有可能在其他地方复用 。因此,通过声明变量的形式,可以减少代码重复,并且易于维护。

4. 避免嵌套太深

如果你写的代码一行超过120个字符,超过500行,或则 if语句超过3层,最好做拆分

你可以把嵌套的if语句拆分成 函数 Promises Observables 。如果你使用了很多异步调用,使用 async/await 也可以极大简化你的代码。

5. 早点做好配置工作

如果你的应用中使用了 全局变量,API接口,第三方认证 等等,把它们放到单独的配置文件中去。

不管是网页(web)还是Node,都有很多可用的包(package)来管理配置,比如config。
某种程度上说,你的应用的配置应该做到可以支持运行在生产服务器和本地开发。
早点创建配置文件比后面再来做要容易很多,特别是相应的环境配置,安全配置,功能配置等等

6. 选用合适的框架

花时间想清楚你是否需要框架,以及使用哪个框架。 终端用户不会关心你的网站或者应用使用了一个在Github上超过10w stars的框架。 根据我的个人经验,我把它们简单的做了如下分类:

  • React: 如果你需要对整体的架构和构建有充分的控制权,React是一个很好的选择。你需要花时间去熟悉React的整个生态系统,事先做好规划。而这些都是值得的,如果你很清楚你要什么。

  • Angular / VueJS / Ember: 如果你想要快速实现一个可靠的Web App,就选它们吧。虽然你可能对整个架构有一些不了解。 这些框架帮你做了很多事情,所以在规划的时候要想清楚使用它的优点和缺点 。它们严格的目录结构虽然少了自由,但是可以让你少犯错误。

  • jQuery / lodash / 或则类似的: 如果你想快速实现一个网页,并且没有多少的带宽可用,那么选用它们能节省你很多时间。不过你需要小心,因为你可能写出难以维护的代码。你要注意把它们当做辅助,而不是基础。

  • Vanilla / 不用框架: 如果你有很多的时间来计划和开发,那么使用纯JavaScript来写是个很好的选择。你可以做一些实验性的功能,比如引入WebGL,Workers,深度优化,或则动画等等。最终,你可能甚至做出了自己的一个框架。

把这些当做建议,你需要花时间慢慢去选择使用哪个框架最适合你的项目。

7. 除非是原型,否则一定要写测试

单元测试、冒烟测试、端到端测试、合理性(Sanity)检验。除非你的项目只是一个原型用来演示,否则赶紧写测试。 当你的代码库越来越复杂后,将会变得难以维护和控制。这个时候,你需要测试来帮你做检查

在不远的将来,当你遇到bug的时候,你会仰望蓝天,谢天谢地的感慨好在当初写了测试。 你永远无法预料新引入的功能是否会默默地把你之前的代码搞挂掉

8. 使用版本控制

不管是一个原型、大型企业项目、或则是一个个人的小项目,使用git或则其它版本管理工具,从一开始就要管理起来。每天保持提交(commit),使用分支(branch),学会合并代码(merge),解决冲突,和回退到之前提交的版本。记得提交代码的消息要认真写,不能随意乱写。







请到「今天看啥」查看全文