IT行业从0-1了解软件项目的那些事儿

成年人之间的客套，不能信，尤其是IT行业。

最近在忙啥？一起吃个饭？

不了不了，手里还有几个项目呢，下次吧

“项目”二字，彰显的是身份，是能力，不说项目多大，不谈担任什么角色，只要我能参与到这个项目中，我就是厉害！

项目组的人表面上光鲜亮丽，背地里绞尽脑汁，进入项目组中，就会发现，在软件项目从0-1中，时间是按照“月”来计算的，几个月甚至几年，才能完成一个项目。

如果交给你一个软件项目，你会怎么做？

今天就带大家从0-1了解软件项目的那些事儿，初学者可以了解在软件项目工程中，主要涉及到哪些岗位以及他们的工作职责；经验者可以了解软件项目工程中，不同的岗位工作对于项目的定位是什么，如果要团队内部协作的话，有什么思路来提高认识。

项目不是一锤子买卖

项目不是一锤子买卖，所有岗位人员并行多任务操作，期间的岗位人员需要的不仅是各司其职，还需要相互和谐。

在项目开始前，首先要这明白几个问题：

梳理项目内部是如何协作的？以及为何这么协作？

软件项目中的协作流程是什么？

各个岗位在流程细节上又是如何协作的？

软件项目在产生时，经历的各个阶段，都由不同岗位人员参与，他们的定位更加明确，只有在进行项目协作时，考虑项目的生命周期、项目的迭代流程、项目的协作流程和高效协作方式，再体会不同岗位是如何项目协作的，才能营造良好的协作氛围。

项目生命周期

项目的生命周期大致分为5个阶段：调研、设计、研发、测试和运营，整个周期呈现环形，方便后续进行项目调整。

调研：多方位评估现状，探索发现最符合公司利益的方案，金点子很重要。

设计：从产品的原型、UI界面和项目里程三个方面考虑，画大饼很重要。

研发：根据团队人员数量和技术水平，合理拆分任务，做项目很重要。

测试：对照产品需求文档、UI设计等因素下手，找对茬很重要。

运营：把环境做好，等待符合要求的稳定代码的到来，发布到生产服务器中，以技术的角度，将项目维持好，维稳定很重要。

不同阶段主导团队该做什么？

调研和设计 ：产品团队主导，产品原型设计师、UI设计师，项目里程根据其他团队的能力逐渐梳理出来，不要贪快做不到。

研发：研发团队主导，其他团队参与。对于设计阶段的内容，产品原型由后端研发人员来完成，UI界面由前端研发人员来完成，前后端团队间把控好数据接口的标准。

测试：测试团队主导，其他团队参与。根据实际情况，依据产品原型的功能和UI界面的效果，进行各种功能性测试和非功能性测试以及其他测试，最终保证过我收的东西是合格的。

运维：运维团队主导，其他团队参与。主要做的是环境标准化、业务流程化、操作自动化等。

就以单一的基础的项目任务来说，运维人员工作的时长，要远远的超出其他人员对于项目的付出， 能力有多大，责任就有多大。

公司组建一个团队不容易，不可能一个人干活，其他人就静静地看着，为了让大家创造出来价值，实现个人的能力升华，也为了让公司更大程度的开发员工的价值，让员工高效的工作，是我们最终的目标。

对于项目来说，一个无限循环的∞，而对于团队个人来说，进入到了一个，刚做完A就开始B，刚做完B就开始C的无限循环中，最终一个团队的所有人都在紧张而忙碌的并行工作，为了让公司开发最大的价值而努力奋斗。

前半个循环参与的部门多，所以需要一个协作机制 AGILE，保证信息的交流是精确的，后半个循环是一个部分自己内部消化的，所以无需其他的协作机制。

怎么合理的保障流程？

相关的产品人员，分析现状问题，发现梳理需求方案，确定最终方案思路，因为方案太大无法一下子搞定，所以将方案细化成一个个有趣的故事地图，为各个团队描述我们如何磨刀霍霍的一步一步将大象关进冰箱里。

拆分完成的故事地图任务很多，为了保证产品能够如期的完成，有我们的协调人员组织大家开一个计划会，群策群力，都说说自己怎么办，怎么干，需要花费多少时间，最终根据时间节点，将任务按照优先级进行排列，田忌赛马的方式，优先完成核心功能，辅助的功能随后以迭代或者其他方式来完成。

