前言
有时候要做一个项目的时候，如果不梳理清楚项目的开发流程，只一味的想着想要开发什么什么项目，就很难下手，就算提起状态去进行开发，开发过程中也会遇到种种困难，导致项目进度缓慢，如果是个人项目，还常常会放弃掉。因此在开发项目之前，对整个项目的开发流程的梳理是一件很有必要的，也能提前为做一些技术调研和准备。
开发是整个项目流程中很重要的一部分，但在一个项目中， “开发” 只是其中一个环节，还需要其他部分来组成一个完整的项目流程，本篇文章将从开发的角度来梳理我对项目完整流程的认知和思考。
项目开发流程
一个项目的大概流程如下：
涉及到开发的相关流程梳理：
上面的流程图不一定准确，实际情况更应该根据团队的情况、项目或需求的体量等等因素进行调整。
思考
在说项目的完整流程之前，作为一个开发者，我先说一下自己对技术的一个认知。
以前听过一个很经典的原则：STAR 原则。
这个原则对我的影响还挺大的，在不知道它之前，我总觉得技术才是王道，不需要去了解太多业务，在那之前就一味的学技术，但很多时候学了也忘的很快，因为技术并不是独立存在的，它依赖业务，也需要有相应的产出，不然它创造不了价值或者创造的价值过低，也就容易失去意义。
所谓STAR原则，即 Situation（情景）、Task（任务）、Action（行动）和 Result（结果）四个英文单词的首字母组合。—— 百度百科
“STAR 原则” 可以映射到现实生活中的各种事情，每件事要做好，一般都需要有始有终，中间也有需要做的任务和具体的行动。
对于一个项目来说，它可以对应上项目的生命周期：
- 立项(Situation)：即 “情景”，立项肯定是有一个背景的，不会无中生有，否则就是异想天开了，立项过程也会确定我们要达成的目标，因此立项往往包含两个部分：背景、目标。
- 任务(Task)：项目确定后，那就需要划分任务，比如产品部门需要负责产品的设计、UI负责产品的样式效果、开发负责实现产品的功能、测试负责验证产品的质量等等。
- 行动(Action)：各个部门去按照各自的任务行动起来，完成任务，项目上线，并运行起来。
- 结果(Result)：项目上线后，不管怎么样，都会有一个结果，有可能达不成预期目标，也有可能超出预期。
如果把它再划分细一点，对于一个每一个开发任务来说，也可以带着 “STAR 原则” 去思考和梳理。
比如我需要开发一个通用按钮组件，也可以划分为以下四个步骤。
- 背景(Situation)：设计稿制定了按钮的设计规范，为了提升开发者效率，复用按钮组件和保持按钮风格统一，因此需要开发一个通用按钮组件。
- 任务(Task)：这种任务一般指定一个开发者即可，任务就是开发一个通用、扩展性强的按钮组件。
- 行动(Action)：制定实现方案、编码实现、团队内推广使用
- 结果(Result)：提升了团队成员开发效率等
生活中其实也有很多事情都是可以按照这个原则去思考的。
比如我要去旅行，那么旅行过程也可以按照这样来思考：
- 背景：我很想去那个地方，或者只是我单纯的想出去走走也可以；
- 任务：为了更好的旅行，那么我的任务就是：做攻略、做准备、去旅行；
- 行动：行动起来，做好攻略和准备，然后开始这段旅行；
- 结果：旅行完，达成了我的目标或者没有达到预期。
不管做什么事，如果想要把一件事做好，那么就去多思考，越复杂的事情，越需要把它梳理清晰，这样才会让复杂变得简单，简单到一定程度，就可以让我们的思维更好的去理解。
最后
本篇文章先是梳理了完整的开发流程，然后由开发流程触发了我对 “STAR” 原则的理解和思考，并结合项目流程和具体开发某个功能的流程进行了简单的验证，希望能给大家带来一些帮助。
最后再说明一下，本篇文章的思考纯属于个人的经验思考，中间的逻辑不一定符合读者的逻辑，每个人都有自己独特的思维，读书学习是借鉴他人的思考，然后按照自身的理解取其精华，去其糟粕。
欢迎👏大家关注➕点赞👍➕收藏✨支持一下，有问题欢迎评论区提出，感谢纠错！
本文正在参加「金石计划」
