| 导语 希望在未来的一段时间，有一些对于软件开发体系的认知，把这一个月的感受，总结在这里跟大家分享下。未来一段时间，我会找机会跟项目经理进行交流，看他们是，如何做开发体系的优化，以及问题的分析与解决。
这里没有立场，没有非要对错，希望抱着开放的方式，去讨论观点。
好多年，其实也不是很多年。看到了企鹅一个人的分享，有一句话让我印象深刻——“我们的核心价值是对软件开发体系的认知”。最近正在做的一个需求，大致分为如下的几个阶段，准备在逐步的尝试开发中。
写这个的目的是，自己感受一下产品开发流程：
会有这个阶段，不过这个阶段我并没有参加 ，应该是技术leader，产品leader，以及项目经理共同讨论，如何确定需求优先级的高低，毕竟需求永远都是做不完的。是的，因为80%的需求都可能是没有什么意义的，但是，想找到那20%有意义的需求，我们就必须做到100%的事情。运气好，遇到不坑的队友，我们就能做出可预期的产品。这里的可预期是，我们大致是知道产品迭代到什么程度，有多少用户，用户的使用场景，使用重心等等。毕竟，大环境不差的话，预期是比较明确的 。这里，做出的决定，希望同步给大部分人，我们需要知道，自己在整个布局的哪一个环节，处于什么位置，才能去思考能做什么，该做什么，怎么做？
要让每一件事情，更有预期，做这个需求的目的，能带来多少价值，价值是什么，什么是可衡量的价值？
价值导向是什么，什么是价值导向，核心价值是什么，附加价值是什么，不要为了做而做，不要为了堆功能而堆，不要因为别人有，我们就必须有。有是为了什么，能创造多少价值。价值如何衡量。
竞品对比，同类型产品的流程设计。这个设计一定要分析，并且邮件输出。
竟品的流程是如何做的！做这个的目的是为了防止产品遗漏一些核心功能。比较反感产品说照这个做，一听到这个话，我就想骂人。就算是抄，我们也专业一点。最起码，大家互相尊重一下。这个做了，至少，能保证80%的问题不会遗漏了。
当leader们决定了要做这个需求，那么需求优先级就确定了，产品会进行标准流程的提单，标准流程 会标记为需求宣讲！会出一个类似的流程和一个设计师做的静态页面的标注。然后进行宣讲，拉上终端，后台，前端的同学进行需求宣讲，包括端，以及后台的技术负责人；宣讲之后，确定各个端的技术owner。由owner牵头进行技术方案的设计；leader 进行跟进和评审。宣讲的阶段是一个熟悉需求的过程，也是熟悉人的过程，知道谁跟你配合，找到关键路径。通过沟通，建立合作方式。
补充： 这里建议产品在宣讲的时候应该准备一个流程图，或者产品架构的功能图。每一个模块的分支、功能点，要达到的效果和路径。最好有 Axtrue rp 画的动态的演示图。至少，也建议有一个流程图，这样会减少沟通成本以及后期做的需求有不完整的部分。开发只需要按照功能图上面的功能进行开发，就可以了。
如何减少需求宣讲的中间地带，灰色地带，开发不明确，产品模糊。最后都甩锅。这不行啊，这需求宣讲的时候，必须有细节描述。可追溯的方案架构图和流程图，产品的设计思路和产品的功能描述，细节到用户操作。拒绝忽悠，共同成长。
- owner 统一完成设计、整理技术方案，前端、终端、后台进行邮件同步；
2）确定时间，进行评审，宣讲时拉上产品和各端的开发，以及技术owner、团队技术负责人等，一起进行技术方案评审，产品查缺补漏，检查技术方案有没有达到产品所提出的功能，并且提早发现技术和产品在某些特定问题上，理解不一致的问题。方案评审的时候，希望要多思考，多观察，如果你处理的好的话，可以减少自己很多工作量，当然，我想描述的不是为了减少而减少，你的工作量本质上肯定不会减少，因为你的时间是固定的，一周五天，减少的是没有价值的工作，让工作更有价值，因为，不同的需求，创建的社会价值是不等价的，也许，技术难度对你来说都是一样的。这里，产品需要review方案设计的功能点是否达成一致。这是一个关键的里程碑！
这里 owner 并不一定能够完全承担owner的责任，因为，对于不同项目的熟悉深度，专业背景，因此，owner 更多承担的是一个上下 沟通 的纽带。即使反馈问题，我个人感觉，owner做到一下几点会是一个比较好的返回式：
1、承担自己方向工作的整体流程的串联，至少信息流的串联。
2、对负责内的项目同学，具有一定的影响力，包含：
1）方案评审：不必要事无巨细，但是，需求清淡需要过一遍，细化功能点，防止遗漏和理解不一致。这里，owner同学的要为自己未来的发展锻炼项目管理能力和需求评审能力。
2）人员沟通：某些同学遇到了困难，如果owner能解决，就解决，不能解决，就要找到相应的人去解决，比如要了解对应接口人是谁。至少对组织比较熟悉，关键路径要尽快确定下来，防止同学走弯路。遇到问题无法推动。
3）项目跟进：需要在里程碑节点的时候，找到相关同学合适问题是否达成，每天需要进行沟通，查看项目是否有进展。遇到了难点等。需要多做记录。为多个owner在一段时间之后，进行项目复盘，找到开发流程上面的弱点。进行合理化的优化。
4）日常问题：对成员进行帮助和实际开发中的关键性建议。
5）总结：跟进项目的大小和人员的多少，进行不同类型的总结沉淀。
二八原则，百分之80的问题，我们一定可以花20%的时间发现。然后，在去优化和解决他就可以了。因此，总结规划，有时间我们在更细化的讨论一下这个议题。
这个流程，是为了减少成员对问题理解不一致的过程，尽早发现问题，可以减少开发成本，完善架构设计的一个过程。并且上大家都参与进来，了解产品开发的整体流程，从中提升自己的视野和对产品的理解。
把需求拆开进行分解，由负责自己部分功能的开发同学，自己评估开发时间，并进行排期；技术owner检验开发同学的排期——是否标准合乎要求，当然更多的是为了检查是否有遗落的点（这一点非常重要，这是开发前最后一次检查错误的机会了。错过了，风险就会很大。）。因为很多时候，由于新人对业务不了解，导致会遗漏很多东西。这个很正常，甚至，由于产品没想清楚，乱写需求，某些重要分支没有表述清楚，开发中的时候才发现。都是很容易在未来产生返工或者延期的风险的。
因此，owner 和 leaderr一般都是有经验的老员工，这一点来看，团队稳定是一件很重要的事情。对不同阶段的产品。增长期的产品，越稳定的团队，产品提升速度原则上，相对越快。毕竟员工离职，吃进新人的成本都是需要花时间，我大致感受了一下，消化一个新人的成本至少是1-2个月，多的甚至是3-6个月的成本，无缝衔接的人比较少。不同团队差异化也比较大。消化不仅仅是技术，还有人本身的消化，团队成员的熟悉程度，上下游业务关系。团队30个人，扩大40个人，很可能都需要一年的样子，吃进来要消化，一次性吃进来太多问题也很多。因此，团队成长是一个长期并且持续性的建设，不是一下就能达成的。有序和长远的思考如何去建队，是对组织最大的帮助，合理的优化组织流程和模式，价值并不比技术的方案看起来低，长远看来这更重要，因为在我看来，技术是有边界的，很多前端工作5年+的老同事常说，他的前端已经到头了，到头的是某一些前端单点技术，不是管理才能，管理永远没有尽头，未来，要花时间思考团队建设的方式和流程，这个流个引子。
在引出一个我相对认同的观点，但是我相信目前大部分互联网产品的核心矛盾是——产品形态和产品架构问题。不是技术问题。
原则上是来说，开发同学在发布提测的时候，或者预发部的时候，进行需求宣讲和方案评审。尽量保证开发同学，手里不要并行事情，如果需要并行，尽量也不要超过2件事情，不是为了提升开发同学的能力，核心问题是，单线程的效率是相对较高的。思路的切换成本是很高的，当然这是理想状态。达到这个理想状态是艺术，达不到是正常的。
补充：这里架构设计之后的进行排期，排期的是按照产品给出的功能点进行拆分细化后的架构点。这个时候，需要有整体的架构图出来，做为项目沉淀和交接文档沉淀。文档需要按照项目和功能进行沉淀，无论是团队wiki，还是git 中的doc目录，都是可以的，按照一定的组织规则进行设计。当然，我说的这种产品是长线产品，不是一锤子买卖。
已经开始开发了，完成了一天的需求，解决了一个问题。邮件同步了工作状态。这边没有站会，领导不参与站会。因此，同步进度的工作就是邮件和标准流程的整理了。
美好的经历总是会不期而遇的发生，因为之前处理的一个项目出现了问题，需要排查了解决问题。那么，跟产品沟通，确认优先级。确认之后。进行处理。比如，我这次是上次的需求更紧急，那么，我就停下手里的需求去处理，你可以理解为类似于现网问题，当然不是，如果是，优先处理现网问题。
开发阶段的最重要的首先是技术栈了，如果不符合技术栈，就像我这样，需要花点时间学习，不过前端还好，现在的前端技术对我来说够用就好，我也不想花时间研究前端技术了，什么打包、构建、组建框架、这东西有技术含量，但是我实在是不感兴趣了，够用就好，拿来主义。因此，能满足业务，不求甚解。生命宝贵，做点自己喜欢并且自己认为有意义的事情。
首先是——接口协议，一个有意思的议题——面向架构的编程，尤其是对于稳定的业务尤其重要。类似ToB类型的服务——高级管理系统。产品形态还是挺重要的，就像我今天在做的这个需求，PC教师端的题库。技术类型就是 react + mobx，这里页面也要前端自己写，有的公司有重构，嗨，这边都是自己搞。不过，正好体验一下大前端的开发方式，体验这个词会不会觉得很随意，其实就是体验。不体验，怎么能想办法把全链路的给闭环——完成闭环很重要。
所谓面向架构的服务就是设计的合理性，应对产品各种无聊的需求，大部分需求都是垃圾，只有20%有意义，这是我们对于产品和用户的不理解，产品能力差，驾驭能力不足，导致了我们花了80%的时间去应对80%有没有都一样的功能。这在产品平稳期是经常遇到的。对于这些无聊的需求，你又不得不做，然后就发现，面向架构的编程有多重要了。
但是，目前我达不到这个水平，但是未来我会朝着这个方向努力。回到实际操作本身，先完善接口，把接口写清楚，可以保证功能的完整性。方便开发同学联调。并且沉淀成文档，为后续项目持续迭代和项目交接提升效率。接口 即 契约，要有契约精神。面向架构做不到，就先面向接口的编程吧，其实，面向架构上一层，就是面向服务的编程，阿里的双十一的架构把我惊艳到了。
站会 —— 一个快速的进度沟通和快速反馈问题的工作方式，站会伴随这白板和贴纸。项目经理通过这些进行需求管理和人员的进度的同步。站会的时间要控制，人数也不要过多。这样，其实会影响大家的时间。这个因团队而已，看看多少时间合适。我拍脑袋给一个时间，控制在7个人之内，15到20分钟。目的：同步进度，阐明风险，协调资源。是否有白板和贴纸，还是采取大屏幕电视机的标准流程，这其实不重要。能满足你的需求就可以了。人数超过15个，我建议就搞会议，然拆开需求，进行扁平化的管理，核心ower + 成员。分开开会，节省时间。
开发阶段对问题的处理，选择就因人而异，我喜欢自己憋着搞，实在不行了在问人。嗨，这样你会发现，你会花很长的时间去解决问题，每个人的选择不一样吧。磨练一下意志力还是好的，并没有特别多的问题，我们解决不了，程序员的世界，从工程的角度，用时间的确可以把差距抹平。多加一点班，这些问题就都可以被解决。因为我相信，在未来不是什么时候，都有人，并且有时间能帮助你的。所以，珍惜目前的团队。
开发阶段和产品以及后台的合作。
如何跟产品沟通，如何面对需求，这是我来到这里需要学习的东西，在未来，我想我也可能会成为一个产品，因为技术做到头了。在可控的边界内，技术的确是有终点的。但是，在此之前，我需要站在产品的角度来看今天的我——一个开发，额，我的确做不到。希望，能在这里找到一个相对平衡的点吧。定个小目标，我希望我年底能做到吧，那就只能，倒逼自己快速成长吧。
开发阶段，关注：排期，协议，风险，可控！我们不是为了明天上线做这个需求，我们是为了上产品变得更好，我们不是为了做需求而做需求。我们对于产品来说，我们开发是工具没错，但是，我们得把自己当成产品的主人，有理由在做的过程中更了解产品本身，优化这个产品。然后，在可控的风险内完成这个功能。关键词：契约精神、风险可控、预期交付、持续开发。
这里可以补充一个点，对于技术的同学，有追求是一件好的事情，但是，如何在日常需求中加入技术需求，如何实施，可以想想。如何结合产品发展，伴随着个人的技术发展是一个很有意思的话题。这个有机会，可以展开来聊聊。既然，说到这里了！
那就还需要补充一个关键词：可持续发展。
联调在重点感觉有几个方面：
第一，协议！这个是最重要的。
第二，新功能，是否能实现。老功能，是否支持（风险）
第三、产品目标和开发同学理解不一致，出现返工，或者，修改代码，导致系统不稳定。
协议非常重要，面向契约的编程是目前行业最简单的开发流程，有一天，后分享说全链路日志还需要推动的时候，我震惊了。这在很多团队都是基本能力，甚至基本能力都不算，大家都认为这是必需品，而不是有没有还需要讨论的事情。很多时候。组织太大了，沟通成本太高，需要引入更多的学习机制，保证团队能够和潮流接轨，我说的潮流不是求新，求快，潮流是理念，一种向前的开发方式，拿来主义不是没有意义，拿来之后，改造，接地气并且不断优化的开放方式，会让组织更有意义。工程师，技术只是进入这个行业的手段，但是，重点在哪里，每个人的追求和未来可能都不一样，但是，重点是要慢慢培养起来团队的职业的态度和做事情的方式，契约化的精神是一点一滴积累起来的。那么从接口开始，进行实践。
剩下两点的风险解决，来源于沟通，让产品更早进入体验的流程中是一个很重要的方式，发现预警。将需求切开，更早的引入产品体验。一个大功能不要最后产品在体验，那出了锅。完全都是开发背了。每一个阶段的里程碑都需要产品介入体验。提早的把风险和产品问题同步出了。
在开发的时候，我们都希望需求更可控，但是这是理想状态下，
1）就比如我这种新同学；
2）做一个功能，很多东西大家都不确定一定可控；
3）以及改造现有老的业务逻辑，遇到不可控的问题。
没有做过的事情，深浅不知道，那悲剧的可能会很大。因此，需要有方法论的支撑，通过方法论去看待这个需求，尽量变得可控。这里也映射出一件事情，就是稳定的技术形态很重要，不仅是稳定的产品形态，对于技术的沉淀和积累都是需要时间的。
现有的人和产品的天花板在哪里我们不知道，现有业务的架构的天花板在哪里我们必须清楚。
联调中发现测试环境不稳定的问题，几乎在很多团队中都存在，有这么一种情况其实更糟糕，我体验过和某些团队对接的时候，我的测试环境，是他的开发环境和测试环境。这是一种什么感受，是一种浪费声明的感受。说的没错，浪费生命的感受。
如何解决这个问题？最好的方式目前想到的是全链路的docker虚拟化，把正式环境的数据同步到docker稳定的测试环境。让测试环境和正式环境、开发环境、预发布环境隔离。进行全链路的节点式的虚拟化。为每一个开发者构建一套完整闭环的测试流程。由于是给开发构建的全链路的测试环境，并发不会很高，而且，会有很多服务是公用节点。开发只要构建自己的服务名称就可以了，以名词服务的形式，构建起开发模式就可以了。
这个能力服用性很强，按照BG去做，就可以了。机器的性能优化在这个时代意义不是特别大，当然，做肯定是要做了。但是，这个时代更大的问题，是流程优化和改进。这种优化所带来的价值，将会更大。因为，流程这个问题在各个团队都存在的问题，而语言所对应的技术站，在每个团队是不一样的，大家选择的技术方案是天上地下的，今天你对C++ 内核 做了很好的优化，但是，另一个团队Java是JVM。完全不相关啊。
但是，流程化、组件化、方案评审、调试问题、沟通成本、反复的迭代，安全、灰度、预发布、发布环节的检测，如何防止漏发，防止乱发，快速回滚，以及产品的质量体系建设等。这些都是公司内部团队通用的，甚至所行业通用的一些方式和方法论。这些东西，才是第一步要做的，有了规划之后，然后才是单点技术的突破，起到以点带面的作用。
目前大部分业务，后台能做的，前端都能做，而且，开发效率还能更快。而且，由于ToB的业务，使用人数也不是很多。使用开发效率高的语言反而更好，让后台做更底层的业务，封装出通用的中间件，专注提供开放API，提供更强大的并发能力和计算力。由于协议是向上兼容的，数据有多少，前端接口可以拿多少，这样，node层会拿到所有数据，前端通过node进行外部接口成的数据控制。就可以了。
现在团队的测试方式是，将测试优先级分为 P0到P1；开发自测P0。就类似如下列表，这里并不需要关注内容，因为这个标准，按照每个团队的标注定义就行。
开发自测，进行P0的自测。需要注意边界问题。需要owner把关。需要好的责任心和意识。对边界问题的处理。如何更好的自动化测试，也是一个很重要的议题，这个以后有机会可以调研一下，不过，想做出成绩，还是非常难的。
P0测试之后，进入开发提测阶段。
这里，我还是想提出，需要产品更早的接入到体验环境，而不是在测试阶段进入。产品需要在开发阶段就应该进入体验环境，保证开发没有问题。尤其是阶段性的里程碑。目前，看到的开发完成这个阶段进入，肯定就有需求不明确的地方了。一定会有，而且不仅是我这个新人，老员工也是一样！！！
【当然有同学也会反对这种想法，关键看如何把需求更细粒度的拆，拆到可以让产品介入体验，开发又觉得产品不烦，并且能保证，最快的速度纠错。】
项目经理在群里发了这样的话。对于稳定型产品，这样迭代的话，会有点意思。这里，我想超出范围的聊一点产品问题，其实不应该在这里扯的，但是，为什么扯，2点！
一点：是测试阶段的确是开发需要松一口气的时间了，一般开发阶段都会很累，加班比较多，这个时候，需要适当的放松和环节一下。但是，放松的阶段不是不工作，一方面是改BUG，另一个是总结，这次开发中的得失。最后，就是发现问题，在流程优化和技术优化的道路上是永无止境的。因此，这个时候，需要反思和总结。
第二点： 28原则，不是说每次都用1天时间复盘，凡事不要过，要有度！但是，又不能不复盘。不要为了做而做，但也不要不做。首先评估的是产品需求是否合理，有多合理，产品那些点在需求启动的时候，没有提出来，开始开发的时候，为什么会遗漏这些。沟通在什么地方出现了问题，不要每次都这样，我怎么感觉大部分开发都跟我抱怨这个观点呢？不是说，抱怨对错，而是，减少抱怨，提升的是效率。
因此，第一、产品复盘！那些没开始的时候提出来，为什么没想清楚。首先我不想从开发的角度上去拿刀砍死产品，NO，我希望和产品共同成长。相同的产品形态下面，下次是不是不会想漏了。对于探索类型产品，我理解，产品形态不固定，产品天马行空乱搞，开发陪你玩，可以。但是稳定性产品，形态固定，流程想不清楚，不要作，不能改关键流程，包括主流程的按钮状态， 因为，这是核心点，非探索性业务，开发不应该在已经开发阶段加需求，除非老板需求。因为，这样产品很不专业。我不是为了为了挑战产品，是希望大家共同互相促进，提升自己的核心价值。产品也要成长，如果一开始就想清楚了，产品会越做越顺利。反而，想不清楚，才是悲剧。
第二个是。测试阶段修复BUG，这个在所难免，人之常情。写不出BUG的程序员，不是好码农。都是一步一步成长起来的，慢慢坑自己。以后越坑越高级。保持耐心就好，尽量减少错误。保持好耐心，持续努力就好。当然，犯错误越多，意味着个人成长会变慢。不是这么讲话，是因为我是开发，就对开发就可以容忍，同理产品也是一样，需求更改的越少，产品就越有时间做附加值更好的事情。技术优化，这个阶段做技术优化是一个不错的点，在开发过程中，会发现问题，在开发的过程中没有解决，这个时候闲暇了，可以进行优化，提升下一次流程的效率。
第三个是、项目总结和架构设计总结。我认为团队应该有这样的储备和沉淀，每做完一个大型项目的时候，应该进行分享和沉淀，第一个复盘设计的是否合理，是否有优化空间，第二个是，进行总结和沉淀。我认为产品形态是相对稳定的，那么技术方案也是可以借鉴的。因此，这个，在成熟的团队就必须要做！这个可以优先让一些要答辩的同学进行分享，如果同事都搞不定，怎么搞定评委。因为同事更温柔。也可以帮助新同学分享，并且项目架构更加通用和完整，架构设计尽量做到扩展。
第四，我这里单独列出来吧，我不接受产品跟我说，你按照这个做，或者设计说，你按照这个做。我认为这是不职业的体现。当然，如果这个组件如果已经是团队成型的，经常被使用的，不再这个范围。但是新的组件和新形态的表现形式，必须要做出来，别跟我说按照XXX做，这是一种对工作的羞辱。我承认能力有限的问题，可以接受，但是态度问题，我没办法容忍。
这个阶段产品新增了需求。其实需求的更改是伴随着整个测试过程的，目前团队的流程大致应该已经完整的体验了。差不多就是这样的环境。
白盒测试，自动化测试，这个能力测试同学应该具备这样的能力啊！！！把测试工具和测试流程完善起来，这么搞，自己效率也低啊，把测试用例保存好，以后做增量，每次跑一轮，测试用例，时间成本和效率会高很多！！！
测试测试过程中，要保质保量，在我看来，如果测试之后，出现了问题，除非是流量问题，被雪崩了是开发的锅，其他的流程问题，就是测试问题，比如，逻辑错误，系统BUG，兼容性问题，这些基本的黑盒测试都能得出的结论，如果，没有在发布前解决，那么，测试就是不认真，要么人员少，任务重。
我今天看到了邮件，发了，我也不会认真看，这个，谁会认真看呢？
每次，开发完成，能有个统计，应该来说，已经不错了，很多团队，连这个统计都没有。那么问题来了，统计之后，有什么意义嘛？我们接下来几天看看，有什么意义。
目前，好像不知道这统计有什么意义，难道，仅仅为了，证明测试同学的工作认真？这东西能干啥，需要把BUG细分，基于这些数据进行二次定义。肯定是有分析的价值的，这个议题，这里就不讨论了，又回是一个庞杂的问题。但是，我想不应该止于此。能不能在每一次开发之后，有一些团队的成长，这里，我希望测试同学也可以伴随着产品共同成长。
在我目前这个心态下面，首先定位的还是产品的持续发展和团队的成长，团队成长不等于个人成长，只有团队成长更快，个人成长才会更快。团队成员的竞争，完全不是我需要要考虑的，这就像高考，很多高中老师视野很差，告诉同学们，要在班级内竞争，然后，搞得很多人关系很微妙，这个在我10年前就懂了。我们需要竞争的是你环境里面所有的人，而你身边的人，是最大的帮助，而不是挑战。
今天，我们竞争的团队是全世界的团队，我想说，未来，我们一定会走出去的，这个只是时间的问题，当然，公司走不出去，我也会出去，只要有机会，这个绝对只是时间问题，那么，回到这个问题，团队就是个人成长最好的沃土，身边的人，就是你成长最好的伙伴。团队的共同成长，是远大于内部竞争的。因此，如何更身边的人学习，不断的超越自己，就是我们要做的事情，也是最重要的事情，只有提升个人价值，适应了这个体系，
【这里】我补充一句！
适应体系，我最近才想清楚这件事情，之前我不理解，现在我貌似理解了，也不确定是否理解——就是，规则存在，就是合理的！（这个假设，是开放性的，当然，如果没有一点假设基础，就没有讨论下去的必要了），好假设成立！之前我的想法是，这个规则有问题
那么，我的问题在哪里呢，是我过于理想化，还是我没有经验呢，不全是！
第一，我们要合理的利用现有的规则，是的，首先我已经假设规则是合理的了，那么，既然规则合理，我们就必须要利用规则提升个人和团队的效率，从组织的角度上讲，不同团队之间是有竞争的，或者说，即使不同角色之前的团队，依旧有自己的工作职责和范围。那么，利用你所在的身份，合理的利用规则，就会提升团队工作效率。然后，有了依据之后，才能去改变规则。进而让规则更好的服务团队和个人。
第二、长期在一个环境呆久了，容易温水煮青蛙，是的。这个文章，只有我在前三个月去写，才有这些观点，过了半年，在写，味道不一样了，当然，我想也会有观点，只是有些区分的观点。是的，会不一样了。因为，很多东西我认同，都是动态改变的。当然，认同不等于是对的。这就是固有思维的影响。人很难考出来去思考问题。这个问题，以后，漫长的岁月里面会伴随着我，我希望，我时常能跳出来看这个环境。
第三、被环境固化和团队过于稳定和不稳定，都是问题：
3.1 过于稳定，会激化核心成员的矛盾，以及近亲繁殖，这个会影响产品的发展和迭代，会影响推陈出新，到时候，肯定要壮士断腕了，但是关系过于稳定之后，就不仅仅是工作了，还有生活，这个时候，干谁都是个问题，如果我在公司工作10年了，我的同学和兄弟，也都10年了，想想都恐怖，怎么断腕，断谁呢？这个时候，工作积极性和进取心也是很大的问题，理想和初心，可能早都不是最开始我们认识的时候了。
3.2 过于不稳定，更悲剧，可能现有的盘子都守不住。因为，回到上面的描述，如何利用现有的规则，就是必须是熟悉体系的人，这些人才是做事情的基础和倚重。没有这些人，很难搞事情。
所以，相对稳定在如今的互联网公司是合理的，有出有进，保持和时代的技术同步，不断的推陈出新才是合理的，团队核心成长以后，地盘和空间分好，也不会有太多问题。整体情况就会比较稳定。因为，只有新人才能更好的保持饥渴，但是，需要志同道合。所以，能找到志同道合的团队是一件很难很难的事情。大部分的时候，我们不得不去求同存异。
3.3 不同阶段的个人和团队的成长 方式不一样，这里我们就不细化每个阶段了，这里，在未来一天，我想，一定会继续讨论的。因为，我总有成长到那一天的时候。
回到这个议题，测试阶段，测试用例的积累，流程化的测试方式，对于bug的分类统计，构造场景统计，人力成本的统计，合理化构建测试流程，如何更快，更精准的复现BUG，如何快速定位和解决BUG。然后，如何能把BUG减少。
是不是，还可以考虑逆向思维一下。如何不出现这个BUG，提升开发人员的测试意识和边界处理能力。不让BUG出现在测试阶段；让测试同学讲课，开发去学习，思考如何优化代码，最好在框架层解决一些经常出现的问题。我认为这是有可能搬到的，因为共性问题的存在，会有很多这样的边界问题需要处理。
还有，是不是有的开发觉得测试没含金量，觉得 low！no！这回让测试同学教育我们，提升他们的成就感。让他们意识到，大家是平等的。他们也是我们开发流程中非常，非常重要的一部分。我尊重，不等于所有人都尊重。他们效率提升了，就可以释放人力去做更核心的事情了，开发型测试，已经是这个时代必备的要求了，其实，让开发转测试也是可以的，因为，测试工具和测试用例的构造，需要开发经验。并且，这不是一个很简单的事情，要尊重测试同学。
判断BUG来源，历史业务不熟悉，产品新增需求，个人编码问题，个人测试不完整，边界处理不认真，或者能力问题，架构不合理。统计之后，看看那部分最多，那些最耗时，然后，在去处理掉。这样我想价值会较大，不要仅仅只发一份报告，估计没人会看，我身边的同学已经做下一个需求了，我自己也是，这里，测试的复盘也很重要。
我们不是为了指责谁工作不到位，我希望能看到完整的开发体系流程，看到更好的内功，这些东西，也许今天看起来做不做都行，但是，在未来，当真的机会来了，赛道打开的时候，自己跑起来了，但是，腿断了，跑不动了，哭死的心都有。因为，也许离终点就那么几步。是的，我想，终点以近在咫尺，但是，就是没办法到达。这样的例子已经太多。
吴军说了一句我需要记忆很久的化，我们大部分人做完的事情，都是做到99%，但是，99%毕竟不是100%，这里我不想计算，什么多次的累乘，这种鸡汤。我想说的就是，100% 和 99% 付出的努力，真的差不多了，何必省那1%的力气呢？多做一点点，结果可能在未来就是天差地别。
需要让测试同学的价值更大，释放他们的价值，也就成就了我们自己。他们效率高了，他们有沉淀了，等于我们效率高了，有沉淀了。他们会让我更快的进步和成长。
还没有发布。。。。不过，我这次就一个工程，不存在依赖问题，后台发完，我发就可以了。
这个点需要场景化，我需要时间来描述，常规需求，突发需求，老板需求，都是不一样的。
发布，最少 3个环节，测试环境，预发布环境，灰度环境、正式环境。
是否有灰度环境，看产品，但是预发布环境不能少，谁少了，谁以后背锅。
至于，发布多久，验证，进入下一个阶段，不同团队，自己控制。发布版本和周期性发布的策略，不同的团队，根据自己的方式自己搞把，有的团队一天2发，早晨晚上，有的团队，周2小版本，周4大版本。有的团队按照需求进行发布，半年发个150多个版本，也是有的。
不同的团队，自己取舍：
（1）大版本发，有可能出现，bug分不清，不知道谁影响了谁，出现了bug，导致，整体功能回滚，很多之前发布的功能，走这个大版本，导致无法上线。
（2）更需求发布，会出现版本过多的情况，但是，不影响迭代速度，回滚只滚小需求。不影响之前发布的版本。
（3）一早一晚，和周2周4，是前面2者的结合吧。虽然存在耦合，也相对保证了版本数量。
没有好坏，只有是否合适。这里不纠结，看团队。
后续补充：
1）接口协议真的很重要，以前后台也是自己搞，不管是node的服务，还是java的系统。都是自己搞，没感觉这是个问题。自己想要什么数据，就自己来了，现在开发纯前端的项目，接口太重要了，因为 react 的项目是基于数据进行页面渲染的，数据字段，我有洁癖，喜欢同名进行处理，后台要是改了，我前端也会改，这样协议定不好，开发效率就被严重影响了。
必须要求强制协议先行，业务开发之前，协议和字段必须要定下来。先不做业务，第一步就是，对接口和功能，这是必要的！！！分治隔离的开发，是效率最高的事情，流水线是这个行业早已经沉淀的精华了。无论是TCP，还是操作系统早已经实践的很好了。
结论——前端控制接入层才是正途。
2）今天在测试构造测试用例的过程中，我提到了一个点，将测试流程的逻辑图，挪到产品宣讲的时候。而不是，在测试的时候进行修改。就类似如下这些开发，按照这些进行开发，而不是标准流程上面字的开发，有些东西不好看，有些需求漏看。有些问题需要及早暴露。
所以，需要有项目的功能图
3）以后在开发的时候，需求评审之后，方案评审之后，我一定要在找交互和UI进行一次UI稿的确定。这次就这样了，很多没有标注清楚的，我也没问，自己干了，因为之前不写样式，都是重构工程师做的，现在自己写样式了，走查要在开搞之前，进行。而不是之后。这次，就在把样式从新搞一遍。
当然，这次我自己也犯了一个错误，我应该早一点的合并进来进行开发，他提醒过我一次，但是当时我已经在开发了。为了不影响开发进度，就沿用了之前的。现在想来是不对的，他重构的代码。逻辑更清晰了，如果用这个开发，应该会少改很多bug，肯定是会省事很多，之前的状态管理是比较乱的，他收敛了起来。这就是前几天感觉更新state比较麻烦的问题，因为一个状态，各种地方都以，所有，更新起来就很繁琐，找来找去，新手，就会比较辛苦。复盘下来，以为快了，实际是慢了，但是个人成长的角度来说，先写烂代码，在写规范一点的代码，收获更大一些。这个角度讲，不白写。
主要还在学习期间，这个项目全当练手，在写一遍，把我的代码，塞到新的代码结构里面，直接完全重构。并且需要有追求产品细节的心理，对交互提出的修改应该予以满足，只要是对产品体验有意义的事情，我们就应该进行到底！！！是的，这个观点必须强制自己修正过来，我其实很不喜欢写样式，页面的逻辑都做了，但是，样子不是100%的完好，这是不对的，需要把样式进行到底。写的多了，经验自然是会变得强大起来，CSS只是时间的问题。
但是这里需要注意：必须在方案评审之后，在进行一轮视觉评审。是的，原因就是：
1、过需求之前，产品会补充一些新的想法，这样交互的稿子就和真实的不同了，其实就是残缺的。评审之后，新功能和新方案的实现，就会有偏差。
2、在实际开发中，有些需求功能可能会变更。这个时候，也需要设计在此走查；
3、由于项目及历史原因，或其他差因素，无法实现的问题。导致样式更改。
这次，我这3个问题我这次都赶上了，因此，需要修正这个问题。就需要，快速引入交互和视觉进行增量修正。把风险降到最低。而且，我对写样式又非常没有经验，目前，写页面逻辑花费的经历，比我画图的时间还要少，至少这次是真的。画页面画的时间很多。不过以后CSS写多了就好了。
现在开始重构代码，以后，规范的搞起！
4）第一次参加代码review。学到了一些，我对昨天的 论点，修正一下，因为老码农都很多问题，何况我这种对框架和代码都是新人的同学。我只能努力做，结果希望比今天的好一点，然后我明天继续进去，每一次迭代下去，一个月以后，希望有长足的进步。
“现在开始重构代码，以后，规范的搞起！”——我做到我能做到的规范！
尽力去做，然后，不断优化。
在这里，我想强调一个点，一定要追求细节，并且认同这件事，去全力以赴，并且对事情负责人的态度去做事情。态度是第一位的，能力是第二位的，能力可以培养，态度很难改变。这是一个人性格和做人的方式问题，责任心，努力程度，对风险的预知，对业务的态度，都是无法短期内看到的，是一个长期的过程。
不同的阶段，我们需要对不同程度的事情负责，我目前这个阶段对努力和态度负责。只要全力以赴，结果我不需要去考虑，因为，那不是我现在最需要关心的，成败并不重要，成长最重要。成长是衡量我现阶段最重要的事情。努力向前跑，当然，努力做事情，一般结果是不会差的。但是，即使出了问题，我也需要保持好心态，防止玻璃心被击垮，就算失败了，又能怎么样，只要继续努力，下一次总是会开始慢慢做好的，并且会未来中持续成功的。
5）规范化，流程化，总结成为知识，转换为脑图 ，在到PPT，未来的一年形成自己的开发标准化，然后，在影响团队的开发标准化。
6）提交了第一个 merge requests，日常工作中的第一次，还不错。 eslint 会让代码变得更好，review 和 大家一起的review 会让项目和编程风格更统一。
7）又到了周一，自己上周干了什么，忘记了。额，以后，需要记一下每天干了什么，要不过了周末，就忘记了。感觉每天都很满，但是，确实忘记了一周都做了什么具体的事情。以 标准流程 去控制 团队工作，还是用小组站会的形式进行控制，还是有点意思的。从效率上看标准流程更高，但是从核心价值上，站会更好。因为，标准流程 做的东西 并不一定是核心价值的东西。这里，对于核心价值的定义我还没有完全能明确出来。
这里先不管，是不是最优，以后，每天更新excel，坚持了2周，这周忘记了，又是一件麻烦的事情。以后，每天都进行一下。至少2到3天一定要进行总结，这个是可以保证的。
或者引入一些工作方法，进行流程改进。这里的所有的事情，都能进行统计，就进行量化。这个项目，出现了往复和延期，我这边还好，第一工作量不是特别大，我周末也会继续处理；还有就是，有问题我一定第一时间fix掉。所以，很少会留下什么问题。以后，尽量进行个人的流程控制。
8）今天没有准备好，下午5点多要做题库的技术方案评审，我没想到会讲什么，因为入库已经进入尾声了。方案上面也没有什么问题了。加上下午去听课了，听课的很爽，状态都在课程里面。那老师太好了，简直非常6。太强了。绝对专家级别的。太酷了。即使现在想来，也是让我感觉激动不已的。今天过的太值了。
今天方案评审自己要检讨。自己需要认真对待每一次锻炼和学习的机会，主要还是思想上准备不足，不够重视，下次要准备好。
需要准备好的东西：
1、项目背景介绍。
2、目前的现状，待解决的问题。
3、如何解决，方案是怎么样的，跟大家讨论是否合理。
4、需要什么帮助。
9）目前相对认同观点：
1、产品进度是不是应该引入项目经理的角色，项目经理应承担需求进度的跟进和同步，而不是owner，这样是问题很严重，即开发又跟进项目流程，这种强度是比较难的，尤其项目压力大的时候，这个owner就形同虚设了。这是必然。
2、产品的需求迭代是不是可以不做，是不是可以下一期做，为什么，需求会增量做。项目经理是不是应该控制一下，这种增量明显就是产品没想清楚。产品的评价标准不是需求做了多少，是不是延期，我认为最重要的是为团队带来多少价值。多少营收，多少新增用户，用户体验是否提升，然后才是需求的质量和数量。不要这么搞，开发会很被动。
3、代码质量的责任制，谁负责，谁关注，协同开发的时候，以项目的责任田做为标准，然后，对代码负责，是一个责任心和价值观的事情，当然，适当的需要有流程的控制。才能让体系运转起来，有代码追求的文化是需要慢慢烘托的，不过，也不要太过，但是要有。
4、自动化测试，自动测试回放，保存测试用例，并且流程化的测试框架是很重要的，每次迭代产品的时候，先跑一下测试框架里面的用例，这个做了，测试的人力会削减一大半，而且可以提升他们的效率和价值，有一些团队已经引入了这样的流程，借鉴过来。
这里，引入一下观点，我和我们的测试同学交流几次了，有过2次稍微深度的交流，但是，工具的完善和基础工具的积累上面，他们并没有在意识到，之前，讨论关于虚拟化链路的问题，这个本质是运维的工作，运维去做容器虚拟化和服务环境的部署，不过，好像团队没有运维这个概念。有的团队运维名声是听过的，这里就不描述了。但是，测试同学最大的价值还是提供高效优质的测试能力，需要解放他们的生产力，稳定产品的测试用例是非常有必要积累的。
5、对于老业务的增量改造，我上次和一个人聊，他的意见是，现在一个需求几十个接口，每天花点时间改2个，改一个月，老接口肯定就改完了。就看你愿不愿意做了，这东西还挑个整时间来改，业务是没办法等你的。
最后一点，伴随着业务开发的不同阶段，需要有业务数据的流程图和项目的架构图。这个，我想，需要慢慢提供出来，并且慢慢积累起来，要有这个意识，做一个需求，做完之后，要画项目的流程图。
这个应该在需求宣讲，产品给第一次，
然后，技术评审的时候，更新第二次，
测试的用例的时候补充，更新第三次，
上线之后，最后一次更新。
如果产品不给，是不是可以拒绝不做，因为，这样，做完，她在改，证明产品老大想的不清楚，但是改了也接受，因为一目了然，好处理啊。可以做，不可以做，比较容易判断。而且，复盘的时候，有迹可循，现在，产品最开始提的需求，到现在，面目前非了。
所以，我可以理解有的团队，技术leader排期，技术leader理解产品需求，选择性的做，因为可能他产品还懂业务。目前，我能看到的很多开发领导是具备这样的素质的，而且很多开发同学，由于做了项目，跟了解产品本身的功能和迭代方向。所以，让有意愿的开发同学，参与到产品的规则和需求讨论中去，而不是，单纯的被动的做，不停的做。有时候，是没有意义的。