产品人员根据梳理出来的实施内容，准确的向实施团队（开发、测试、运维）描述主旨，保证实施方向不偏，然后实施团队开始着手，圆环套圆环的方式将所有的任务列表中的内容完成，并逐步发布到生产服务器，最终完成交付产品的目的。执行过程中，每日的站会可以让大家互相周知我们彼此在干什么，协作起来有了知根知底的前提。

产品发布前，通过回顾评审会，向产品人员演示我们的产品成果，评审成功，产品最终发布，然后进行反思大会， 积极的开展我党的批评与自我批评大会，让整个团队气质高昂起来，优点发扬，劣势规避，积极的为下一个版本的产品做好处。

这个流程简单来说，可以理解为敏捷研发的scrum：三角色：PO、SM、DevTeam三工件：产品地图、任务列表、完成报告五事件：用户故事地图梳理、工作计划会、每日站会、回顾评审、反思会等。

协作流程中，开发、测试、发布紧密的结合在一起，这部分的工作是否高效，直接决定了整个项目协作流程是否能够通顺的走下去。而这部分的工作就是平常所说的持续集成和持续交付的主要核心 操作对象：永远存在代码仓库里面的“代码”

1、研发人员在自己的本地环境开发代码，开发完毕后，将代码推送到代码仓库。

2、没人敢保证自己研发的代码不会出现问题，所以为了保证代码能够在生产环境正常运行，所以将代码先后拉取到公司开发环境、测试环境、预发布环境，对代码进行不同级别的测试和验证，最终保证代码处于随时发布的稳定状态。

3、运维人员，将经过层层测试保证的稳定代码，拉到生产环境中，部署成功后，开放相关的权限，最终用户可以看到相应的效果了。

4、整个流程，纯手工来做的话，眼就瞎了，所以为了省事的同时也提高工作效率，做了如下两个动作：将所有的代码获取流程、代码的部署运行流程自动化 -- jenkins之类的持续交付工具。将所有的环境标准化、流程化、实现基础环境的快速呈现 -- Ansible、Saltstack 实现配置的统一标准化管理，Docker、Kubernetes实现业务应用环境的快速标准化。

DevOps来了

思路虽好，方案虽好，架不住团队里面有坏人，总想着有人要害朕。所以一个个部门领导要宣誓主权，导致部门之间出现各种交流障碍，最终害人害己。

因此需要一种软性的交流思路，能够打破不同部门的协作思路，推己及人，互相理解，于是DevOps来了。

用户访问流程：用大家最常见的场景作为入口，理解团队协作的时候，都干了什么。

文件查找流程：我看到的文件，是怎么找到的？他保存在哪里？

文件产生流程：我们看到的文件，都是怎么产生的，有什么区别，都是谁做的？

加速访问流程：页面效果好不好，谁说的算？ 客户。那么客户对什么感兴趣？时间。

基本访问流程：用户在浏览器输入域名，通过互联网找到对应的主机，主机上的应用程序找到到处是空白窟窿的文件，通过程序机制到后端数据库获取数据，然后再空白窟窿的文件里面填充，形成完整的页面，最终返回一个完整页面数据，完整的页面数据，在用户浏览器渲染成一个完美的页面。

问题：

我怎么知道要找的主机在这里？

我怎么知道要找的文件在哪里？

我怎么知道页面到处都是窟窿？

我怎么知道可以从后端数据库获取具体的数据？

我怎么知道获取到的数据，可以填补空白页面中随处可见的窟窿？

查找主机流程

根据互联网的域名管理系统，解析出来网站的服务器ip

因为群众里面有坏人，所以为了安全，不让所有人看到真实的服务器

根据用户的请求，由反向代理服务器将请求转交给真实服务器。

全球的根DNS实例1381个（截止到今天），由12个根dns运营商来管理，每个DNS实例的服务器数量未知，我们国家有37个根DNS实例（图中数据没有问题，因为它把越南的3个算到了香港的那个区域中）。

用户在浏览器输入的地址主要有三部分组成：

域名 - 解析为ip地址，目的是找互联网上的主机地址端口 - 请求的服务在服务器上以端口的样式作为唯一入口。url关键字 - 请求的资源到底是什么，根据这个关键字有程序来识别。

nginx web关键查找url关键字流程

通过server配置段内部的listen监听端口接收用户请求，根据location匹配的关键字，查找对应的资源对象，到root指定的目录下找index匹配的文件。

Django web程序查找url关键字流程

