![我们曾经为应用架构做过的努力 ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
Plus de fangdeng
Plus de fangdeng (20)
浅谈应用架构
- 1. 浅谈应用架构 前端分享
- 9. 谢谢！
Notes de l'éditeur
- 此次分享的主要目的是回顾过去我们做的应用架构相关的努力，发现其中的不足之处。反思我们的问题出现在哪里。 结合标哥对未来前端的展望和社区目前所做的特殊工作，分析作为新时代的应用架构这一角色该承担什么样的职责。
- 原架构组做过一些开创性的工作，给后面的应用架构铺好了道路，早期应用架构的工作定义其实是沿着原架构组设定的方向走下去的，其核心体现就是 codereview ，而 codereview 有个前提，就是确定实现方案，一个有问题的或不完善的实现方案，对它去做 codereview 好比南辕北辙，于是衍生出了应用架构的第二大职责，前期实现方案讨论。 和千变万化的代码不一样，有些东西本应是一成不变的，相对的一成不变，比如说框架，比如说规范，比如说文件目录结构。一成不变的是灵魂，千变万化的是女人的衣服 我觉得，我们的最大问题就是框架、规范、文件目录结构还没有做到一成不变。这些反映出来的更大的问题是，我们的开发模式还没有形成，我们的灵魂还不够健壮。原架构组在这方面做了很多工作，说到这里，就不得不提蚂蚁搬家。 我们痛，是因为我们一开始没有把握住这些一成不变的东西。假设在网站架构起来的第一天，假设在我们前端还只有两三人的时候，就有一位神人告诉我们，你们这几个人要集合在一起，把框架、规范、文件结构定下来，再用 codereview 的方法限制后面进来的新人，不要让他们做出违反规定的行为。当然现实中这位神人是不会存在的，而问题扩散了，就像疾病蔓延，现在只能通过假设来寻找问题的根源，寄望从假设中找到指引我们前进的路标。 遗憾的是，我们必须忍受着越来越沉重的痛，继续走我们之前走的路。问题是，我们该有什么改进。
- 之前提到过应用架构的职责之一，前期参与设计方案讨论，在这个讨论，架构师们只需要把好关，把不合理的设计挡在门外，或根据资源的情况推掉或简化一些复杂的设计。这个环节我觉得仅仅这样做好不够，这个更像是需求分析师，而不是架构师。我们应该找到一些更符合架构师特点的定义。这里，我会重提旧事，以文 件 目录结构为核心展开探讨。蚂蚁搬家，方向是正确的，但方法上需要完善。架构师的一个天职，为产品设计好文 件 目录结构。
- 曾经，我们执行过 codereview ，但是效果不是很好，有很原因在里面，我觉得最重要的原因是，缺少一个提纲性质的东西，要一个切实可行的提纲。打分也是个问题，好 一般 差 让打分者很难决定，而且不同的组长打分，标准也不一致。我们需要一个是和否的严格打分表，没有模棱两可，或者将这种模棱两可降到最低限度。这里我提出一个加分和扣分原则，把所有能加分或要被扣分的点描述出来形成一张列表，这就是我刚才说到的提纲。每个人都有一个初始分比如说 100 分， codereview 过程中，遍历列表里所有的描述点，该加分的加分该扣分的扣分，如果没有涉及到描述点，不加分也不扣分。最后我们得出来的分数就能准确反映某位同学在某个需求或项目里的质量表现。
- 曾经，我们执行过 codereview ，但是效果不是很好，有很原因在里面，我觉得最重要的原因是，缺少一个提纲性质的东西，要一个切实可行的提纲。打分也是个问题，好 一般 差 让打分者很难决定，而且不同的组长打分，标准也不一致。我们需要一个是和否的严格打分表，没有模棱两可，或者将这种模棱两可降到最低限度。这里我提出一个加分和扣分原则，把所有能加分或要被扣分的点描述出来形成一张列表，这就是我刚才说到的提纲。每个人都有一个初始分比如说 100 分， codereview 过程中，遍历列表里所有的描述点，该加分的加分该扣分的扣分，如果没有涉及到描述点，不加分也不扣分。最后我们得出来的分数就能准确反映某位同学在某个需求或项目里的质量表现。
- 曾经，我们执行过 codereview ，但是效果不是很好，有很原因在里面，我觉得最重要的原因是，缺少一个提纲性质的东西，要一个切实可行的提纲。打分也是个问题，好 一般 差 让打分者很难决定，而且不同的组长打分，标准也不一致。我们需要一个是和否的严格打分表，没有模棱两可，或者将这种模棱两可降到最低限度。这里我提出一个加分和扣分原则，把所有能加分或要被扣分的点描述出来形成一张列表，这就是我刚才说到的提纲。每个人都有一个初始分比如说 100 分， codereview 过程中，遍历列表里所有的描述点，该加分的加分该扣分的扣分，如果没有涉及到描述点，不加分也不扣分。最后我们得出来的分数就能准确反映某位同学在某个需求或项目里的质量表现。
- 曾经，我们执行过 codereview ，但是效果不是很好，有很原因在里面，我觉得最重要的原因是，缺少一个提纲性质的东西，要一个切实可行的提纲。打分也是个问题，好 一般 差 让打分者很难决定，而且不同的组长打分，标准也不一致。我们需要一个是和否的严格打分表，没有模棱两可，或者将这种模棱两可降到最低限度。这里我提出一个加分和扣分原则，把所有能加分或要被扣分的点描述出来形成一张列表，这就是我刚才说到的提纲。每个人都有一个初始分比如说 100 分， codereview 过程中，遍历列表里所有的描述点，该加分的加分该扣分的扣分，如果没有涉及到描述点，不加分也不扣分。最后我们得出来的分数就能准确反映某位同学在某个需求或项目里的质量表现。
- 我们不是没有这样做过，是我们做的还不够，我们的执行力还很弱，我们要想有所成就，不能一味的抛弃过去，而是发现不足，加以改正。我们一个很大的不足就是执行力不足。很多问题我们都只停留在讨论层面，往往时间一久，讨论的东西也就搁置了，我们需要普遍的达成一致，我们几个大头更应该达成一致。想当初做蚂蚁搬家，讨论文件结构，每个人都说出了自己的想法，但是没有达成一致，这是很不好的一件事情，也许我们的不同想法在关键点上都是一致的，比如目录结构，也许就是目录名字不一样，内在精神都是一样的，那为什么我们不尽快把这一层东西定义出来，固定下来，我们缺少的就是固定的东西，我之前也说过，固定的东西才是我们前端的灵魂，由此看出，我们在加强我们的灵魂建设上还需要走很长一段路。