受某人的影响，吃饭的时候也跟着刷了好几遍的《甄嬛传》，真下饭！

         积石如玉，列松如翠，郎艳独绝，世无其二。你在本宫心中，便是如此！

        做了十五的开发，经历的公司国内的有日活千万的业内顶流。国外斯坦福大学的工作经历，也有世界顶流公司的工作经历。最近gap。停下来想想，当初为什么出发，未来又在哪里。

今年的枫叶好像不够红啊

        做衣如做人，一定要花团锦簇、轰轰烈烈才好。鲁迅公园春天的樱花交至在一起，形成一张网，笼罩着如织的人群。如何衡量一个项目的复杂程度？工程有多少个G，代码量有几百万行？业务函数交织成的网的复杂程度，代码交织在一起，编织成一件华丽的晚礼服，各种色彩的丝线各种材料的珠宝的交织，随着客户各种定制改变。普通的需求大致是改新的材料，改变尺寸，变长变短，夸张点的需求大致是随着温度自动变薄变厚，随着场合自动变化五彩斑斓的颜色。

        就拿长袖改短袖这种普通需求，裁缝肯定不能用剪刀咔嚓一刀把长袖子剪了，缝合新的袖子上去，这样不体面，礼服也就成了缝合怪。负责的裁缝会抽丝剥茧的找到线头，捋顺了再衔接上别的线头，可时间允许吗？ 华妃穿着你给他改的旗袍，会不会更觉得今年的枫叶够不够红？

        各种不符合预期的需求接踵而至，开发者欲哭无泪。黄老板从影视圈混到了美食圈，想在一栋商业写字楼里，想增加一个厨房。需要考虑到承重墙，油烟通道，电路，水路等各种问题。马斯克有一天想变成金刚狼，需要考虑到艾德曼合金，骨骼，血液，神经等各种问题。硬解决也行，屎上雕花罢了。要不然就得大动干戈，得重构！

        互联网公司的重构都伴随着风险，甚至会失败。如何让事态按照预想的结果发展，搜一下各种论坛，不论是方法论还是操作细节。无非是分层，模块化，组件化。但真的到现实中，面对积重难返的屎山代码，不知道如何下手，从哪里下手，边界在哪里？风险怎么评估？怎么跟领导解释重构的价值？你像不像一个新手拿着手术刀，不知道第一刀从哪里切，切开之后血就止不住的流出来，是该先止血，还是继续下一刀？

        本文接下来的主要内容针对的是年久项目的重构，如果你是一个新项目，有N多种选择，自己有业务，想转向线上寻求更多的市场，选择诸如混编，纯RN，小程序，网页实现等等。或者前期可以先找第三方的拖拽式编程，LCNC，定制化的UI找第三方去做。npm能实现快速的插入定制化能力。甚至最近网上已经有自动生成代码，生成业务能力，甚至发布等，基于AI和LLM，将来一定每个人随便一句话，就能做出一个产品来，可能明年，可能后年，就会实现人人都是产品经理的能力。

        有AI的加持，也需要有一个输入与业务的确认过程，我想先知道流程是不是我想的样子，如果不是，我怎么调整。即将文字解析成可视化流程的一个过程。所以虽然是为了解决年久项目，但AutoFlow不是随用随扔的东西，可以为代码开发流程做出深刻的改变。为代码服务只是一个引子，接下来AutoFlow能做的事还有很多，解决人与人沟通的信息对称和效率问题。如果读到这里有兴趣，可继续往下看了。让我们一层一层的剥开揉透了。

        大家讨厌华妃，但都想做华妃，手里握有统御六宫之权，账上有卖官鬻爵的银子，身后有功高盖主的亲哥哥。现实是你在后宫里谨小慎微的活着，手里握着刚掉下的头发，账上有房贷和车贷，身后有呼啸而过的跑车。

