关于如何把项目做得更好的一次思考

之前做开发的时候对项目完全没有一个整体的思考，需求来了就知道做，只关心自己做的那部分的功能，做完拉到。但最近所做的项目中，遇到了不少问题，自己都忍不住吐槽起来了。如：项目经常性延期、代码冗余、添加一个很小的新功能都需要改动很多地方，还对之前的代码逻辑产生不小的影响。这使得我不得不对现有的项目进行思考。

怎么样才能把项目做的好一点或者更好？
首先，在老板看来，他肯定希望今天提的需求可以立马就上线。
然后，老板希望我们做出来的产品有很好的用户体验，有良好的性能。
最后，希望系统能够稳定运行，出问题时能够尽快修复。

当然，这只是我脑补出来的（我个人的想法，至于老板是不是这么想我就不清楚了）。

从技术上来说就是：

• 可以快速搭建
• 拥有比较好的性能
• 逻辑清晰，易于维护、拓展
• 快速解决线上问题

如何进行快速搭建？

一、组件封装：公共样式、逻辑提取。
有时候，我们需要做一个统一的自定义弹窗样式，或者自定义的下拉框等。我们封装成公共组件之后，其他地方需要用到时，只需引入组件和传入数据即可使用，不需要再重复的去写样式或者逻辑。有些甚至不需要设计再重新出图，利用组件就可以完成我们的页面开发了。
封装前：
多个页面中，同样的页面样式和js逻辑无法复用，需要在每个页面中进行代码的复制粘贴，很可能会漏掉部分代码。发生样式或者js逻辑改动时需要每个页面都改一遍，很容易漏掉。
封装后：
可进行代码复用，多个页面中，同样的页面样式和js逻辑直接引用封装好的组件即可。发生样式或者js逻辑改动时，只需要改一个地方即可。

二、 项目的基础搭建
新开一个项目的时候我们都需要先去做一些基础搭建，比如说：项目目录结构、登录模块封装、http请求处理和其他辅助小工具等等。这些东西我们可以做成一个npm包，发到公司内部的私有仓库里，使用的时候直接一个npm install 就可以快速的完成项目的基础搭建了。

逻辑清晰，易于维护、拓展

深入理解产品需求，将功能逻辑划分，对应成相应的代码逻辑：

• 哪一部分样式可以封装
• 哪一部分功能可以封装
• 页面里各个逻辑的关系：点击一个按钮，页面中的其他展示要如何变动
• 各个页面之间的逻辑关系：在当前页面操作，其他页面需不需要做出相应的变动

如果开发时不看需求文档，到了最后除了撕逼之外还得返工。

与其他功能模块对接时尽量多考虑，做成可拓展的通用模块。与某个模块对接时，如何与当前模块完成对接是我们首要考虑的事情。考虑完这方面的事情之后，我们还要考虑一下再有另外一个模块或者多个模块接入时我们要如何才能在代码改动量最小的情况下进行快速接入。

关于注释：
注释是有必要的，这个对个人和他人都是有好处的。自己一个月之前写的代码，没有注释再回去看时可能也不太懂，何况是别人呢。
如果可以的话，每个js文件的开头简单描述下当面页面的功能逻辑，让维护的时候能快速的了解到当前页面上的东西。

关于文档：
大家都去遵循一定的规范才能更好的去共同创造/维护一个东西，这些规范形成之后一定要遵循下去。当一个新的小伙伴加入到我们的时候，我们不可能把每一个规范都口头的跟他讲一般，我们自己也记不住那么多规范。所以，将这些规范整理成文档很有必要，记不清楚或者不了解的时候可以重新去翻一翻。还有我们封装好的组件，其他人使用的时候也不可能花时间去看看你的源码，或者总是来问你要怎么用。这样会很浪费大家的时间，阻碍整个项目的进度。所以，组件的用法、入参/出参、注意事项等等我们都需要再文档里面描述清楚。

拥有比较好的性能

根据当前做的项目，使用的技术栈，找出引起性能问题的点，逐个进行优化。就拿我当前做的这个原生小程序来说，性能问题主要在以下几点：

• 频繁的调用setData。
• 在后台进行多个数据请求并进行多个页面setData操作。
• 首次加载小程序时包下载比较慢。

解决方案
问题1: 避免频繁的setData, 将可以合并的setData合并，不在页面渲染的变量不在data里声明，在page下的其他字段里声明即可
问题2: 当面页面的改动需要刷新其他页面时，不需要立即对其他页面进行数据刷新的动作，给需要刷新的页面加个标识，等到该页面显示时通过onShow声明周期来判断并刷新 数据。
问题3: 使用小程序的分包加载，加载首页时只需先下载分包即可，提高首页加载速度。

快速解决线上问题

遇到线上的bug应该快速的响应和积极的定位问题出现的原因，从根本上去解决问题，而不是说这不是我的问题，我不用管。
尽早发现问题，在造成更大的影响之前解决问题：
自行搭建一个错误收集系统，收集js脚本错误和接口请求错误的相关信息，为定位问题提供帮助，还可以根据错误的峰值来检查当前系统是否异常。怕麻烦，图省事的还可以花钱使用fundebug。

日前能想到和记得的就只有那么多吧， 先记着，以免遗忘。