Node.JS和Socket.io入门及保持代码工整的7个小技巧[图]

一、Node.JS和Socket.io入门
使用Express创建您的第一个Node和Socket.io聊天应用程序。
要求
1.安装Node.JS和Git。
2.一点JavaScript经验。
创建应用
1.转到您的项目目录。
2.在此处打开终端并运行以下命令，
安装所有必需的模块
express：npminstallexpress--save
Socket.io：npminstallsocket.io--save
创建和部署基本的Express服务器

部署服务器
打开Chrome并导航到localhost：8080。
如果您看到以下信息：
通过服务器加载HTML文件
为简单起见，我没有使用Jade，EJS或任何ViewEngine。
现在，在根目录中创建一个名为Public的文件夹，并在其中创建一个名为index.html的文件。
现在让我们开始使用Socket.io
首先，我们必须在主服务器上启动Socket.io子服务器。
在server.js中：
更换：app.listen(port);
为：vario=require('socket.io').listen(app.listen(port));
这使Socket.io可以访问服务器，以便它可以将socket.io.js提供给public/index.html。
有关Socket.io的信息
为了实现与服务器和前端的实时快速通信，使用Socket.io，它将请求从客户端传递到服务器端。
在socket.io中，有两个脚本，一个在客户端运行，另一个在服务器端运行。两者相似，但是运行在不同的平台上。数据的传输通过由Socket.io内核中的函数触发的事件来处理。
在开始传输数据之前，客户端必须连接到构建在服务器顶部的Socket.io子服务器。当客户端连接到服务器时，'connection'将为在服务器上运行的Socket.io触发事件。
二、保持代码工整的7个小技巧
可读的代码是可维护的
在这篇短文中，我将介绍一些你可以用来改进你的代码的方法。本文代码示例均使用JavaScript。
我发现但凡是可读的代码必定是可维护的。
作为一名开发人员，我的目标是编写高质量的代码。团队中的每个开发人员，不管他/她的技术水平如何，都必须能够通过阅读理解我所写的代码。代码的可读性有助于年轻的开发人员编写代码时更加自信。
删除不必要的代码注释
当然，有些代码可以非常复杂。我深知这一点且见过很多次。在复杂的代码中，我会写些适当的文档和代码注释。
别误会。我不是代码注释或JavaScriptJSdoc的爱好者，而且基本上我能不用它们便不用。
我不需要任何注释来解释这个接收X个数组并将它们合并到一个新的数组中的函数。
functionmergeArrays(...arrays){letmergedArray=[]arrays.forEach(array=>{mergedArray=[...mergedArray,...array]})returnmergedArray}
像示例代码，如果增添文档并不能提高可读性。我希望团队成员知道展开操作符是什么。如果他们不清楚，他们应该在代码审查codereview时来问我。
当然，我们不要忘记注释的代码块。如果我们忘记了，这里只有一个解决方案：删除代码。既然了不起的git可以检出旧代码，那么为什么还要把它留在注释中呢？
请停止把你的代码库变成垃圾场。
重视命名

如果你看到函数名mergeArrays，就应该很清楚地知道这是一个将X个数组组合成一个新的数组的函数。我知道命名是件难事。函数越复杂，命名就越难…我有个法子让命名更容易，举个例子：有一个函数，它会合并两个数组并生成一个新的唯一的数字列表。观后感（https://www.yuananren.com/guanhougan/）你会怎么命名？是下面这样吗？functionmergeNumberListIntoUniqueList(listOne,listTwo){return[...newSet([...listOne,...listTwo])]}