臣妾做不到啊

        23年马斯克收购推特之后，仅仅用一年时间进行了大量的重构，人数从8000锐减到1500，虽然短期内有阵痛，但数字指标真的好看。平均指标都做到了80%左右。做重构工作的的时候，领导会先问如何量化重构的结果，是不是回想起自己在回答领导时候不自信的样子，心虚的报上一个数字20%？APM其实好做，不是因为技术难度低。而是卡顿率，启动时长等这些都有很好的数据支撑。重构怎么算这笔账？

        在互联网浸淫多年的看官应该能觉察出，好几年都没啥太多的东西出来了，互联网行业触及的边界慢慢萎缩。哪些东西是老树新花，实际没有啥新意？哪些真的能改变工作生活方式？我这十几年对互联网痛点的理解，知道哪些东西可以真正的提效，想做点变革，直击痛点，根本上解决问题。各位看官耐住性子，咱们慢慢说。

        本宫经历的几个公司，从产品到开发到测试到运营，到数据观察和市场采集，再进入产品加工，再到市场反馈。形成闭环。不好的是过程是割裂的，能清晰的看到流转过程中，组与组之间，部门与部门之间过度并没有那么平滑。每个组都顾自己的利益，注意维护好自己的入口和出口，就像水流在一个环形的管子里流动，中间有几段卡的特别细。有流体力学知识的同学知道，根据伯努利方程，水流会越来越慢。

        架构的改动会影响到上下游各个环节，会引起群体的恐慌。不确定性会充斥着整个过程。要充分考虑上下游的利益。让各个利益方都能收益，这样推动起来，会很有利。都是职场的老油条，都不是省油的灯，只有给他们实实在在的利益，才能说服对方接受。让卡住的水管能顺畅。金融的基础是信任机制，我想建立互联网行业，甚至传统行业的信任透明机制。

        每个行业都在卷，后疫情时代需求变少了？还是问题变少了？需求的提出也是为了问题的解决，问题只是暂时左移或者右移了，并没有变少。 互联网各大厂的APM指标满足边际曲线递减，基架也越做越稳定，重要且紧急的问题是有限的。去年前年在老司机论坛做演讲做直播宣传各自技术先进性的大佬们，如今也回归如何服务业务开发。

        架构会遇到两种情况，A，从0到1.0；B，从1.0到2.0到3.0。

        A，这种情况是大家都想看到的，开局一张白纸，可以画好蓝图，然后照葫芦画瓢。葫芦是什么样，瓢大致是差不多能有个预期的，前提还是CodeReview（代码评审）细致一些。就像去年的梗，理想小龙女和现实小龙女，差不多是李若彤和刘亦菲的对比。

        B，是现实工作经常遇到的，解决方案基本上就得叫重构了，重构这个词，会被一些开发人员挂在嘴边，但是非开发人员听着冲击力太强。再换个表达方式，结构演进？有可能往好的方向发展，重构有可能是负向的。理想中的小龙女还是李若彤，可现实中会变成贾玲版甚至岳云鹏版。

        架构师服务于架构的优化和迭代，既要为自己的职业发展考虑数据背书，又要年度考核的时候和面试的时候表述清楚自己数据指标。重构真的能带来效率的提升吗？这笔账这么算？乌拉那拉宜修说”臣妾做不到“。如果想做到，以什么为抓手？如何为业务开发人员赋能？如何形成收益的闭环？如何进行技术先进性沉淀？如何打通跨组沟通的障碍？本宫现在也是互联网黑话张口就来，成为了自己讨厌的样子。

        在这宫里，有利用价值的人才能活下去

        一个项目都会涉及到立项，研发，测试，数据复盘总结。问问自己，对于不熟悉的模块，开发时间和代码阅读时间的比例是多少？这个需求写的代码是否能用一半时间做完，甚至三分之一，四分之一。换个角度计算，10天的一个需求，沟通时间、理解代码时间、写代码时间跟总开发时间，比例是多少？大致是，30:50:20，或者20:50:30，或者20:60:20。对于自己之前熟悉的模块，一个月之后还能剩下多少？三个月之后呢？半年之后呢？

        换个方式统计，还是是10天的需求，老李完成需求研发工作，不要直接合入代码到主分支。换做小张cherry pick，老李在旁边指导，并说明每一段的作用加注释。小张完成理解后，最终完成合入操作。整个过程可以在一天内完成。老李做完了之后，又能把前后关联性能很好的解释，算高质量的完成，测试效率提升也巨大。十天比一天。即开发效率有90%的提升。

        1/10，是一个终极目标，前景是好的，道路肯定是曲折的。分子和分母拆开了看。分母的十天的预时又是如何得来的呢？对未知风险的恐惧和忌惮。调研需要看得清上下游逻辑，摸清来所有的龙去脉，稍有不慎，就是一个Bug，就是职业的一个污点。

         再举个例子，一个结构体的三个值XYZ分别影响后面ABC三个不同的业务。开发由于调研不充分，或者业务不熟悉，并未给出完成的影响范围，测试人员只测试A和B业务，测试不知道会影响到C，或者不知道有C业务。时间累计，就会成为那种线上偶现，但怎么都无法测出来的问题。随着业务的开发，ABC三种业务可能已经改了，永远不会重现了。线上bug变成历史悬案了。各位柯南怎么看？

        如果各位看官认同上述的推导过程，不用纠结于数字的准确性。那架构升级的价值就体现出来了。明面上的账算明白了，如何算其他的账？换句话说，如何向上管理，得到领导的支撑？

        1，历史代码段的理解成本如何降低，怎么衡量代码的阅读成本？

        2，人力成本是互联网公司的最大成本之一，架构升级的投入产出比是多少？花出去的银子多久能收回成本？

        3，抛开prd、文档，语言的存在的漏洞和理解的误差如何抹平？说如何与产品经理和测试进行沟通？

        4，如何找到适合自己的架构？别的厂的经验能否复制到我这里？

        读到这里的看官，如果对这几个问题有兴趣，下面是如何把这些问题进行拆解，再推导的过程。

        本宫宫里一共有三百二十六块砖石

        大部分互联网公司都是从10年前的第一句 “Hollo Word” 开始，经过成百上千次产品的迭代，保留了大量的历史逻辑，多少被if包起来的僵尸代码。一个函数里有多少个if else 嵌套。一个类多少次维护差不多能烂掉？如何保持统一的代码风格？开发人员接受一个需求， 会不会维持原来的风格去写？还是打补丁？ 补丁打的多了，谁看都会迷糊？多年前扔出去的回旋标，最终扎到自己身上。 

         开发人员进入一家公司，通过代码了解公司的基本现状。开发通过业务需求和提升代码质量体现自己的价值，而代码支撑的各种业务来提现公司的价值。随着业务迭代，很多人来了，走了，留下了大量的无主代码。代码慢慢成了大家最不想看到的样子。一个简单的if就会让下面的逻辑网络的可能性翻倍。而如果涉及到某个数据模型涉及到传递到多个业务中使用，那每次迭代带来的测试量是很大的。用养寇自重，养虎为患来形容老员工虽然是不客观的，但是表面上看确像是很主观的。

        从工程架构的健康角度上讲，每一个模块和组件都是有一个健康的生命周期，从模块和组件的上线到其下线，都应该平稳流畅的实施。现实中大多数情况是一个模组件升级或者改动，会有未知的各种业务会被影响。提测之后，就会有各种很迷惑的Bug，查也不好查。现场也不容易重现。

        经常做过业务迭代的开发会先用ProcessOn，Xmind等工具把模块的图做出来，画一个长方形的大框，里面加几个长方形的小框，小框内写着简略的流程，然后用不同的颜色标注一下线程或者层次，用流程线把格子连起来，标识流程的前进。完成之后，进行方案评估。方案通过之后，把代码像橡皮泥一样。使劲摁进模块的格子里，每一个框都都是一个乐高的小积木。

        随着代码的迭代，脑子里慢慢出现那个MM豆描述屎山代码的那个场景了。有的需求合理，有的需求是从竞品抄的，有的需求天马行空。即使当初有了一定的架构，类似于MVVM，MPV，VIPER，React等。也难免会有一些逻辑类慢慢庞大臃肿，最终是变成了大家都讨厌的样子。代码阅读成本变大。想更改或者插入一点东西，就很费劲，怕引起其他的问题。

         家有一老，如有一宝。老员工不可替代性是其价值的体现，虽然业务逻辑很庞杂，但是很多年久的业务逻辑记在脑子里。当有新的需求来的时候，搜索脑子的代码，找到合适的插入点，想象可能的修改项，估算好开发时间，加上一个点buff作为下楼抽烟和开小差的时间。代码即文档，现实中有几个能做到呢？

        庞大的代码带来巨大的阅读成本，就像敬妃宫里的326块砖，并且有31块砖已经有轻微的裂痕了，如果不是因为抚摸过很多次，根本就不可能会知道这些细节。各位看官的后宫里，有多少块砖出现了裂痕呢？

        各花入各眼，是非自在人心。

        世界上最难的两件事其一，如何把我脑子里的思想装进你的脑子。信息的传递和沟通，可以使用prd（产品需求文档）、技术文档、口口相传，要整理这些prd，就要去查历史，就需要人的参与，人力成本的花销，但是面对历史包袱，人脑是最不靠谱的。

        你们组来了一个新人，大抵会有一个老人来带新人。如何快读的，能低成本的把经验复制到新人的脑子里。手把手的教？还是扔给新人一堆文档或者直接代码让新员工自己学习？公司招人肯定不会愿意花太多时间培训培养。想新员工当天就直接上手干活。在建筑工地倒是可以，互联网公司应该不行。

        好的架构设计，应该能快读的拉齐新老员工的业务逻辑信息差，为跨组之间的沟通提供数据信息。跨组之间的沟通能保持一一个频道上，更高效，更省时间，信息的传递业务准确无误。解决产品和开发沟通不在一个层面的问题，甚至解决信任问题和内耗问题。为什么很多会议室的墙都变成了白板？大家开会时遇到说不明白的事，会直接拿着黑笔在白板上画出来。原因是什么？

        代码是人的思想的归纳和抽象表达，每天在电脑前看着满屏幕的代码，人脑的疲惫是很快的，这是人的天性，人脑不会主动记住很多东西，就像小时候背诵课文一样，没几个人是愿意主动背诵。人的经验是可以长期存在的，就像瞬时记忆和长期记忆，类似于电脑的内存与disk的关系。而寄存器就相当于最近的几段记忆。

        信息传递的越来越快，越来越密集。信息是如何转化成经验的？经验是可以当饭吃的！这里说的经验专门指的是可以用大脑思维计算和语言表达和肢体表达。辅助于图像解释，动画表达。一个外科手术10年的医生肯定更受欢迎，但是为啥一个35岁的程序员被公司淘汰呢？

        各位看官跟产品经理吵了多少？跟测试吵了多少？有没有再心里骂对方是SB？你知道对方在心里有没有骂你是SB？你有没有站在对方的角度思考问题？对方有没有替你思考过问题？

        各花入各眼，你看到了什么，就会接受什么。怎么做到让大家看到的东西一致？架构师能提供什么样的服务？

         那年杏花微雨，你说你是果郡王

        架构师要做到内外兼修，

         对内，直面业务开发人员的人性弱点。解决大家的痛点，才能得大家的拥护，人都是趋利的。

        人性是懒惰的。项目开发中本性会先松后紧，deadline是第一生产力，下落过程中手中有一根绳子，一开始都会先松，到最后快看到底的时候才抓紧。但是这时候速度已经很快，抓紧的话会很疼。手忙脚乱。项目刚开始的设想可能会破坏或抛弃。也就是程序员说的，当初想的好好的，到结果不得不为了应付各种bug，写补丁代码。

        人性是自私的，在实际业务开发过程中，大家都想享用已有的成果，要不是为了OKR好看，都不会主动想为了整个组去奉献。但是需要有人造轮子造工具，也需要规范开发人员的代码风格，增加一些可读性高。关于代码整洁度，就像战忽局的局座说的，好看的东西一定有战斗力。轮子要好看，才有战斗力。

        人性是软弱的，开发人员每天都面对着压力，有沉重的心理负担，帮助开发人员缓解压力，把不确定性和关联性和依赖性都复现出来。让估时更精准，并且把步骤安排好。达到一种平衡，wlb，根源上解决脱发问题。

         向外，对老板体现自己给公司带来的战略价值和战术价值。

        绝大多数企业不具备对外适应性做长期规划的条件。一旦外部环境变化，资本会进入，那如何快速的利用优势进行转向成为稍大点的公司的心病，很多东西都固定下来了，动则伤筋动骨，还面临着风险。

        架构师需要通过帮助企业找到长期生存的架构方案。即要让产品能快速高质量的迭代。又能迅速的调整方向，即产品改了千百倍，本宫待产品如初恋（大部分产品妹子是挺漂亮哈）。我刚入行的时候，一位前辈说，一个接口就是要改来改去的，要想着如何应对改变。

        每个开发都想着在职场里再进一步，那年你是果郡王，其实你心里是想着四大爷的位置。

        这福气给你要不要？

        注意看眼前的男人叫小帅，这个女人叫小美，这个男人叫丧彪，这个女人叫翠花。大家经常刷到这种七八分钟分钟解析一步电影的短视频。有的电影例如诺兰的电影，短时间讲清是比较有挑战的，甚至完整看完电影之后也有很多要琢磨的地方。

        去掉了电影的细节，只保留电影的故事梗概，留下故事发展的唯一脉络，让故事的时间线得到压缩，在数学角度上看，是不是一种求导？有时候只想了解一下梗概，有时候又想补充和了解那个时间线上的历史细节，得到更细节的解析和诠释，在数学角度上看，是不是就是一种积分？

        本地迭代的某个需求，会涉及到若干个类，而这些类也要为其他的业务迭代服务。对比着业务流程图，是不是哪些要改动的类，在你这个业务迭代维度上的求导？听懂掌声！换个通俗点的讲法。如果一朵花反射了红色光而吸收了其余波长可见光，就会看到红色的花，其他颜色的花也是同理。花朵对自然光波长的选择，是不是也类似于在单个色彩维度的求导？

        如果一个播放器没有可以拖拽的进度条，是不是觉得难受？如果一辆车没有仪表，是不是觉得难受？如果你是个时间管理大师，想要撩的美女或者帅哥总能轻易逃脱你布下的陷阱诱惑，是不是更难受？对事情进度的掌控，局部区域的感知是不是一个人权利的范围？程序员想要的掌控力在哪里？面对复杂的页面，脑子里想的是像TypeC或者HDMI找到对应的位置，插入对应的设备中，电压自适应，结果能完全预测。

        拽妃为什么拽？因为她把握了四大爷的心理，可以自由控制快慢，甚至生不生孩子都能控制，本宫想在为宫内再添一把火。

        臣妾要告发熹贵妃私通，秽乱后宫，罪不容诛！

        终于要说到本剧的大戏，也是时候回答上面的问题了。

        1，历史代码段的理解成本如何降低，怎么衡量代码的阅读成本？

        快速找到需求与代码之间的结合点，快速定位到Bug与代码的结合点。老员工和新员工能以同样的时间成本有同样的产出。即产品组提给开发组业务的时候，不用再考虑员工工作年限和是否熟悉某个模块，某个业务功能。

        2，架构升级迭代投入产出比是多少？花出去的银子多久能收回成本？

        如果你的项目已经完成模块化，则针对模块内业务代码添加流程监控，像淘宝首页或者抖音首页这样的模块可以在1天内完成。剩下的账可以自己算了。理想的话，半个月之后就能有收益。半年内可以收回所有成本，并且持续提高效率。

        如果你还没有完成模块化，建议先按照模块化拆分，再进行模块流程的更改。当然也可以直接改，只是收益会慢一些。

        3，如何与产品经理和测试进行沟通？

        动态代码运行即流程，以上帝视角通过宏观和微观的角度去看任何一个流程的进度。如下图展示了一个请求发起到后台处理完数据的整个过程，做到从发起到内部所有的流转的过程的全知。这里先提醒一点最重要的点，这种图不是人工画的，而是根据手机端的业务流程产生的数据自动生成的。

        4，如何找到适合自己的架构？

        只有基于业务的代码产生的架构才是最适合你的，别的厂的经验能否复制到我这里？千万不要为了主动往某个架构形式上贴，硬改。相信你的同僚，他们也想把事情做好。他们都有专业的知识储备。

         上面第3个问题，提到自动画图，就会有类似xmind或者Processon这种平台，反映出APP运行过程中的流程中所有的过程信息，都通过图片+文字描述+区域性数据解析的方式展示出来。实现买菜大妈也能看懂流程和数据和逻辑的关系。并且自动根据代码辅助生成框架图，依赖图，层级图，模块边界，出入口，灰度等，一个UI组件与数据的绑定结构都清晰的展示。

         我给平台起的名字叫AutoFlow。AutoFlow能自动的，动态的，实时的，真实的反应一个产品在整个过程中，在页面上做的事和桌子底下做的事。产品，设计，开发，测试，所有人能基于同一个平台进行沟通和讨论。以极低的沟通成本的让产品和开发和测试和设计都能清晰的看清逻辑，可以专注于某条业务线，也可以查看具体的的细节。展示相关性，流程性，结果归因性，能有效的提升开发效率。

       程序员去查看某个页面是由哪些逻辑产生的，产品经理去查看线上版本和历史版本的的业务逻辑，在什么地方有什么灰度 。测试去查看结果与预期的差异。设计的去查看每一个小的设计的对应到产品端展示是不是能完全符合要求。

        使用方法，植入SDK，代码需要做部分的修改，部分代码在最后会有部分讲解，以把数据进行存储和图片的整理(json+jpg)，找一个屏幕，或者大屏幕投影，展示流程，流程中可以编辑，例如自动埋点，流程质疑，编辑之后，会把编辑过的数据直接同步到代码中，代码会自动生成相应的代码模块，所见即所得。以动画展示时间关系，依赖关系，事件关系，因果关系。不再依赖于人的理解去画图。而是动态的，随着代码的运行，去画图。真正做到知行合一。

       AutoFlow具体的方法论：

        A，定制统一的Channel

        任何事件往Channel里面扔，有UI操作事件，有跨模块调用事件，有通知更新事件，网络请求返回事件，如果只关注某个Channel事件，则只针对特殊时间求导，就能得出事件的线路。其实Router也是一种Channel。

        B，准入准出

        准入即代码在业务中的加入，上架，符合一定的规则。从简单的要是某个特定的类，子类，再到各种Lint，再到符合某个或者某几个协议的类或者结构。再到内部的结构组成方式（上下都有做好接口）。

        准出即代码在业务中的退场，下架，因为准入，有了一定的规则，那下线的时候就更好的分析出影响面和影响链路。手术过程中想摘除某个组织或者病变，看清楚其相关性，即可动刀。

        C，手动代码归因+自动Hook

        设计出模块的边界，代码自动找到归一的模块，智能的拼接，自动把流程中的逻辑分析并已易读易懂的方式展示出来即能解决上面的问题。支撑页面的代码以易用性，易读性，复用性，多次迭代能力等指标来为开发人员服务，来让产品设计开发测试有一个可以沟通的平台来对历史进行梳理，对新业务对代码量的修改减少到最少。通常对于历史迭代较长，参与人员较多，代码的抽象性和易读性是呈现反相关的。当然并不排除有及其优秀的架构设计。可以让十几年的生长能呈现比较好的方式。从源头，让代码理解逻辑变得更简单，更舒畅。

        什么是Hook呢？

        量子纠缠听过吧？把形成纠缠的两个粒子放到无限远和无现近的位置，一个粒子收到任何刺激，另一个也会做出同样的反应。

        锦衣卫电影看过吧？大臣吃饭的时候说了什么话，会一字不差的传到皇帝耳朵里。

        Hook就是一个钩子，钩心斗角的钩，诸位看官心里有什么话，本宫都能听的明明白白。

        自动Hook，把有用的信息勾出来，当然不是所有的信息都是必须的，关注的某个点，某个维度，可以把所有的信息都勾出来，通过某个维度进行投射。皇帝通过粘杆处，了解到果郡王写的家书，都会加一句熹贵妃安，知道了二人之事。可见一个钩子的重要性。

        这纯与白原是最干净的，不该与欲望纠缠在一起

       实际操作过程过程中会先遇到几类问题

        A，这么多代码，有一些代码要随着业务一直要使用，而有些代码短时间内没有需求，先改哪个？本宫的建议，先改稳定的。改完了之后，再在上面做迭代，就能觉察出AutoFlow的优点。

        B，老代码如何按照准入准出机制重新拼装，有的函数几百行，有的类几千行，如何平稳的过度到新的设计模式里？本宫的建议，先把UI跟逻辑代码拆开，逻辑代码按照需求，分几类，瘦身之后，再进行改革。

        C，新老员工如何分工？老员工的经验如何落实到实体代码里？老逻辑降的理解成本很高，老员工要对重要的方法添加方法的运行解释，函数层面，对入口的解释，函数内部重要节点，出口返回值添加运行解释。业务逻辑层面，if逻辑对分叉的解释，流程的直线变成分叉，交叉。

        D，模块化和组件的边界在哪里？本宫的建议，没有边界，可以随时互换，模块和组件的关系就是乐高拼装的关系，只要出入的接口统一，关系可以随时互换和替换，军改的重要变革，师改旅，即是本宫答案的由来。

        E，如何减少人的参与，发挥人的主观能动性？测试人员的能力，产品的能力，如何参与到代码流程的优化，本宫这里说的是流程优化，而不是细节实现的优化。一个功能的细节可以有多种实现方式。

         F，手动要加的东西又哪些？ 使用一个Plist，进行标记模块与类的关系。手动，则使用，方法注册类，类注册流程，流程注册业务。具体的demo会在后面公布出来。

