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：为什么这个项目的访问流程中，没有过多的描述产品岗位和测试岗位？