mergeNumberListIntoUniqueList这个名字并没有那么糟糕，至少功能如其名。命名的难点在于这个函数要做两件事：一个函数做的事情越多，命名它就越困难。将这个函数拆分为两个单独的函数，命名会更容易且函数复用更容易。
functionmergeLists(listOne,listTwo){return[...listOne,...listTwo]}functioncreateUniqueList(list){return[...newSet(list)]}
当然，不需要调用新函数就可以很容易地创建美观的一行代码。但有时，一行代码的可读性并不高。
If语句
我对这个问题的命名无力…看！命名不易…
但我经常看到这种情况。
问题
if(value==='duck'||value==='dog'||value==='cat'){//...}
解决方法
constoptions=['duck','dog','cat'];if(options.includes(value)){//...}
这样做，你创建了一段像是英语句子般的可读代码。如果选项包含值，那么...
提前退出机制
这个准则有很多种命名方式，但我选择了“提前退出Earlyexit”这个名字。
让我给你们看一段代码。我相信你们以前见过这样的东西。
functionhandleEvent(event){if(event){consttarget=event.target;if(target){//Yourawesomepieceofcodethatusestarget}}}
来我们检查下对象event是否为真，以及属性target是否可用。问题是上面代码我们已经用了两个if语句。
让我们看看如何在这里实现“提前退出”。
functionhandleEvent(event){if(!event||!event.target){return;}//Yourawesomepieceofcodethatusestarget}
在这里用“提前退出”，你可以检查是否event和event.target同时非假。很明显，我们确信这一事件event.target非假。因为如果这个语句为假，程序就不会执行其他代码。
解构赋值
在JavaScript中，我们可以解构数据和对象。
根据developer.mozilla.org上的文档，解构赋值语法是一种JavaScript表达式。通过解构赋值，可以将值从数组、属性从对象中取出，赋值给其他变量。
一些代码示例
//Destructuringanobjectconstnumbers={one:1,two:2};const{one,two}=numbers;console.log(one);//1console.log(two);//2//Destructuringanarrayconstnumbers=[1,2,3,4,5];const[one,two]=numbers;console.log(one);//1console.log(two);//2
解构的问题在于，它有时会为属性创建一个不好的命名。最好的例子是从API获取数据并接收具有data属性的响应对象。
consturl="/api/v1/organizers/1"constresponse=awaitaxios.get(url)const{name}=response.data
这个代码示例说明你正在获取id为1的organizer。organizer对象有一个名字，你可以解构它。这样做没什么问题。
这段代码可以正常运行。但是为什么属性名还是name?那将是整个范围中唯一的name属性吗？属性名又来自哪个对象？
通过重命名属性可避免这些问题。
consturl="/api/v1/organizers/1"constresponse=awaitaxios.get(url)const{name:organizerName}=response.data
这段代码变得更具可读性。每个人都知道变量是organizer的名字。
童子军规则
听过这样一句话吗：“永远保持离开时的露营地比你发现它时更整洁”？
这就是童子军的规则。让代码比发现时更好。你发现代码异味codesmell？重构它！你发现一个未使用的变量？删除它！
我喜欢把童子军规则和打扫房间的情况进行类比。想象一下，你家里的每个人都把盘子放在水槽上，把所有垃圾都放在走廊上，把所有要洗的衣服都放在浴室里。但是每个星期天，你必须花费4个多小时清理整个房子。你会钟意吗？
我肯定答案是NO。所以如果每个人都立即清理房间的小部分，星期天的工作量会小一些。
代码库同理。如果每个小的代码异味codesmell都留在代码库中，没有人删除未使用的变量，linter就会抓狂且有大约77个warning。而且代码库将会有很多清洁工作要做，但是如果每个人都承担起自己的责任并遵守童子军法则，很多问题将会得到解决。
代码风格
同样重要的还有确定团队中的代码风格。
我不care你是喜欢单引号还是双引号，空格还是tab，结尾逗号还是不用。选择一种风格并坚持下去。你可以用Linter或者Prettier来做这件事。
有很多工具可以用来解决代码风格问题。我最钟意的是使用Husky预提交钩子。Prettier的文档中也有一个关于预提交钩子的页面。
这个预提交钩子总是在每次提交之前运行配置好的命令。如果你正确地配置它，它会运行得更漂亮，并对所有文件应用所有规则。这确保了团队总是拥有统一的代码风格，而没有任何糟糕的代码。
总结
我知道有些方法显而易见，有些则不是。但作为一名全职开发人员，我在不同的代码库上工作。这些规则的重要性只有在较大的代码库中才会突显。但这并不意味着你不应该将这些方法用在小项目中，提高你的代码质量让小项目更高效。它让团队成员方便地阅读你的代码并合并你的pull请求。正如我所说的，可读的代码更容易维护，当然可读的代码还有其他更多的好处。
如果你想了解更多关于代码整洁之道的知识，可以尝试阅读罗伯特马丁的《代码整洁之道》。