之前我在做开发的时候，完全没有把项目作为一个整体来考虑。需求来了，我就知道怎么做了。我只关心我做的部分的功能。但是在最近的项目中，遇到了很多问题，忍不住发牢骚。比如：经常项目延期，代码冗余，增加一个小的新功能需要很多改动，对之前的代码逻辑影响相当大。这让我不得不考虑现有的项目。我们如何才能使项目更好或更好？首先，站在老板的角度，肯定是希望今天提出的需求能够马上上线。然后，老板希望我们做的产品，用户体验好，性能好。最后，希望系统能稳定运行，出现问题时能尽快修复。当然，这只是我的想象（我个人的想法，至于老板是不是这么想，我就不知道了）。从技术角度：搭建速度快，性能更好，逻辑清晰，易维护，易扩展，快速解决线上问题。如何快速搭建？1、组件封装：公共样式，逻辑抽取。有时候，我们需要做一个统一的自定义弹窗样式，或者自定义下拉框等，我们把它封装成一个公共组件后，需要在其他地方使用的时候，只需要通过引入组件并传入数据，无需重复编写样式或逻辑。有的甚至不需要设计和重新绘制，我们的页面开发使用组件就可以完成。封装前：在多个页面中，不能复用相同的页面样式和js逻辑。每个页面都需要复制粘贴代码，可能会遗漏部分代码。当一个样式或者js逻辑发生变化时，每个页面都需要重新改一遍，很容易遗漏。封装后：代码复用成为可能。在多个页面中，相同的页面样式和js逻辑可以直接引用封装的组件。当样式或者js逻辑发生变化时，只需要改变一个地方。2.项目的基础搭建当我们开始一个新项目的时候，首先需要做一些基础的搭建，比如：项目目录结构，登录模块打包，http请求处理等辅助小工具等等，我们可以制作这些东西打成npm包，发到公司内部私有仓库。使用时，只需一个npminstall，即可快速完成项目的基础搭建。逻辑清晰，易于维护，扩展深入了解产品需求，将功能逻辑划分为对应的代码逻辑：风格的哪部分可以封装功能的哪部分可以封装各个逻辑之间的关系页面：点击一个按钮，其他显示在页面上如何改变各页面之间的逻辑关系：如果对当前页面进行操作，是否需要对其他页面进行相应的更改？开发时不看需求文档，最后除了撕还得返工。与其他功能模块连接时尽量考虑，使其成为可扩展的通用模块。在与某个模块对接时，如何完成与当前模块的对接是我们首要考虑的问题。考虑到这方面之后，我们还需要考虑在连接另一个模块或多个模块时，如何以最小的代码更改快速访问它。关于注解：注解是必须的，对个人和他人都有好处。一个月前写的代码没有注释我都可能看不懂，更别说别人了。如果可能的话，每个js文件的开头都简单描述一下当前页面的功能逻辑，方便维护时快速了解当前页面的东西。关于文档：只有遵循一定的规范，才能更好地共同创造/维护一些东西，而这些规范形成之后就必须要遵循。当一个新伙伴加入我们的时候，我们不可能口头上向他解释每一个规格，我们自己也记不住那么多规格。所以，有必要把这些规范整理成文档，自己记不清楚或者看不懂的时候可以再过一遍。还有我们打包好的组件。别人用的时候，不可能花时间看你的源码，或者老是来问你怎么用。这样会浪费大家的时间，阻碍整个项目的进展。因此，我们需要在文档中清楚地描述组件的用法、输入/输出参数、注意事项等。有比较好的性能根据当前项目和使用的技术栈，找出导致性能问题的点，并一一优化。以我目前做的原生小程序为例，性能问题主要有以下几点：频繁调用setData。进行多次数据请求，在后台进行多次页面setData操作。第一次加载小程序时，包下载速度慢。解决问题一：避免频繁的setData和merge可以合并的setData。不在页面上渲染的变量不在data中声明，但可以在页面下的其他字段中声明。问题2：当页面发生变化，需要刷新其他页面时，不需要立即刷新其他页面的数据，在需要刷新的页面上加上标记，等页面显示出来再判断和通过onShow语句循环刷新数据。问题三：使用小程序分包加载时，只需在加载首页时先下载分包即可，提高了首页的加载速度。快速解决线上问题遇到线上BUG，应该快速响应，主动定位问题原因，从根本上解决问题，而不是说这不是我的问题，我不在乎。尽早发现问题，在问题造成更大影响前解决问题：自己搭建错误收集系统，收集js脚本错误、接口请求错误的相关信息，为定位问题提供帮助，并根据当前系统检查是否正确到误差异常的峰值。怕麻烦的话，想省事可以花钱用fundebug。前几天能想到的和记住的东西就这么多，先记住了，免得忘记了。
