Loading... 这个是前两天在年级群水群的时候聊到的一个话题，当时顺着说了几句，感觉挺有意思，然后就一直到了**编到了**后面 CI/CD 流水线的部分。 回到住处之后，想了想，好像还能继续说下去，就又补充了几条。内容不保证严谨可靠**（因为本身就是编的，就是为了形象说明各种职位是做什么，以及起到什么作用而已）** <div class="tip inlineBlock info"> **创作声明：内容包含虚构创作** 内容中的情节存在虚构加工，仅供参考 </div> --- > Q：在大厂写代码和平常写代码有什么区别？ > A：想象一下你写软构 lab3 的状态 > Q：难道这就是软构这门课存在的意义之一 > A：补充一点，你把软构lab3想象成小组项目，然后你的角色是“组长不写代码”的小组里面写代码的组员。这样更准确 > Q：感觉这样比单人项目还顶 > A：在这个小组里面，负责计划做什么功能的角色（比如你的“不写代码”的组长/老师）是产品（PM），产品对项目进行管理和决策，以及需求的统筹。 > A：然后，别人写完代码之后，会有一个人截图、写报告，描述程序功能并且试用（测试）的人，这个角色是测试（QA，准确翻译质量保证），测试人员负责验证功能是否满足需求，以及一些和质量有关的规则的制订和实施。 > A：如果你们组比较有理想，可以拉一个有艺术品味的人，或者去树莓忽悠一个人，帮你们设计一下程序的界面。这样的角色是设计（UX），会负责系统界面的设计（原型图），以及交互的设计等等。严格来说还能细分，但是这里就不展开了。 > A：这些都是组里不写代码，但是对于项目有参与贡献的角色 > A：想象一个场景，你自己一个人做项目。写完之后还要买服务器、域名，配置解析，配置环境，打包构建代码，上传项目，部署项目等等一系列步骤。你的目的是开发，但是要负责很多“让开发出来的东西跑起来”不得不做的东西。这个时候，如果你有了一个小组，就可以单独选出来一个人，让他专门去做这些事，每当有人想要部署的时候，给他说一声，给他代码，他帮你跑起来，这个角色就是运维（OP）。细分的话不同层次的运维（比如集群、物理机、虚拟机、网络、系统、应用等等）是可以分给不同人来做的，但是这里统一概括为运维。 > A：他干了一段时间，感觉每天都是重复性的操作，想着，为什么非得人来干？于是写了一个脚本。以后每次部署，他登到服务器上，运行 `./deploy.sh`，然后坐在一边刷一会手机，环境就部署上去了。后来，他又想着，反正一直要部署，干脆每次有代码更新的时候，直接跑一遍部署脚本不就行了？于是通过版本控制或者什么工具，当有提交发生时，自动构建然后部署到指定机器。他实现了提交之后自动的构建与部署（CI/CD 流水线） > 你作为开发，感觉不乐意了，这么有用的东西，为什么只能运维一个人自己用？两天前测试找你说上个版本还没这个 BUG 朝你要环境；昨天，另一个开发说找你要一份能跑的代码，因为改动比较大，想单独搞一份做测试。既然按照流水线整个步骤（构建&部署）走一遍，就能得到一个独立的环境，那么为啥我不能给旧的版本重新走流水线？这个思路做下去，只要机器管够，就算不懂代码的人，也可以随时调出自己希望用的那个环境版本去用，而且彼此互不干扰。 > 你同学看到你们组欣欣向荣的开发情况，想进来取取经。这东西让他白嫖不合适吧，所以你想让他们帮你写代码。但是他们没有你们组这么聪明，代码经常有 BUG，所以就算提交了代码，也不能直接进入仓库，万一不小心混入了系统传承下去了呢？于是你在他们提交（commit）代码并且推送后，强行加入一步，让另一个人审查一遍代码（同时，也会有一些机器检查，比如代码规范性等），只有当这个检查的人也认可代码的正确性的情况下，才能进入仓库。这个过程就叫做 代码审查（CR：Code Review） > 向你取经的人越来越多，很快，开发这里就越来越乱，只在 master 上做开发已经满足不了你们了。每个人迫切的希望有一个不被打扰的开发环境，而不是每天打开电脑第一件事拉取 master，合并本地冲突。这个时候，分支开发主干发布就是一种选择。每个人在自己分支上开发的过程中不会受到他人影响，只需要在最后合入 master 的时候跟进版本，然后解决一下冲突就可以。而后来，你感觉如果只用 master 做发布，记不住线上版本是不是最新代码，也不希望代码合入之后紧接着就被发布，发布版本要有控制。于是另外起用了一个叫做 deploy 分支用作部署，每次发版的时候，移动 deploy 到最新位置，标志线上版本。这样，就变成了分支开发，分支发布。（分支开发：每个人在自己需求的分支上开发。分支发布：单独一个分支控制当前发布版本）（常见的有三种实践方式：分支开发分支部署、分支开发主干部署、主干开发分支部署，各有优劣） > 老师感觉你们做的很好（别忘了一开始说的，这是一门课的作业）。希望你们能上线~~割韭菜~~，新的问题来了，开发的人都是标标准准的理工科学生，和机器打交道不是难题，但是和人打交道，却实实在在的犯了难。机器说一就是一，但是人不养，对于人，你得让他用的舒服才行。这怎么让用户喜欢用？怎么留住用户？就需要有专门负责运营的同学来帮忙了。 > 运营提出方案，开发将他做出来，这样配合非常完美。但是活动不能一成不变，运营隔三岔五要改文案和图片，过个几周可能要上线一个新的活动，开发时常要分出心来去做这些文案和图片上的修改。一来二去，开发感觉烦了。每次就改几张图片，换个文字换换颜色，为什么非得让我跟着做。这个东西让运营自己去改就行。开发们一协商，既然你要时不时的改广告位的广告，那么我单独给你做一个“XXXX系统广告管理平台”不就行了？这样你直接在你的平台上修改就行，前端由后端读取最新的设置进行展示。经过短期的开发，运营和开发实现了分离，终于又可以各干各的了。这样的 XXX 管理平台就叫做运营中台（区别于后台） > 运营说：之前的那个平台好是好，但是我还想有一个按照用户性别查询用户列表的工具；还想有一个筛选未付费用户的工具；还想要统计一下每个人……(╯‵□′)╯︵┻━┻。~~鲁迅说，一切服务离不开 CRUD~~，你们开发一合计，运营需要的界面不就是各种表单组合一下的 CRUD 吗？那干脆做到底，把各种常见的表单都预设出来，然后拖拖组件就可以形成一个新的运营系统。如果真的需要一些复杂的逻辑，有后端参与一下对接 API 也就够了，极大的节省了人力。这个东西就叫做低代码开发平台。 --- 背景：软构 Lab3 为软件构造课程实验三，单人项目。代码量较大且因为位于期末时间比较紧。核心代码大约 20~30kB，算上界面 50+kB，或者这个量翻倍也有可能。（界面不是必须） | 缩写 | 全称 | 含义 | | :-- | :-- | :-- | | RD | Research and Development engineer | 研发工程师，通常意义上的开发人员，有时特指后端 | | PM | Product Manager | 产品经理 | | QA | Quality Assurance | 质量保证，也可以说是测试 | | OP | Operator | 运维 | | UX | User Experience | 交互设计/用户体验设计 | 注：有时 RD 特指后端，此时对应前端是 FE。另外 NA 可以用指原生开发。 https://baike.baidu.com/item/%E5%90%8E%E7%AB%AF%E5%B7%A5%E7%A8%8B%E5%B8%88/53137396?fromtitle=RD&fromid=1112812 最后修改：2022 年 07 月 28 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