[笨蛋熊] 「架构师」流程精讲：第三节 - 基础框架设计 [复制链接]

一：项目指标设计
标题有点唬人，实际上很多公司的项目也都是这么设计起来的。

所以我们才会听说关于造船的笑话（产品经理：我们可以提供这样的设计、架构师和程序员：我们可以提供这样的方案、估时：1年、领导：不行，一个月内搞定、程序：立刻编码、测试：提前单元测试……最后苦了这帮人肉运维）

这件事是如此重要，以至于有经验的开发团队，从来都不会在这方面节约时间。

同样的，也有很多水平不太够的团队，非要扣时间，最后项目烂尾，发现修复BUG和重构功能的时间完全失控。

不管是个人开发者，还是一整个开发团队，能够准确的掌握好项目指标，并根据指标给出设计和解决方案，都是非常重要的能力。

那么怎么设计项目指标呢？不妨先问自己几个问题：

这个项目的逻辑复杂度如何（如果用一个函数把整个项目写出来，大概要嵌套多少层判断和循环代码，这决定了项目的复杂度，越复杂的逻辑越容易踩坑，调试成本和容错代码相应的也要增加很多）
这个项目的模块耦合度怎么样，不同功能模块的依赖关系是否清晰，有迹可循（A用了B，B用了C，C用了A？这决定了项目能不能模块化拆分，模块化后单元测试实现了，项目出问题好追溯，反之可能原地爆炸）
试着画，或者模拟一下项目的架构图，层级关系是否清晰，跨层级组件是否明确（架构混乱，代码的可维护性必定跟不上，等着被客户骚扰把）
数据是集中管理还是分步处理，数据的传递和容错怎么处理？（数据是编程的核心，所有代码最终都是为了数据服务的，一旦数据乱了，逻辑很难不出问题，怎么管理好数据是非常重要的学问）
最重要的是，这个项目的预期质量要求是什么，使用年限有多久，开发周期要求多久？（这个有多坑下面说）

可能还有更多需要考量的点，但无疑这些点是每一个项目管理者，不管你的项目是大是小，是盈利还是公益，都得考虑清楚的。

这些坑但凡踩中一个，等待你的都将是原地爆炸，尤其是商业工程，踩一个坑，基本上项目就活不了了。

最坑的是最后一个，因为决定者不一定是你，举个例子，项目使用年限预期3年（就是说3年内出了问题都必须要维护），质量要求较高，符合标准的话，开发周期3个月，需求方要求一个月开发完成，这活你要是敢接，那恭喜你了，你不爆炸谁爆炸？

任何时间都可以压缩，架构的时间绝对不能压缩，地基决定了建筑的上限，地基不大好，后面出问题根本改不了，直接积重难返。

怎么打好地基？设计好项目指标！

项目逻辑和不同的流程负责的部分提前思考清楚，基于此，把功能模块拆分清楚，数据结构提前规划清楚，这样项目的模块就出来了，架构图也出来了，指标也出来了，这个过程并不需要花费很多时间。

最上层的逻辑单独提炼出来，设计相应的输入（界面、选项、数据来源等）、输出（结果、数据统计、日志等），这些东西穿起来，不就是项目的顶层逻辑嘛，这里不要设计的太复杂，能分模块尽量分模块，不然出个屁大点的问题都要整体重跑，会不会有种想死的冲动？

然后开始进入不同的模块设计。



二：模块指标设计

顶层逻辑确定之后，开始设计分模块指标，前两节课的东西就能用上了。

先确定模块的指标和数据，指标就是容错程度，逻辑的组织方法，也就是第二节的那些写法怎么组合在一起。

数据就是输入和输出，程序开发时，IO是如此的重要，I就是Input，输入，O就是Output，输出，一个功能模块的实现，本质上就是输入和输出，在数学里，就叫函数，当然，编程也沿用了这种叫法，所以一个功能模块的本质，就是处理数据的输入和输出。

对于按键这种脚本语言，模块经常是用一个或者多个命名类似的函数实现的，输入通常是用全局数据，或者参数实现的，输出通常使用全局数据，或者返回值实现的。

按键精灵X支持表，组织数据的能力比较强，按键精灵2014则差一些，因此我推荐新的项目尽量用按键精灵X实现。

然后说说指标，指标在这里主要指冗余程序，说白了就是容错能力，要是你的代码全程 FindPic，MouseClick，一点容错不写，那肯定一点小的干扰直接就原地爆炸了。

所以我们需要第二节课的各种经典写法，来吧流程穿起来，第二节课需要反复看，每一种写法都用熟了，熟到闭着眼睛就能写出来，熟到代码一看，各种写法就能摘出来，这样这些写法的代码行数多，就不再是缺点了，很多初学者都差在代码行数掌握能力不行上，几百几千行代码就头晕，几百行代码能有几十种写法，别说你了，给编程大师看这堆屎山他也头晕啊，记住了，真正牛逼的代码，是初级工程师也能看得懂，改的动的代码，别没事净整些奇形怪状的写法，多用标准写法，这样就算十万行，你的代码也是可维护性高的。

另外也别整一层一层的调用，尽量遵循平坦的原则，自上而下，不要跳来跳去，跳来跳去的地方，尽量用标准写法。

懂得了这些，你的模块设计应该就出来了把？

如果是打开背包 - 寻找道具 - 使用道具 - 输入数据 - 实现功能，这样的串行代码，且每个步骤都可能受到干扰的情况下，则你在设计这个功能模块的时候，就得使用带优先级的双循环结构，一个是优先级，一个是流程自我修复。

如果是：打开一个网页 - 等待网页打开 - 填写一个表单 - 等待表单结果 - 记录操作结果，这样的串行代码，一个步骤完成后状态就确定了，那就得用带超时的特征等待，再加上重试机制，这样出错了，重置环境整理重跑几遍，直到成功了为止，要是连续失败，那就可以记录原因，排查错误了。

你看这样规划好，是不是代码也知道怎么写了，以后出问题也知道怎么调试了？

不费劲把。

也别在日志上省时间，每个步骤都好好的记录日志，出错了能成百上千倍的节约时间







这节课纯理论了，就先写到这吧，虽然罗里吧嗦的讲了一大堆，但内容是干货满满的，下两节课我会提供两个完整的脚本，包括从设计阶段，到开发阶段，到维护阶段的思考，以及完整的源代码，应该会晚点发出来。

暂定两个课题吧，一个是Excel读内容填表，一个是多开群控。