nginx反向代理请求给Djangoweb应用程序，应用程序的路由系统匹配路由关键字，交给后端的view视图系统，views视图系统根据request对象识别相关参数，按照内部的函数逻辑对数据进行整体处理，借助于后端的数据库引擎基于模型类从后端数据库中获取数据，根据render函数找到到处是窟窿的模板文件，然后基于context的属性将数据和模板整合为一个完整的页面。然后原路返回给nginx程序，经Nginx软件，将数据返回给用户浏览器端。

要创建页面，就要了解页面的表现样式，目前互联网上的页面样式，主要有这么三类：移动端的上中下结构，浏览器端的上中下结构，浏览器端的左右上下结构。

样式虽多，但是生产的方式主要有两种：干脆利索：直接在后端生产完整的页面，最后统一返回给用户方便快捷：先返回页面框架，根据实际的情况，通过大量的局部请求，逐渐获取页面中的部分数据

整合样式1：web程序端的项目代码逻辑，先获取模板文件，经由ORM工具从后端数据获取数据，通过render函数将数据和模板整合为一个完整的页面，返回给用户，在用户端进行正常的渲染。

整合样式2：将之前后端程序一个人做的事情，拆分为两个地方来做，前端程序和后端程序，前端程序通过axios等方式，根据情况在用户发起局部请求的时候，从后端获取针对性的数据，然后再浏览器端逐一的加载到一起，最终形成一个完整的页面。

所谓的用户体验，就一句话，用户访问的时候，越快越好，享受山大留学生的皇帝后宫式体验。网络上的用户体验策略多种多样，我们直接从页面本质上入手。

如果一个页面中的子文件对象少一点，页面加载的速度就会快很多，因为没有资源获取的等待+阻塞时间了。

每个页面都有自己的域名地址，如果大部分的文件都在同一个域名下，后面的资源就无需重复的域名解析，使用dns缓存记录，可以大大提高文件的获取效率。

页面中的子文件对象存放在不同的主机中，如果一个在河南，一个在荷兰，那么获取的方式就很慢。但是如果所有的文件都在同一个局域网中，那么所有的文件获取的速度就会非常快。

所以基于 减少页面对象、减少域名解析、使用同构网络等方式，可以从根本上实现页面高效访问的目标。

虽然页面的优化策略非常多，但是我们主要是从页面访问流程来描述不同岗位的协助思路，所以其他的优化策略，不再我们的思考范围中。

岗位协作梳理

Q：为什么这个项目的访问流程中，没有过多的描述产品岗位和测试岗位？

A：研发出来的产品样式和流程就是产品人员设计的，研发之前产品人员已经和研发团队彻夜进行心连心的交流了。

只有研发出来的代码，才会进行代码质量测试，只要能够给用户看到的，都必须经过测试人员的火眼金睛的找茬能力校验。

因为这两个岗位的职责清晰，所以我们没有过多的描述，主要集中的体现在了研发和运维的角度。

Q：用户访问流程有什么重要的？

A：就是很重要，这个流程都不理解，我们怎么互相达成一个普遍的认知，而且这件事情就是我们做事情的根本。

Q：用户访问流程有什么重要的？

A：就是很重要，这个流程都不理解，我们怎么互相达成一个普遍的认知，而且这件事情就是我们做事情的根本。

Q：页面的查找流程，研发人员和运维人员的定位是什么？

A：主机的查找流程，涉及到 DNS的解析、TCP/IP的三握手四断开，nginxweb软件的配置、反向代理的配置、真实web服务器的部署和管理，这些都是运维人员的 核心竞争能力。

页面的查找流程，涉及到web软件的配置、反向代理的配置，这些是运维人员的岗位需求。后端django程序的页面查找是研发人员的主要岗位要求，内部代码的逻辑不通，何以通全程？

Q：页面的加速流程，不同岗位人员的定位是什么？

A：页面加速流程是一个综合性的项目维护过程，涉及到哪些页面应用需要进行加速、用户对哪些应用页面感兴趣，运维团队采集数据，产品团队进行功能梳理或者版本功能计划。

Q：怎么进行页面加速策略实施？

A：运维团队采集数据，研发团队实现多种静态化的方案，最终由运维团队来落地。

Q：为什么对页面本身的业务逻辑对象来进行加速访问策略？

A：这些东西对于研发人员或者运维人员来说，都比较好入手，好处理。

Q：还有没有其他的策略可以让我们更好的完成页面的加速流程？

A：有，不同的岗位都会有自己的思路来完成这个任务，但是很多人不愿意干，因为没有动作，就没有伤害。

编辑：jq