泛亚电竞 泛亚电竞官网大型公司开发软件的流程是怎样的？
时间太久，不为本文中的任何一句话的线年的时候刚刚加入搜狐，刚刚有工作经验7个月，很快就开始做白社会的项目。
那时候开心网的偷菜正火，Facebook如日中天，Twitter刚刚起步，新浪和搜狐刚刚在博客上打的热火朝天。
同组的师兄刚刚从搜狐奥运组撤出，刚刚经历过奥运高峰期的考验，特地分享了架构，可惜当时才疏学浅，大部分都只能听一个皮毛，当然现在也很菜。
方老大带着我们做SNS，Mark带着琳姐，吉子哥他们闭门会开了好久-据说是好久，反正多久我不知道，我是小兵兵一个，这些都是后来他们告诉我们的。
终于他们决定了，要做白社会。从他们决定做白社会开始，就决定了太多人一生命运的改变。
用我六年前的话来说，就是在白社会的时候，没觉得有什么，可是在现在看来，60人的团队有条不紊，如同军队般整齐，条理清楚的做一个项目，是多么难得的一件事情。
这就是我经历过的最大的项目了~跟众多大牛比起来，大概微不足道，但是对我这种小兵兵来讲，回忆起来已经是感慨万千。毕竟当年的白社会团队，60多个人，最菜的就是我，其他人几乎全部是各个一线公司的CTO，副总裁，核心架构师，CEO等等等等。
我记得很清楚，要做这个项目的时候，第一次参加项目动员会，也是到今天为止最让我受震动的一次动员会。
熊杰那个时候是PM组的Leader（后来一个新浪的朋友说，她们在做微博的时候，那个时候其他行业都没有产品经理这个岗位，新浪就有了。听我有点目瞪狗呆，这么算起来搜狐有产品经理这个岗位比新浪至少多了两年吧？）
做的PPT很漂亮，怎么漂亮的我不知道，反正就是讲一个人，经受着各种各样的压力，然后早上七点起床，开始挤地铁，上午被老板骂，下午被客户骂，晚上十点又要挤地铁什么的。
然后说他们需要一个地方，让他们释放压力--虽然我到现在都没太明白，一个单纯的网站能够释放这么多压力么？
然后，Mark他们定了一个很清晰的框架，这个框架，在未来半年到一年内，几乎没有变过。
整个网站的功能，被分解成三个模块。FrameWork，App，Common，到现在我都在延用这种模块结构。Framework是白社会的主要框架，Home，User什么的都在这里。App是预留的网站的应用，如真心话，池塘边等。Common是公共服务，邮件啊IM啊通知啊神马的都在这里面。
两人一个组，做一个小的功能模块。吉子和琳姐好像军中大将，总共差不多十几个组。每个组领命而去，两周或者是三周交工，嗯，这是后话。
我在之前的项目中，用到过一点点的Maven，琳姐给了我任务，让我给大家讲一下maven.第一次技术分享就奉献给了白社会的团队，还是有很多东西不太懂，可能也讲不清楚，但是收到了申总的鼓励，说我讲的知识点可能不够深，可是条理很清楚，能像我一样把东西讲清楚的人不多。
当时的敏捷开发还有很多不完善的地方，但是已经给我留下了很深的印象，除了敏捷开发，我想我大概以后不会采用任何的开发流程了。
特别是需求评审的时候，我记得很清楚，琳子和吉子他们会争的很厉害，为了一个功能要不要做，有没有必要做，经常会吵得非常非常凶。可是我很喜欢这种氛围，很喜欢他们思考问题的方式。
印象最深的一句话就是：琳姐说，为什么要花费80%的工作量去满足了1%的用户的需求？池明想了想，说：可是用户会因为这1%的需求得不到满足而离开。
这个问题我到现在都在思考，虽然我现在思考的角度有了很大的不同，但是仍然会遇到同样的问题。
嗯。特别是在做方案评审的时候，我在一周之内，为了拿出一个为用户推荐二度好友的功能，做出了7种方案。
读研的时候我们的老师就说，我们那个年龄，22岁~28岁，是最容易出成果的年龄，现在想想也确实是，如果再次能回到那个年龄段该有多好，如果你在看这篇贴子，如果你处在这个年龄段，好好珍惜吧~
方案评审比较随意，不太在乎格式，只在乎能否把事情讲清楚，把要做的事情列清楚。我的第一次方案评审，也是交给了搜狐。
这是一件很开心的事情，那么多技术大牛告诉你方案中哪里做的不合理，告诉你需要怎么做，怎么解决高并发的问题，怎么去做算数据量，怎么去估算占用的内存大小，怎么去利用缓存，怎么去防止数据不同步。
Demo也是一件很开心的事情。整个搜狐的团队，没有测试。是的，搜狐60多人的研发团队，没有一个是测试。所有的程序员，自己就是测试。我们能确保，每一组工程师，做出来的程序，在Demo之后，几乎是零Bug的。
这是一个通用的，封装了缓存的DB访问框架。无数次我们都讨论过开源事情，只是一拖再拖~到现在，嗯。
申总和康总负责这个框架的研发，是的，你没看错，在我们做项目的同时，他们只比我们早启动了不到两个月。
Tuscany是我至今仍然非常喜爱的框架，非常非常喜欢。Tuscany的设计哲学很经典，很开阔，又很简洁。看完Tuscany之后，再看Dubbo，有点无法忍受这种山寨版的Tuscany，虽然Dubbo有他自己的优点，也是国内很多公司正在使用的东西，但是几乎 没有什么思想，或者说我已经掉进Tuscany的坑里面根本不想出来了。
不仅仅是Tuscany的使用，Tuscany本身并不支持负载均衡。神一样的花了两周时间，重新写了一个Scallop的框架，用于做负载均衡。
嗯。当时还没有Zookeeper，即便现在有了，我也更喜欢Scallop这种简单直接明了的方案。
ActiveMQ确实有很多坑，我们遇到过不少的情况，折腾了好久才把他搞定。
用ActiveMQ来做解耦，也确实是让代码简洁了很多。比如说用户注册，要算积分，要算推荐，要加好友，要初始化任务，要做很多很多事情。这些东西，用JMS来解耦是最合适的。
而且还封装了Tuscany和JMS组件，这是我一直很佩服的地方，这些开源框架，在这些大牛手里就是一个个可以任意组装的玩具，三两下就明白别人怎么做的，然后自己要怎么改进。
Erlang的语法也是真心醉了，如果不是看过一点Drools，还真的。。学不会。
白社会用Erlang来做五子棋，那时候对Comet也是一知半解，直到后来自己用Comet来做在线多人扫雷的时候，才深刻体会到重新打开Http连接是一件多么废时间的操作，才真正转向到WebSocket-可惜，白社会那时候没有WebSocket。
Groovy用在了任务上，用户接受任务，完成，领取奖励，这些东西是通用的，但是每个任务的完成机制不一样，所以我们需要一个轻巧的，简单的动态语言来解决这个问题。
嗯。后来我在我们自己的项目中，把Groovy用到了后台统计各种复杂的计算公式算法中，可以在线编辑。
而这一切，丝毫没有影响整个项目的开发进度，这么多人做出来的程序，几乎是没有Bug的。
要上线之前，苏菲设计了一版粉红的UI，还有一个冬天雪人的UI。我更喜欢那个雪人的设计。
先是开始内测，内测的时候，很快就发现了Feed里到处都是加好友的信息。然而，以我的感觉来看，搜狐内部其他部门对于这个产品，几乎是带着嘲讽的角度去看的。
并不会如我想像的一样，大家都是搜狐的员工，出了一个新的产品都会去开开心心的用，然后开开心心的提问题，大多数都会说：这什么鬼东西，怎么设计的这么烂？
不过，白社会大部分的时候口碑都很好，UI的设计，交互的体验，简洁的功能，都是我做过的系统中最舒服的一个。
公测之后，对于绝大多数的人，白社会的口碑都很好。特别是生活在别处，特别是小白这种亲切的称呼。
后续又出来了白社会小报，池塘边，梦幻城，绿光森林等几款很有特色的产品或者是游戏。
只是当时大家所谈的都是一件事情，想要复制开心网偷菜应用的成功，所有的人都认为，白社会只是缺少一个杀手级应用。
他们说，当时新浪在做新浪朋友。然后搜狐抢先上线了白社会，当白社会出来之后，新浪朋友的团队直接解散，放弃了新浪朋友，转做微博。
嗯。我不知道具体是怎么样的，白社会的产品研发团队都很赞，可是在运营上，在大的方向上或者还是差了一截。
只有北京的公交车似乎有过白社会的痕迹，搜狐主页上曾给白社会留过一个很值钱的广告位。
当时，白社会也是没有运维的，运维是和洪涛两个大神负责。每周二，每周五，半夜十二点，每一个项目的工程师，都在自己的电脑面前，完全不需要聚在一起，完全不需要在一起加班，只需要在自己的家里，电脑面前，等着说一句：发布了~检查一下有没有发布成功。然后开开心心的等着晚上第一个使用的用户，检查有没有问题。
白社会战友群，写的是那些年，你上过的白社会。群里大概80多个人，有很多是在我离职之后才加入的，现在都混的很好很好。
一旦聊成了，他们就会进入下一个阶段，聊不成他会想方设法让你答应，然后进入下个阶段，知道我为啥叫
，不了解的点也会去了解，测试，开发，UI我们都会在会议上提出自己的观点，自己的意见，然后等产品反馈，最后意见一致之后，产品当天就回改出敲定版本。UI就会按照产品爸爸的意思去作图，接下来就是交互设计评审了。
这个环节会比较快，只要UI按照之前敲定的逻辑开发，出入不会很大，一般都是小改。
但是也不乏很多，之前敲定了情况，等UI按照敲定版本出了图，但是却发现出图之后有些不合理的点，比如是否应该在这里展示GMV（销售总额），或者是否这样展示活动规则啥的，会有这种情况，不过是小概率事件，改动也不会特别大。
，这个是大厂程序员需求下来之后基本上都会做的一步，不过看需求大小，可能很多小需求直接就详细设计了，也有啥设计都不用做的小改动，具体需求具体分析嘛。很多不了解的同学可能会问，需要设计什么呢？为什么要设计呢？
，你用了技术之后你是不是需要列出他的优点缺点，出问题之后的解决方案，还有可能出现的问题，注意点等等。这么是为了让你能有把控力，比如你这个需求接入了新技术Es
Elasticsearch）你什么都不管你就是要接入它，你把他开发好了上线了，但是有啥坑你知道么？上线崩了怎么办？不主动，不拒绝，不负责，这是渣男的行径，我们需要负起责任。
这个环节你需要考虑这个需求涉及到哪些服务了，需要新增哪些接口，修改哪些接口，表有现场的还是要新建表，字段要新建么？
其实远远不止这些问题，这就是我们做设计的主要原因，也是大家工作里面能成长的途径之一，你以为大佬们的经验是怎么来的？
瞬间高很多，形成知识体系。概要设计一般就是做个大概，给大家看一下我自己在设计ES相关的需求的时候的概设，比较粗糙看个大概就好了：
，比如你涉及哪些服务，新增了哪些接口，改了哪些接口，都是要同步出来的，至于为啥？是因为测试会依据这个数据，评估影响范围，方便他写测试用例，后面会提到。
？傻瓜，简单呀，见名知意嘛，概要设计是大概的设计，详细设计是详细的设计。
我们研发的时候整个流程往往很复杂，如果你理解不对直接就写代码，最后容易造成返工，延期，加班，被骂，心情差，回家吵架，离家出走，露宿街头，饥寒交迫，被迫吃野味，然后全国。。。。
，其实大家花点时间做详细设计很有必要，你思路完全清晰了，写代码那就是分分钟的事情，不是嘛？那再看看帅丙的一个小设计吧，之前文章中大量的流程图，时序图都来自它，
这个环节一般上不需要Leader参与，但是如果你有疑问或者不了解的点还是要提出来的。
测试用例，主要是为了把改动点影响点都考虑到，测全一点，免得上线了影响别的现有业务，也是为了把你开发的功能可能出现的bug给排除了。
这里有个小细节还是想说一下，一般开发前我们都会提前定义数据类型，接口名称，然后在公司的接口工具上给出链接和参数，方便前端爸爸mock数据。
他总不能等我们后端开发完了，才去开发嘛，这样效率打折扣，所以都是后端先定义好，然后前后端并行开发的。
Tip：日常环境不能由开发人员发布，是因为测试流程比较久，所以不能中断，如果你一直发布会影响测试的效率，在发布期间他们是没办法干活的，而且很多部门涉及相同的服务，你发布还会影响别人。
测试发布之前，在测试群里问问可以发某个服务么，大家觉得不影响，那么就可以发了，懂了吧。
预发环境，也叫灰度环境，这是跟线上数据一样的一个环境，只是只能内网访问，一般这一步是防止很多是因为日常的数据量不够真实，数据级别达不到线上的量级无法测出的bug。
过来人的经验你就说香不香吧，以前老大经常没时间，但是我就是烦着他要Review，后来他说不用review了，但是我还是要组员大佬review，因为我很享受别人对我提建议的时候，这不就是成长，扫盲的好时机嘛。
但是如果你BUG多，那我觉得你可能会生不如死，因为有的bug真的找很久很久的，调用链路又长，特别是跨服务又涉及消息队列，或者第三方的接口什么的。
我们开发一个需求，可能涉及到N个服务，这些服务是有依赖关系的，那就需要打包，比如订单系统，依赖人员系统。优惠券系统，也依赖人员系统，然后订单系统还依赖优惠券系统，是不是有点乱了？
现在都是分布式的集群，这样发无疑会累死，我之前负责的系统有50多台机器，一般都是4台4台发布。
知道解决了再发布，顺利的话就没啥错误，一口气发完了，看了下时间凌晨了，那发完差不多也得回家了。
一次发布可能涉及服务多的话，真的有可能发布这么久，但是没办法，线上出问题就是掉脑袋的事情。
对自己设计的严苛也会让你的业务能力提升，开发考虑的点也越来越广泛，我想大佬应该都是这样走过去的，那没啥好说的，我们也走。
最后给大家看看我自己搞的一个项目管理模板吧，基本上能适用大部分项目了，要xmind格式的公众号回复【
答主在2016年写了这个答案:写工业级别代码是怎样一种体验？, 当时也比较年轻，基本上是以抱定“工业标准一定是宝贝”的心态写的那个答案，可以说当时答主对aSPICE和ISO26262 part6 的流程推崇备至，然而这些年渐渐有了些新的感悟。
答主这几年也是比较坎坷，公司换了两家，部门换过四次，在中、美、德、英四个国家的汽车软件部门工作过，见识了不同的流程和文化，令我惊奇的是，所有这些公司、部门和项目，有一点是相同的：都是世界前五名的汽车零部件供应商哦，居然
完全遵循了aSPICE和ISO26262 part6流程...关注我的不少童鞋也在汽车行业：有一家算一家，甭管您是国内的、国外的，国企还是外企，传统车厂还是新势力，主机厂还是零部件，有哪位能告诉我你们是严格按照这两个流程来开发软件的？我真的很想知道。
这就说明问题了。我开始思考，也许不是这届项目管理不行，而是这些流程出现了一些问题，已经不太适应现在的汽车软件开发，特别是HAD（Highly Assist Driving）大背景下汽车软件的开发了。在此，我想结合我的项目经验，谈一谈我理解的实际的软件开发流程。事实上，我们很多部门已经开始在做这方面的实践，并取得了不错的成果。
首先，结合我自己的专业，我想谈的是汽车行业里大型（超过一百万行代码）、重大安全系统（safety-critical system）软件的开发流程。业内对此有已经两个流程标准：ISO26262 part6 和aSPICE。前者现在是发布汽车相关软件必须遵守的标准，而后者基本上只有大众、戴姆勒等几家德国车企才强制要求（从我和他们打交道的情况来看，我都很怀疑他们自己内部遵不遵守这些流程..）。
关于这些流程的扫盲贴可以看这个答案：写工业级别代码是怎样一种体验？， 相关细节这里就不重复了。
这并不是我凭空生造的，而是我在实际项目中部分实践过的流程，很希望在这里和大家交流。
无论是ISO26262 part6 还是aSpice，它们的核心都是“V型开发流程”，说白了就是个变形的瀑布（Waterfall）流程。
一旦软件计划或者资源上有一点变动，比如需求临时变更，或者架构师被领导临时抽调，那真的是产生连锁反应，整个项目后续都受影响，最后就是无穷无尽的加班。再者，现在市场的实际情况就是，
V型流程建立的基础都快没有了。现在HAD功能大量上马，OEM们争分夺秒逐鹿蓝海，别说造车新势力，就是传统主机厂，也是不可能等到功能完全想明白了、写好了再把完整的需求文档给你的。往往都是先搭个框架，有个大致想法，需求就发布了。紧接着就是一遍一遍的沟通、测试、修改，大家都在抢时间，每周都有新功能进来。就这，你还指望软件需求有冻结的一天？！做梦呢。往往是上一版刚冻结，后续还没展开，新需求就又来了，所有人都崩溃。第三就是
。这个问题很影响项目实施，但我从来未见有帖子认真讨论过，所以想多写点。很多关注我的童鞋都是业内人士。我想问问你们，在实际情况里，上图的6到11这些环节中，您觉得那个环节最重要、薪水最高、最有意思、领导最重视、最容易升职/跳槽啊？毫无疑问是7和8，架构设计和功能单元设计对吧，没悬念嘛。那么哪个环节或者职位最不受重视、薪水最低、最无聊枯燥、最不容易跳槽啊？6软件需求/需求工程师啊，完全没职业发展嘛。大一点的企业甚至干脆外包了对吧，咖喱味的需求有没有？
事实就是，做软件需求工程师和测试工程师的童鞋，但凡有经验、有能力、有机会的，都会努力转成控制工程师或者架构师，这家公司转不了，哪怕跳槽也要转。说句得罪人的话，您公司里的需求工程师，是不是相对来说，都是对产品不那么熟悉、经验不多，或者水平欠佳的同事在担任啊？
然而，要命的是，按照V型开发流原本的定义和初衷，最最重要的职位恰恰就是需求工程师。需求是一个项目的根本，是项目执行的第一级，可以说一切的一切都是围绕软件需求展开的。一个水平欠佳的需求工程师，不到位的理解和水平欠佳的需求文档，往往会给项目带来灾难性后果，有些甚至是后期弥补不了的。我想这一点童鞋们或多或少都有体会。
在讨论完弊端以后，为了改进流程，我们要明确一下V型流程的核心，把它们保留起来，取其精华去其糟粕。
和2. 建立完整的可回溯性。这两点是一定要保留下来的。否则在软件发布以后，根本就没法通过ISO26262或者aSPICE的验收审核。>
分层次的测试，也就是单元测试（Unit Test）、集成测试（Integration Test）和硬件在环测试（HIL Test， Hardware in the loop），这些是必须的，没法省略也没法变动。但是，为了提升流程的灵活性，在文档的完整性和可回溯性上，我们可以适当做一点妥协。V型流程要求每一步骤都要时刻建立完整的文档和可回溯性，然后才能进行下一步骤。根据实际项目经验，我认为，这一要求可以放宽到“在成熟软件发布的时候，具有完整的文档和建立可回溯性”。用通俗的话讲就是从制度或者
，或者说，“文档、代码一起写”。当然，这种妥协一定有一个前提，就是项目团队有充分的沟通和项目组长有清晰的框架，从我的实际项目经验来看，这是不难做到的。
为了解决传统V型流程的的弊端，我在项目实践中引入了一些敏捷开发的元素，比如Scrum master，Sprint，Kanban Board等等，这里我们暂且先不讨论这到底是“真正的”敏捷开发还是只是借用概念。
在成熟的软件发布时，用新流程开发的软件同样具有完整的文档、完整的可回溯性以及完整的分级测试报告。新流程完全不影响原有的项目审核和质量控制。2.新流程右侧（测试侧）不变，而
。各个步骤从原来的次第进行变成以Sprints的形式齐头并进，最大限度地提升灵活性。下面我详细阐释一下新流程。
项目组长扮演Scrum Master的角色，组织例会。例会上需求工程师、架构师、基础软件工程师、应用层工程师（控制工程师）每人阐述本周的进度，对新需求或新修改项达成一致认识。这种认识是通过非正式的形式，比如口头沟通、演示来达成，并通过email和会议记录的形式（而不是冻结的完整文档）明确固定下来。随后组长明确这周的任务，并设置关键结点，形成一个Sprint，每位工程师开始完成自己规划的任务，发现问题快速反馈，这是并发的。
当关键结点到来的时候，再次例会，组长查看进度并根据新需求制定下一个Sprint的任务。这样随着Sprints的进行，最终会形成完整的需求文档、设计文档和代码，同时完成可回溯性文档。随后一切就和传统V型流程一样了：交付集成工程师进行集成，随后进行各级测试。
为了实现这种新流程，软件团队的人员架构也需要做一定微调。项目组长与需求工程师、架构师、基础软件工程师、应用层软件工程师组成一个敏捷开发小组，而软件集成工程师和测试工程师需要在敏捷开发结束后才进场工作，不再属于某个开发小组，而是为所有小组服务。
。组长一定要有能力协调好已经发生的任务冲突，并且还要有能力预见未来的冲突；另一方面，由于每个工程师的任务毕竟是模糊定义的（没有冻结的文档），组长要有全局掌控的能力，并和每位工程师流畅沟通并确认工程师已经充分了解自己的任务。可以说，
是能否实现新流程的一个要点。不过我的参与过的项目中，这是实际实现过的。而我自己也做过项目组长，新流程并没有复杂到无法实现。
，新流程灵活性大大增加，窝工情况缓解。每位工程师在每个Sprint的开端就（以“模糊”、非正式的形式）明确了自己的任务——如前所述，这种任务以Email、会议纪要的形式固定，以和组长的沟通来保证正确性——不必再等待自己前级的输出。就算架构师消失一周，其他工程师照样能写自己的代码/文档。架构师消失只会影响他自己的进度，最后只有架构师自己加班而不是拖累全员加班。
新流程不必等待需求文档冻结。客户给一点我们就做一点，客户要改、要加料，研发团队可以从流程上随时奉陪，非常契合现在造车新势力和自动驾驶相关研发的节奏。
，新流程一定程度上可以弥补需求工程师的缺位。在String的执行中，任务分配可以比较灵活。原来由需求工程师承担的任务可以分配一部分给其他工程师。比如与客户的沟通、技术谈判，对需求的分析和确认等等，如果需求工程师能力足够，则这是他的本职工作；如果需求工程师能力、经验欠佳（这是普遍情况），则这部分工作可以分配给架构师、控制工程师来完成，而让需求工程师退化为一个把文字打进DOORS系统里的打字员或者文档整理员...（这也是从我们的项目实践里无奈的总结出来的）。新流程也有着他的劣势。比如，高并行意味着对
都提出了更高的要求，无论是经验、技术还是团队配合都要求更加严格，这无疑对企业是一个新的挑战；特别是项目组长，更是一定要由经验丰富的员工担任，导致小企业里可能没有足够数量的员工能够胜任组长。然后，组长如果消失了，比如病了、或者跳槽了，对项目会有相当大的打击。您别说这例子还真发生过。曾经有一次一个项目组的英国组长连续休假三周（不得不说欧洲人假期就是多....）,导致项目进展缓慢，气得客户打电话过来骂人.....不过这应该是企业整体考虑的问题，比如设置第二组长等等。
这篇文章我想写给有一定基础的汽车软件从业人员，所以中间如果有解释不够细致的地方还请见谅。也可以留言提出意见让我修改。在此答主也是抛砖引玉，希望和大家共同交流～
同学说参数太多，嗯嗯，俺虚心接受，想了想，把 theBoss 改成全局的了。
v 1.02 把传值的 std::list 改成std::list&，本来想传常引用的，不过想想还是算了。这个捏其实也是照顾广大还没用上 C++11 的同学的习惯，C++11 通常是 std::move 进来就可以了。
我比较熟悉的针对金融行业的J2EE软件，通俗来讲，就是给银行保险公司投资公司等用的核心系统。这个领域除了互联网金融，其实电子化率很低，银行稍微高些，其他的保险公司也好，基金公司也好，很多中小型的，甚至真的用excel而已。原则上，和这些公司工作，流程基本上都是：
首先做售前和销售，这个时候多少会演示下系统，有的公司还会给你几个功能尝试下，这个叫POC。然后签合同，合同一般是分步签的，这个不细谈。
签完合同，给客户上课，把基线系统给客户演示，然后客户根据他们自己的需求，提功能需求，这个阶段叫workshop。
然后业务人员针对客户需求，写功能文档，当然，还有一部分非功能要求，叫做NFR，这是由架构师负责的，还有专门的集成部分，因为金融系统大多很多年，通常有十几个系统互相集成， 这些都写完，开始设计。
设计阶段主要分三个部分，概要设计，这个部分是看整个系统是否要大改动，比如我现在正在做一个项目，要把常用框架升级到Spring全家桶，这就在概要设计部分展开。
然后是底层设计，这个部分会写伪代码和功能测试用例，用来给开发中心进行编码。
在开发中心编码的过程当中，还要采用CI的概念进行开发质量管理，直到提交。
代码完成了以后，提交发布，放到测试服务器进行人工测试和自动化测试，直到符合标准。
之后是客户SIT，这是系统集成测试，放到客户环境，和客户其他系统进行对接测试，看看通讯是否成功。
然后是UAT，这是客户的最终用户进行测试，用他们实际业务当中的行为进行操作。同时也是对他们的培训。泛亚电竞 泛亚电竞官网泛亚电竞 泛亚电竞官网
扫一扫关注AVIA ESPORTS泛亚电竞微信公众帐号
