1.背景在接手新项目或分阶段切换项目开发，或翻社区项目时，快速跑起来的技巧方法通常是通过阅读项目下的README.md文件来获取的。以上只是万里长征的第一步。当你想了解项目使用的技术栈、组件库、工具库等时，浏览依赖管理文件的三方包或业务代码模块时，往往结果比较扑朔迷离。稳定的项目库伴随着业务的增长和技术的升级。里面可能包含各种类似的素材库，比如elementui、antd-vue、自研的组件库等。在这样的情况下，如何取舍、避坑，不得而知。根据开发时根据需求如何划分项目包含的目录结构，是否随意存放当前业务模块应该存放的目录；开发中使用的工具是否在现有工具箱中可用，是否可以新增？有重复造轮；如何找到业务部门的相关负责人，每个环境访问的是哪个域名，开发测试发布的应用名称是什么，接口权限或菜单配置是哪个系统？抗拒私自找人打开等太多，相信各位读者都有所体会，都能产生共鸣。2.收益减少项目首次运行时遇到问题的概率，各种权限申请，各种环境下的系统地址访问，功能开发目录的存储，查询，查询，沟通，联调需要的资料项目。代理配置成本；提高需求聚焦度，把精力放在需求解读和执行上，用指南避坑；提高可维护性：保持开发环境配置的一致性。3.内容旨在帮助指导商务项目文档的编写：3.1项目名称项目名称是我们了解新项目的首要重点。在创建一些项目仓库时，我们经常会遇到只有几个字母的差异，业务却完全不相关或不存在的情况。需求中涉及到的项目对于新手来说会造成误解，所以这个名字也可以让我们更清楚的知道我们在众多的仓库中为目标库寻找一个更重要的参考。3.2开发环境（1）运行准备由于部分业务项目新旧并存，nodejs@version版本更新发布较快，经常会因为默认版本不同导致不同项目运行，导致切换项目后控制台报错。根据H5前端项目，从Git仓库拉下来后，下意识执行依赖包安装npm或yarn，因为那是项目运行的必要前提；因此，有必要指出当前项目使用的包管理工具的类型，以避免惯性在使用不匹配的管理工具思考了太久之后，我惊讶地发现我用错了。此时的心情，是世间最令人沮丧的等待，是扼杀人性的至暗时刻。H5目前主流且知名的前端有React、Vue、Angular等，必要的技术栈描述可以给人一个实现功能切换的时间，因为涉及到UI组件库的选择是Antd-*,Element-ui或者其他主流的组件库，在开发需求的时候，也可以明确在开发之前是否需要时间做一些技术储备，需求评估是否需要额外的时间。通常C端产品不需要菜单和界面路由配置，但对于B端系统，往往需要进行菜单配置。为了准确测试完成的功能和发布生产，大多数情况下需要进行菜单和界面路由配置，但是新手如何快速了解配置通道和配置系统权限的应用，最好直接提供链接配置文件。造成的损害。为保证代码风格统一，提前告知当前项目的开发需要执行哪些配置，哪些插件关闭IDE等，避免使用IDE格式化插件与项目的ESLint风格，导致运行时出现一堆令人抓狂的红色提示。(2)项目启动针对需要通过SSO权限认证的场景。大多数是通过验证根域名的合法性来授权的。这种情况下，需要将localhost绑定到本地hosts文件中的指定域名，这样才能在开发中正常使用。获得认证。通常默认的本地开发是通过yarndev/npmrundev进行的，但是由于需要配合后端以及不同项目的需求，不同的业务系统的需求是有区别的。清晰的说明可以减少启动时的多环境负载。审判或调查的费用。对于一个新项目或者新业务，新手在请求prd或者review的时候指的是指哪个模块，这个时候是盲目的。他们不知道如何查看模块的当前状态，所以直接链接到产品就显得尤为重要，因为这是一个快速访问入口。大多数情况下，当环境不稳定，环境被紧急占用，或者涉及访问其他域时，需要配置接口代理。一个清晰方便的配置姿势和目录尤为迫切。(3)目录划分展示形式：Markdown树状结构，借助工具树生成。项目业务模块划分的描述也是不可或缺的重要部分，因为在开发相应的业务模块功能时，需要知道相关模块是否存在，存放在哪里，以便后人快速定位;对相应的模块进行相应的操作或迭代。基于不断的版本升级迭代，逐步提取满足特定业务场景的公共部分。作为项目的公共资源，例如各种元器件、工具库、网络库等，都标明清楚，防止新手重新造轮子。(4)SDK文档对于一些非社区主流资源的介绍，比如在群或者小众中使用二方、第三方资源，建议将文档粘贴到文档中，这样大家就可以开发或排错时快速浏览文档，避免在一些不科学的上网情况下无法追踪。(5)避坑指南大多数人在开发过程中很少会遇到新架构、新版本的创业项目。因此，涉及的项目所使用的资源包存在历史原因等特殊场景。我们走过的坑等宝贵的历史经验记录，可以帮助后人避免类似的情况发生；(6)持续集成在项目部署中最重要的就是部署功能，而这时候兴奋的小手已经准备好放手了，当时我发现我不知道是哪扇门了，所以一清二楚应用程序名称和直接发布系统的链接似乎非常令人期待。(7)监控报警软件工程开发至此进入打磨阶段。一个软件产品还在裸奔的时代，基本上已经一去不复返了。观察生产真实用户场景下的运行健康状态，此时可以明确项目已经接入的监控；3.3业务介绍业务领域：清晰的描述项目所属的业务领域，帮助快速建立业务印象，结合业务下各版本的功能描述文档，帮助开发者初步了解背后的业务价值这生意;迭代方式：不同业务采用的需求迭代方式有一定差异，有项目化和敏捷开发方式。采用的速度也不同；有产品驱动或PMO方法来促进项目实施。目前来看，多为后者。Zaidwu采用更高效的系统RDC，具备MRD、PRD、review、schedule、taskAllocation、风险控制、人力资源等精细化运作方式，具备流水线需求完成和管控能力；相关人员：在项目中维护项目涉及的人员，不定时更新，有需求或者排查问题的时候，可以帮助大家快速找到相关同学进行支持。至少在大多数时候，还可以帮你找到当时参与过或了解过相应功能点的同学，提高交流效率等好处。4.总结项目文档是快速了解项目的最佳途径。从中你可以得到它所服务的业务，你参与开发所需要的知识体系，你在开发前需要做哪些准备，遇到问题可以联系我们。给对应的同学，不仅可以帮助新手快速上手，还可以帮助并行切换多个项目，刷新以往；总之，一份优秀的项目文档不仅要被团队成员理解，还需要被其他成员理解和完成，才能发挥其潜在价值。
