首页手记投稿013期 |...

投稿013期 | 程序员——不仅仅是编程

标签：

JavaScript 征文

我们往往热衷于追求一些新技术，却忽视了一些同样重要的东西。这些东西都是在工作中直接需要的，但是平时你很可能忽略，这很致命。或许你的知识水平能满足开发需要，但是却不能真正做好它，一些编码之外的东西，同样重要，或者说，这些东西也是编程的一部分。

1、代码规范——使用该死的ESLint

前端代码大部分是Javascript，JavaScript 是一个动态的弱类型语言，在开发中比较容易出错，而且很多错只有在运行的时候才能被发现。例如，我们应该一直使用=而不是，因为==可能会得到一些意外的结果。另外，我们开发大都是团队协作，需要保证代码的一致性和可读性。

ESlint的配置很灵活，你可以不使用业界已经存在的规范（例如airbnb），可以完全由自己定制。例如，我们在写React项目的时候，会有一个ESlint规则是：

react/prefer-stateless-function

意思就是无状态组件最好写成纯函数的方式。但是实际开发的时候，本来的无状态组件不知道什么时候就有了状态，所以我经常把无状态组件变成了纯函数，然后又改回来，很闹心。

随后，我关闭了这一条ESlint的规则，每次用到无状态组件时，就去继承PureComponent:

class XXX extends PureComponent ...

使用ESlint，不仅仅可以让代码变得规范美观，还能潜移默化地提升自己平时忽视的知识。最后的状态就是，我们在写代码的时候，就条件反射般地遵守了这些规范，不依赖ESlint就写出了“ESlint式”的代码。

2、代码合理封装——敢不敢模块化

我们都知道有一种算法叫分治法，我们写代码的时候，是不是经常一路写到底呢？

我经常能看到一个JS文件有上千行的逻辑代码，唯有泪千行。

开发的时候，比较难受的事情就是，一个团队重复做了同一个功能。例如，我曾经在一个项目里面同时看到了5个不同的函数，去把时间格式化，有的是写在公共模块，有的写在了代码逻辑层，非常混乱。这是某一个文件的不合理代码，我们要把某一类功能模块抽出来，这样就不必面对千行代码了。

我们都希望写出优秀的代码，但是优秀的代码都需要时间来沉淀，其实，模块化本身就需要一定的时间，以及一定的勇气。

为什么说需要一定的勇气呢？我们经常面对这样一种情况：

根据开发计划，先开发了A功能；

根据开发计划，又开发了B功能；

结果A功能和B功能差不多，然后发现即将开发的C功能也是类似的；

这个时候我们要做出艰难的选择，是复制粘贴一份A功能然后随便改改，还是写一个公共的模块用于复用，顺便把前面已经写好的功能用公共模块改造一下。

我们经常会有这样的想法：功能先做出来再说，模块化改造以后再说。但事实是，后面不会再优化这一块代码，甚至看都不想看，后面的维护可能只去关心有没有bug。

我个人的看法是：在条件允许的范围内，可以试着做一些模块化改造。以初级的水平来看，很难在编码之前就做好模块化设计，所以我们必须要自己创造机会去做这件事。尽量去写优秀的代码，这样才能积累经验，为了能在未来写出更优秀的代码。就算把功能改崩了，我们还有SVN、git，可以恢复，慌什么。

3、文档、注释——别逃避

上面说的例子中，我们看到一个项目里同时写了好几个同一种功能的方法，我们是否需要某种方式来规避这一类问题呢？答案就是写文档写注释。

程序员最讨厌写文档，比这个还讨厌的事情就是，别人居然不写文档！

确实，每个程序员都很讨厌写文档，但是写文档确实可以带来很多帮助。

据说，鱼的记忆只有几秒钟，那么人的记忆呢？听过一个小段子：某程序员吐槽，这是什么垃圾代码？然后仔细一看，这原来是之前自己写的代码。确实，随着时间的推移，我们会忘记自己当初为什么要做某件事。或者，某个函数需要传什么参数，返回什么值。虽然这是可以通过阅读代码来实现的，但是毕竟不如阅读文字来得方便。VSCode里面有个插件叫：Document This，可以自动生成注释：

/**
 *
 *
 * @param {*} object
 * @param {*} prefix
 * @returns
 */

写好文档需要我们真正理解代码具体在实现什么功能。如果不理解自己的代码，就不能写出好的文档。所以，我们在写文档的时候，进一步加深了自己对自己工作的了解程度。有时候，在写文档的时候，我们会意识到某些方法可以优化，进一步提升了自己。

写文档也可以帮助我们快速定位bug，尤其是代码里面的注释。例如，某个函数可能有问题，你不记得这个函数名是什么，但是你注释过，然后我们就可以通过搜索注释信息来得到我们想要的了。变量名、函数名可能在代码的多个地方用到，但是注释信息会少很多。

我们还需要写好注释之外的文档，注释的东西可能是具体的，但是我们还需要一个文档来整体把握整个项目，我们需要分析项目的整体架构，然后庖丁解牛，层层分割。或许我们还不知道如何写文档，我们可以看一下Github上别人上传的README.md，参考一下。顺便说一下，一般我都是用Markdown来写文档。

4、版本控制——这是必备技能

版本控制系统也是一个重要的编程工具，用于管理程序变化。如果你的代码因为某种原因不能用了，你可以把代码回滚到上一个稳定的版本。

不使用版本控制工具行不行呢？强硬地回答就是，不行！必须要版本控制。如果你对版本控制工具不了解，建议你多看看这方面的知识。

除了回滚代码，追踪修改之外，一个更大的原因去使用版本管理系统，就是为了合作开发。我们只需要考虑自己负责的模块的代码结构就行了，当然，也可以把别人的代码下载下来查看。我们也不用担心代码丢失或者改崩了，就算改崩溃了，我们也能找回之前稳定的代码。我们还可以新建分支，一个分支就是一个独立的功能模块，我们在某个分支上做的操作很明确，这样便于功能模块管理。

常见的版本控制系统是SVN和Git。我们可以去使用命令行代码，也可以使用图形化界面工具（Tortoise、sourceTree）。