背景

由于业务线的调整，我一手搭建的新项目后期就要交出去（我有点舍不得，自己开创的自己做的多香），而我要去接手别人的项目。在我接手别人项目的时候，我就发现项目文档不清楚，关于项目的很多事我都追着当事人问，项目交接体验不太好，看了几眼代码，这个开发体验也不好，哎。己所不欲勿施于人。当我的项目交出去的时候我就需要尽可能的避免这样的问题，于是我陷入了思考

前言

为了让代码的可读性增强，势必要舍去一些高级语法；

为了代码的可维护性，势必要牺牲一些书写的便利性；

我曾接手过很多很糟糕的代码，项目一期负责人是app同事，他们边学边写前端，前端项目与他们而言就是一次性项目，写完拍拍屁股就走人。我接手的时候，项目本地跑不起来，只能在测试环境看，项目布局全是position:absolute…总之你想象不到的糟糕，有一次产品提出需求的时候，差点把我写哭了，因为项目不重构没法写新的需求了。

从那以后我就会一直思考，如何提高开发体验，虽然现在我开发的项目还没有达到我理想的状态，但是我会一直努力做，争取未来有人看或者接手的时候，能没有任何怨言，最好能够说一句，这项目搭建的不错。这一直是我所努力追求的事

开发文档的完善

这个很重要，历史需求追溯，项目启动，项目概况等等，最好是新人接手看一眼就大概了解这个项目了

1. 项目安装/启动 => 分分钟启动项目

2. 项目用到了哪些插件/插件地址/插件简介/解决什么问题 => 未来有更好的实现或者更好的插件可以替换/大概可清楚项目做了实现了哪些功能

3. 每一期需求的设计稿地址/需求文档 => 项目可追溯/可快速了解整个项目的所有的功能

4. 项目发布/测试/预发/线上地址 => 不用到处问人

5. 开发相关人员，一目了然找到人，不用到处问

理清业务和开发的关系

知道整个项目的业务，不是为了跟产品 PK，砍需求，而是为了预判未来的发展方向，方便指导自己写的代码可以适应未来更久的时间，需要调整时可及时调整，而不用等到代码不可维护时才行动。懂了业务之后是去发现前端的“价值点”，以至于让我们更好的成长。

代码层面可以即使删除一些多余/冗余的代码，避免后续看的一脸懵逼，在开发时可持续化优化原来的代码。

逻辑点的分离

1. 埋点业务于逻辑业务分离，比如vue3项目中，埋点业务可用自定义指令实现，埋点业务就只存在DOM节点上

2. 业务逻辑复杂的情况下每一个 api 数据请求分离，比如使用react中的hook，或者单独一个js文件作为单一数据请求 多个api请求可以复用数据源 一个函数只做单一的一件事/单一原则 数据源来源方便追踪 适合大型项目 减少页面代码，颗粒化

3. 代码注释/相关逻辑数据放在一起

4. ui 逻辑/数据逻辑/业务逻辑 分开

5. 每个页面代码量控制在300-400行左右

虽然我是vue的忠实用户，基本是写了三年的vue，但是关于这个逻辑点的分离这点我非常喜欢react，我觉得react这方面做的很不错。未来是我不断学习的方向

总结

这只是我个人对于开发体验的一些总结，很多地方我都做的不太好，我会继续努力加油。争取我做到我做过的项目开发体验极加，别人看或者接手我的代码的时候没啥可以吐槽的。

自从我开始注重开发体验之后，我发现自己以前写的代码真low，我的进步太大了，我还有进步的空间，哈哈

参考文章

理清业务团队开发和业务的关系