我报名参加金石计划1期挑战——瓜分10万奖池，这是我的第8篇文章，点击查看活动详情
从今天开始我将学习《前端架构师》这门课程，后续所有的文章都是对这门课学习的心得体会，如果对您有帮助不胜荣幸。
软件开发生命周期
软件开发生命周期(Software Development Life Cycle，SDLC)包含了软件从开始到发布的不同阶段。SDLC旨在通过最少的资源，交付出高质量的软件。为了避免产生严重项目失败后果，软件开发的生命周期通常可以被划分为如下六个阶段：
需求收集
这是整个周期中其他阶段的基础。在此阶段，所有利益相关者(包括客户、产品负责人等)都会去收集与待开发软件相关的信息。对此，项目经理和相关方会频繁召开会议。尽管此过程可能比较耗时，但是不可急于求成，毕竟需要对将要开发的产品有个清晰的了解。
利益相关方需要将收集到的所有信息，记录到软件需求规范(Software Requirement Specification，SRS)文档中。
在完成了需求收集后，开发团队需要进行技术方案设计，以确定项目是否能够被完成。
设计
设计是项目开始前的必要环节，在这个阶段首先进行技术调研，以确保需求能被技术所实现。
在调研过程中，需要考虑成本与时间的因素，对于某些技术可以采用购买第三方服务的方式，不必浪费时间自研，从而耽误项目的交付。如果第三方服务满足不了项目需求或者购买成本较大，这个时候就可以考虑自研。
在设计阶段，需要编写技术方案设计文档，一般软件项目包括前端和后端，因此设计文档可能包含如下文档：整体技术方案文档，前端技术方案文档，后台技术方案文档。如果某个需求比较复杂而且重要，可以单独编写一个技术方案文档。
技术方案设计中，可以利用伪代码的形式对其中关键技术进行模拟实现。如果拿不准，可以在本地跑一个demo，看其效果能否满足需求。
同时，也会产出 UI设计稿。
最后，组织各个相关利益方对技术方案及UI设计稿进行论证，以确保能满足项目需求。这个过程可能进行多轮，但是是必不可少的过程。在论证的过程中，前端和后端技术人员需要深度参与，特别是对其中难点能否实现做一个大致评估，不要等到开发进行了一半才发现实现不了。
软件开发
在此阶段，前端和后端开发人员依据软需和技术方案文档进行开发。
后端开发人员负责构建数据库结构和其他必要组件。最后，由前端开发人员根据设计去构建用户界面，并按需与后端进行对接。
在配套文档方面，用户指南会被创建，源代码中也应适当地留下相应的注释。也就是说，为了保证良好的代码质量，适当的开发指南和政策也是必不可少的。
测试
专门的测试人员协同开发团队在此阶段开展测试工作。测试既可以与开发同时进行，也可以在开发阶段结束时再开展。通常，开发人员在开发软件时就会进行单元测试，以便检查每个源代码单元是否能够按照预期工作。
注意，测试人员在需求收集阶段就要参与进行。试想，如果一个测试人员对项目整体都不了解是不可能做好测试工作的。
部署与维护
完成测试后，我们就需要通过部署软件，来方便用户使用了。在此阶段，部署团队需要通过遵循若干流程，来确保部署流程的成功。
维护作为开发周期的最后阶段，在修复方式上，我们既能够采取立即纠正错误的方式，也可以将其作为常规性的软件更新。
此外，软件项目团队还会在此阶段从用户处收集反馈，以协助软件的改进，并提高用户的软件使用体验。
项目管理的生命周期
项目管理绝不仅仅是指工作项目，任何一件事情都可以当成一个项目来管理。如果你有这种思维，我相信你的生活一般都会过的比较好。
上面讲了软件的生命周期，它被包含在项目管理之中，只是其中的一个重要环节。那什么是一个项目管理的生命周期呢？可以通过一个图来说明项目管理的全周期。
在管理流程中，需要特别注重三个阶段：
-
需求阶段：此阶段一定相关各方都参与进来。当PM把需求文档写好之后，需要组织需求评审会，并在需求定稿之后各方要签字。同时，开发人员也要参与进来，以熟悉整个业务，方便后续开发。
-
技术方案设计阶段：此阶段对上一阶段的需求进行技术可行性分析，保证在现有资源的情况下能用技术实现需求。在此过程会编写技术文档，并对技术文档进行返回论证并签字确认。
-
开发阶段：在开发阶段利用每天站会，周会等形式，协调开发中的问题并追踪，同时要对可能产生的延期风险或者技术风险随时跟进与汇报。
下面我们对这三个阶段重点展开，如下图：
-
一个项目的产生首先肯定为了解决一个痛点，有了痛点就产生了需求，互联网公司都会有PD这个角色(product design产品经理)，产品经理就开发出对应的产品来解决这个痛点，这个时候就会产生一个PRD文档，在文档中还会画上原型图。
-
接下来就是架构师的工作了，根据PRD文档编写技术方案，技术方案包括：技术的选项，技术的架构，API的定义，技术的调研，评估技术的风险。
-
写技术方案的目的是为了确定这个需求是可以被实现的，然后PD就根据技术方案来评估这个项目是否要继续进行。
-
如果项目的成本等各个因素，都是可以被接受的，那么这个项目就正式立项（kick off），同时确定项目经理，开发人员等。
-
然后确定计划排期，确定时间点，然后细分各个里程碑，即什么时候联调，什么时候测试，什么时候上线等。
以上的这些阶段叫项目设计阶段。
以什么角度来进行需求分析
如果你是这个项目的负责人，你该从什么角度来把握整个项目需求呢？
答案：以架构师角度来进行需求分析。
下面从一道面试题开始，来看看什么是以架构师角度来进行需求分析的。
你作为前端负责人，来开发一个 h5 页，某个抽奖功能的运营活动，如上图。假定 PM 和后端 RD 都是实习生，技术和业务都不熟练。你要从 0 开发这个页面，你会要求 server 端给你哪些接口和能力？
多数人的答案
所有人都能想到，需要一个抽奖接口。否则，他就不是一个合格的程序员了。
很少一部分人能想到，需要一个用户信息接口，否则都不知道奖品给谁，总得登录一下。或者直接输入手机号抽奖也行，但需求没说这里有手机号。
还有，假如刚刚抽了奖，再重新进入界面，是否要禁用抽奖？是否要限制每个人抽奖一次？这些需求没说，但这些很重要，这些可都需要后端支持。
架构师的答案
- 获取用户信息（同时判断是否登录）
- 如果登录，判断该用户是否已经抽奖，以判断他是否还能继续抽奖
- 抽奖接口
- 可能还需要调用登录接口
- 当然也可以直接输入手机号抽奖，需明确需求
- 埋点统计
- pv
- 自定义事件
- 微信分享
由此可见，一个看似简单的功能，其背后并不一定简单。因为需求它包括浅层需求及深度需求。
浅层需求是指一些看得见的主要的功能；深度需求可以理解为让用户或者运营人员更加方便使用软件的需求。
比如现在有个需求：用户登录。
浅层需求就是登录，但是深度需求就是登录有几种方式，可以用户名和密码登录，也可以是短信登录，也可以是第三方登录(微信，QQ)，还有就是登录的验证，登录的安全性问题等等。
你看一个简单的登录，就可以衍生出这么多深度需求。
因此，对于需求的理解不是考察知识点和技术能力的，完全就是在考察你对一个业务的理解能力。
由此你就可以看出，程序员对于需求和业务理解能力有多么重要！直接会影响到你的 API 接口设计，进而影响到你的开发。
有些时候，PM 和 RD 比较靠谱，他们能考虑清楚整个流程，你也就顺利的完成了，这很幸运。
但大部分情况下，你都会遇到一些不靠谱的人，或者太忙没空理你的人。这个时候就要靠你去承担起来，而你有没有这种能力呢？
在你抱怨别人不靠谱，抱怨需求频繁改动的时候，你有没有从自己的身上找一找原因。
如果你是老板，你如何看待这件事？你是否希望你的员工都深入了解业务？
能联想到的还有很多很多……
技术架构设计
对技术架构的理解
首先我们先来理解下面两句话:
第一句话：任何看似复杂的设计，都是让整个系统变得更简单
在我刚入行的时候，公司的高级工程师搭建了一个项目的工程目录，里面包含了很多文件夹，甚至一个文件夹里面只有一个文件，然后这一个文件里面可能只有几行代码。我当时就非常的不理解，为什么要费劲为了这么点代码还要专门新建文件夹来管理，然后通过调用的方式来使用，直接写在使用的地方不更加简单吗？
当我写了几年代码后，才明白这么设计的目的：看似任何复杂的设计，都是为了让整个系统在后续开发和维护中变得简单。刚开始你直接写在使用的地方确实很爽，但是随着项目的变大，如果不拆分就不好管理和维护，导致后期迭代非常困难。
第二句话：技术永远都是为业务服务的，技术是实现业务增长的工具。脱离业务的架构就是耍流氓。架构师必须要深入理解需求、参与需求、看透需求背后的业务本质。
通过上面对需求分析的了解，需求分为浅层和深度需求，只有彻底了解了需求才能写好技术方案，不然你都无法设计你的 API 接口。总结一句话：需求指导设计，设计指导开发。
确定项目边界
这一步就是确定项目的范围，确定范围是做任何事情的第一步。
范围确定好了，剩下的事情，即便有问题，也属于"人民内部矛盾"。该购买第三方服务，还是该自研，或者该放弃，就看实际情况了。
比如说，ToC的项目通常有一个用户使用的网站项目，有一个运营人员使用的管理后台项目（包括一些统计服务），可能还要开发一个监控平台供开发人员随时了解系统的运行情况等等。
知道了需要开发多少子项目之后，那么还要用流程图把各个子项目之间的关系画出来，方便开发人员理解整个项目。
核心数据结构
每一个项目都会有一个最重要的需求，针对这个需求设计你的数据结构。比如：你现在做一个低代码的项目，用户在通过拖拽的方式创建了一个页面后保存到后台，前端该如何传递这个页面的数据结构呢？后台又如何存储呢？
这些核心的数据结构，在技术方案设计之初就要明确下来，因为这是这个项目中最主要功能。
如何写技术方案设计文档
不知道怎么写文档
通常大部分同学不知道怎么写技术文档:
为何难写？
- 没有规范可依
- 不常写
如何写？
- 随性一些，解释一下你要如何做，即可
- 可以先尝试写一部分代码，捋一捋思路，再来写文档(这里写代码纯是为了捋思路、为了写文档，搞清楚目的)
写设计文档是浪费时间吗？
- 如果你真的想明白了，最多浪费你 1-2h 时间，不会导致项目延期
- 如果你写不出来，说明你没想明白，正好暴露了问题
文档目录
-
需求背景：可以把需求文档贴上
-
范围：整体设计
-
模块设计
- 模块拆分和关系图
- 各个模块的功能解释
- 特殊模块说明：组件库、统计服务
-
核心数据结构设计
-
扩展性保证
- 扩展组件
- 扩展其他功能，如大数据分析和计算等
-
研发提效
- 脚手架
- 组件平台
-
运维保障
- 线上服务和运维服务
- 安全
- 监控和报警
- 服务扩展性：基于云服务，可以随时扩展机器和配置
