在ThoughWorks有一句广为流传的话——“在ThoughtWorks，你需要有一种随时拥抱变化的心态”，因为我们践行敏捷，我们有各种各样的客户，商机稍纵即逝。作为一个普通的dev，很明显我不会像其他互联网公司一样长期呆在一个固定的项目里，有足够的时间去了解项目的来龙去脉和背景。我们的项目周期足够短，有时甚至几周也算正常。项目的频繁切换，需要dev快速了解一个新项目。这是我在ThoughtWorks思考了几年的问题，如何快速熟悉一个新的敏捷项目。以下是我为自己、新同事以及任何正在实施敏捷软件项目的人积累的经验。本文中提到的许多术语和术语都是基于ThoughtWorks的日常项目和团队活动。默认情况下，读者对敏捷开发过程和不同的角色有一个大致的了解。对ThoughtWorks的开发模式感兴趣的也可以参考小然的文章《ThoughtWorks的敏捷开发》。文中还会提到具体的技术和工具，如Spring、Gradle或Webpack等，仅作为具体示例，与本文主题无关。如果您有任何问题，请留言，我会尽力解答。在了解团队工作之前，我觉得项目上的“东西”应该更重要。工作时间越长，我越意识到“人”在决定项目成败方面发挥着更大的作用。虽然有时候我们会调侃某个项目是“坑”还是“不坑”，但其实我们知道一个项目是“坑”还是“不坑”取决于谁来做这个项目，所以我把这一段放在前面.站立会议应该是第一次见到团队中几乎每个人的最佳机会。在第一次站会时，你应该了解团队中的所有角色，以便在接下来的工作（Kickoff）、DeskCheck、checkpoint（Signoff）中找到合适的人来开卡，它需要注意的是，并不是所有的项目都有“全明星阵容”，有时候很多角色是兼任的，比如PM和BA（BusinessAnalyst，业务分析师），BA和UX等。可以主动询问项目中是否有相关的OnBoardingCheckList，快速了解一个团队的工作作风。每个项目的工作习惯都不一样。工作中的OnBoarding文档可以快速了解这些，比如如何开卡，是否需要做DeskCheck，提交代码时的Comment规范是什么。另外，积极寻找合适的人配对，结对学习一个新的项目，在ThoughtWorks是很常规的操作。刚到项目的时候，会给你一些时间搭建环境，熟悉代码。这时候，你可以熟练地与老手配对，几天可以说是事半功倍。另一个重要的技巧是学会快速记住其他人的名字，这将使你更容易融入团队并受到尊重。作为开发者理解业务，需要把业务作为一个整体来理解，才能对单个故事卡有足够的理解，否则单个故事卡被横向看成一个山脊，看成一个峰。当然，去BA聊业务是很直观的，但是在找BA之前更好的建议是向QA询问测试或UAT（UserAcceptanceTesting，用户验收测试）环境的地址和账号，如一个普通用户再用一次，这样你就会从用户的角度有一个初步的了解。和BA做业务的时候，BA会拿出原型图，这时候会结合之前对应用的印象，了解业务背后的逻辑。因为并不是所有的业务逻辑都能在原型图中体现出来，所以在实现过程中会对原设计做一些小的调整。还有一个就是结合已有的功能看原型图，这样就可以知道哪些已经开发了，哪些还在开发中，以便后面参考已经实现的功能或者代码自己的开发过程。另一个关于原型的小技巧是，为了保持项目风格的统一，很多项目都会给出一个StyleGuide，指定一个基本的风格规则，比如间距、字体、颜色等，如果有时间，可以通过故事墙作为一个整体来查看项目达到了哪个阶段和状态。很难有足够的时间详细阅读所有的故事卡，你需要有一个整体的印象，但需要注意的是，一些跨职能的需求很重要但没有在故事卡上表现出来，因为跨职能的需求是一些常见的，默认的需求，比如表单验证，分页等等，如果不注意这点，开卡的时候可能会忽略，但是对应的需求会在QA里覆盖测试。了解项目业务的其他方法是阅读项目启动（启动）报告和Wiki文档（如果可用）。Inception报告中的信息来自Inception期间从客户处获得的第一手资料。有时觉得有些需求很奇怪（比如用奇怪的存储介质Excel代替数据库，用户业务人员需要直接修改数据等），但往往是一些既定背景妥协的产物，以便可以了解前维护者的真实意图。了解项目架构师的习惯往往是第一时间打开代码，但是随着项目越来越规范，一般来说会分成多个代码仓库。如果直接阅读代码，有时很难组织和理解项目的结构。如果项目提供了一些架构图和流程图，可以作为参考。如果没有，我们也可以通过一些方法来了解项目的架构，尝试画一些图形来帮助自己理解项目。使用C4模型表达项目架构和依赖C4模型是一种逐层描述项目结构（系统-容器-组件-类）的方式，避免在绘制图形时将不同层级的实体放在一起，造成架构图看起来很混乱。为了表达项目依赖关系，我们可以使用系统级别（即以每个系统为单位）；为了表达我们自己的项目架构，我们使用容器级别。例如：（图片来自：https://c4model.com/#examples）在这个例子中，虚线外侧可以表示系统之间的依赖关系，虚线内侧是系统的各个组件当前系统。如果很复杂，可以用两张图来表示。当然，系统的各个部分还可以进一步放大。通过查看代码仓库中的配置文件，很容易了解项目的依赖，因为标准化的项目会将第三方依赖的信息放到配置文件中，方便根据不同的环境进行切换，并且不会硬编码到业务代码中。从技术架构上考虑：技术栈和第三方包依赖依赖服务的调用关系。认证授权服务使用E-R模型来表示数据库关系结构。E-R图也称为实体关系图。关系数据库的灵魂是数据模型之间的关系，通过这种方式来实现数据的完整性、一致性和正确性。为了减少冗余，提高一致性，需要对多张数据表进行合理拆分。如果数据库比较大，很难理解实体之间的关系。因为我们可以用实体-关系图来表示数据库的关系结构，所以一般来说，实体-关系图也会画出属性，但是如果属性比较多或者我们想关注关系，也可以省略属性。图片来自：https://www.aliyun.com/jiaocheng/1112566.html使用时序图表达关键逻辑如果遇到比较复杂的单个业务流程，比如订单流程。前后端API可能有多次调用。在这种情况下，使用UML的序列图非常清晰。（图中没有对应的项目，仅作为案例展示）说说对代码的理解阅读代码时，除了看平时的代码逻辑外，最好关注与代码相关的代码项目的配置。例如，@Config注解下的类在Springboot中使用。每个项目之间的区别通常就在这里。如果你不知道如何配置一些bean，你会经常被一些简单的问题卡住。一般来说，一些拦截器和过滤器放在配置相关的代码附近。多了解全局配置可以避免一些奇怪的问题。另外，项目中的打包过程也值得一看，比如gradle构建文件和前端webpack相关的脚本。一些项目会有技术债务列表或图表。了解技术债务可以避免一些重复工作，因为有些代码可能会被重构或弃用，我们不需要在这些代码之上进行更改。在DevOps项目中的DeveOpsChecklist项目中了解DeveOps的工作是非常琐碎的，但是如果了解了这些信息，对于上线和调试会有很大的帮助。这里我就不一一展开了，只是提供一个列表来说明一般的项目会包括哪些DeveOps。相关内容。Dev、QA、UAT、Prod等多环境CI/CD代码仓库Artificts存储密钥管理部署脚本安全扫描工具FindbugsSonarqube定时任务备份日志使用网络拓扑图展示部署情况当我们遇到一些线上问题，想调试，或准备上网时。您需要了解网络和服务器相关情况。这时，你可以使用网络拓扑图来描述应用程序的部署。（图片来自：https://aws.amazon.com/getting-started/projects/deploy-nodejs-web-app/）为了了解项目的进展，我把了解项目的部分放在最后，因为团队中有PM和TeachLeads更关心项目组织。但是随着对项目的熟悉，了解项目管理的一些方面也是很有必要的，至少了解一些重要的时间点是很有必要的。Releasetime–顾名思义，上线发布的时间UATtime–上线前在UAT环境中准备的时间Codefreezetime–锁定代码或新建分支，不再提交新功能，但可以继续修改缺陷展示案例时间——向客户展示阶段性结果的时间这些时间点基本上是一个项目的飞行计划。在项目管理中，干系人管理是非常重要的一环，因为客户往往不可能只联系一个人。大声疾呼的人不一定是最终的决定者，经常不出现的人也可能是能够做出重要决定的人。但是对于devs来说，如果需要对接客户的其他系统，找下面几类人比较重要：技术对接人UAT或者线上验收人总结这篇文章基本上是CheckList类型的“水”文，但还是决定发出去。交货时间是真钱。如果新成员能够快速上手，很重要的一点是团队的敏捷实践足够好，代码足够规范，文档足够完善。尽量避免人员调换造成上下文丢失。团队沟通不应该只是口耳相传，更不能让一些关键信息成为“单点故障”，而应该及时传递给整个团队。