没有你，这福寿绵长于本宫而言，不过是万事皆空而已。 

       上面讲了那么多，是不是就是一个看流程的平台，我自己也能画，再强调一遍，上面的流程是自动生成的，你想看什么逻辑，就看什么逻辑，可以进行阶段性的拆解，想关心细节就可以查看细节。并且还有很多意想不到的收益。

        除了看流程，这个最基础的功能，还能做什么？

        A，自动埋点。

         每一个参与流程的函数都有运行解释，是一个标准模型，有输入输出和中间节点，而埋点需要的就是这些信息，现在的做法是把数据转一层，再通过统一的方法上报，没有必要再转一层。因为事件产生的函数，入参，函数内参数，出参，能完全满足数据的需求。

        具体操作：BI（数据分析）在平台上对流程函数选中之后，选择埋点关联事件，时间关联联合ID，联合ID由业务+流程+节点+事件组成派发到客户端，客户端自动将相关数据上报。实现闭环，自动化，智能化。

        B，数据归因

        页面上显示的Label，Button，Image 经常是若干个条件来控制的，能快速溯源到某个业务或者某个接口的输出。实现了页面跟数据的零成本沟通。 经过接口请求+层层的值传递+本地业务逻辑判断和中间类的影响触发。如何溯源到某个网络接口的返回值，再溯源到发起请求的接口，时机+参数。可以通过平台直接看到。

        C，业务的快速拆分组装

        快速拆出一个新的对外的模块，如何快速评估不遗漏，不添加多余的？目前的调用是网状？如何评估改完之后的效果？ 跨级调用可能性？数据驱动的话，最终落实到数据上，如何解耦过多，则需要自动将数据拆拆分再封装。如何使用一条数据结构？CR的时候如何减少人的参与？交叉代码整理，某一个类或者方法是否只能被单独的类使用？即使是单例，如果被非白名单调用，也不会有效果，甚至报错，保持独立性。

        D，历史的积淀

        开会的时候，经常会被问到以前是怎么做的？怎么办呢？查文档，查prd，飞书能实现文字即文档。不如直接通过平台的版本定义。查询历史的数据表现。

        E，突破海弗里克极限（Hayflick limit）。

        重构之后需要多久，代码会变差？除了工具类，即用即丢的情况，如果参与迭代使用，2.5年。互联网公司平均人员迭代周期是1.5年。代码经过两个人的迭代基本上就会往差的方向发展。一个人如果负责多个业务，对某一个业务模块的熟悉会如果超过0.5年，则会丢失20%记忆，基本上 五次以上，就会丢失部分记忆。大的迭代周期在 0.1-0.2个月，而大的迭代周期会引入多名开发，多名开发除非在进入开发之前如果能对代码有完全的认知，并且代码开发风格统一。但是做到这一点需要长期的调研时间。

        F，减少人的参与

        健康发展，除了CodeReview，如何能摆脱人的参与，因为大家都知道，人脑是代码开发中最依赖，但是最不靠谱的东西。keypath 做到一条线，一条链，链条上的点要记录具体代码，一条业务逻辑的代码被更改了，自动能进行版本diff。通知到相关负责人。需要开发辅助工具的完善。

        G，沟通的融洽，增加理解，减少割裂

        减少组和组之间的嫌隙和割裂。让所有组都等你朝着对整个最终目标有利的方向去发展。每个员工的向量力，最终都是朝着一个方向。

        H，回到APM，继续卷性能，为用户提供更好的服务。

        每一个业务流程都有一个入口，一个出口，一个模块也有开闭口。监控的细节可以落到每一个函数执行的时间和次数。为了用户我们再卷一次。业务开发人员可以制定自己的在APM指标，服务于自己的OKR。

        与其心生敬佩，不如自己便是那样的人

        下面是暴露出的一些要遵循的使用规范和规则。demo地址更新中

        Prepare阶段，想使用分享模块，先注册及拼装

        moduleBiz是预存的一个通用工具类，通过类方法，moduleBiz 可以获取 Desc:(nsstring*) desc

        biz,model,UI, 业务逻辑层（根据时机获取数据，处理数据逻辑+本地逻辑+uiview和uivc的关系管理），数据模型层（请求数据+存储数据+），展示层（UIVC 负责生命周期管理，UIview负责自己的输入和输出）

        // desc 

        (Stirng*) registerModule:(Stirng*)moduleBiz fromParentBiz:(Stirng)*parentID  andLayeratindex:(int)layerlevel {

        Sting bizID  = @“”;

        //##根据父类逻辑，生成当前逻辑

        return bizID

        }

        1，IOC容器化CAServiceContainer

        //注册某个组件或者模块的能力，例如同步，首页，文档，相机，工具箱，Me，这类是无父类

        或者父类是@“CA”，主业务生成之后会有一个基础的单独的阿拉伯数字模块，例如@“1” @“2” @“3”

        然后子业务 传的第一个参数就是 父类的 @“2”，那子业务就是 @“2.34” 这种

        - (NSString)registerBizUnder:(NSString *) bizID andDesc:(NSString *) desc { }

        //参考BizBuilder的创建方式，或者直接复制一套BizBuilder，在其基础上改

        - (void)assameseContainer:(ServicebaseProtocol) protocol andDesc(NSString*) desc ...  {}

        //检查每一个层次下面的所有组成，输出位一个树状图，可以参考TableView折叠展开，

        或者参考github上的树状

        并且给出所有协议是否有类来实现。参考OCLint 添加ruler

        - (void)checkLayer:(Int)Layer {}

        2，能力快照 ServicebaseProtocol

        //这个是为了存储当前UI或者其他工具能力的数据

        需要将自身的BizID，跟数据类型绑定，存在 沙盒中或者工程目录中

        其他能力包括，图片转换，网络请求，数据库操作能力，多线程能力等等

        @required

        - (BOOL)enCodeAbilityWithdata:(NSDate *) data { }

        需要将自身的BizID，拉取存在 沙盒中或者工程目录中数据

        展示当前当前UI或者其他工具能力的数据

        @required

        - (BOOL)showMyAbility { }

        //截图能力

        @required

        - (BOOL)showAnimation { }

        //视频录制能力，比如一个动画，如何展示

        @optional

        - (BOOL)snapShotAbility { }

        //解释非UI能力

        @optional

        - (BOOL)diffAbility { }

        3，基础类建设

        //UIView的Category,用来存截图和数据的结合，数据能直接形成截图，以及如果数据中有多风格影响截图

        怎么去展示和划分

        UIView+SnapShot

        //UIViewController的Category,用来存截图和数据的结合，数据能直接形成截图，以及如果数据中有多风格影响        截图

        怎么去展示和划分

        UIViewController+SnapShot

        //NSObJect的Category,用来存截图和数据的结合，数据能直接形成截图，以及如果数据中有多风格影响截图

        怎么去展示和划分

        这个主要是给非UI类，例如工具类等

        NSObject+Diff

        4，迭代开发

        4.1，现有老逻辑更改 | 能力迭代

        ApplyModifyBizID:(NSString *) bizStr {}

        生成新的能力，满足协议，绑定ID，可以选择是否采用原代码进行填充

       4. 2，新的业务逻辑 | 能力开发

        ApplyAddForBiz:(NSString *) bizStr {}

        5，申请业务流程和业务环

        针对于函数绑定成函数流程和函数环，函数要在实现中对BizID中的第几步进行标注，在标注中进行

        ApplyBizStep:(NSString *) bizStr  andDesc:(NSString *) descStr{}

        ApplyBizCircle:(NSString *) bizStr  andDesc:(NSString *) descStr{}

        函数的包装：

        ClassA *ainstance = [ClassA new];

        更改之前的代码：

        [ainstance fetchdata:"type" andTime:"weekend"];

        改后的代码：

        [ainstance fetchdata:"type" andTime:"weekend" for:"请求首页数据”];

        获取能力，通用UIVC 的instance

        更改之前的代码：

        UIVC *demo = [UIHomeVC New];

        改后的代码：

        UIVC *demo = [commonResolver resolveModule:homebizID];

        [demo SetValue:(NSDict*)];