浅谈应用架构

643 views

Published on

Published in: Design
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
643
On SlideShare
0
From Embeds
0
Number of Embeds
50
Actions
Shares
0
Downloads
2
Comments
0
Likes
1
Embeds 0
No embeds

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

    1. 1. 浅谈应用架构 前端分享
    2. 2. 我们曾经为应用架构做过的努力 <ul><li>架构小组的各种工作是应用架构的铺垫 </li></ul><ul><li>Codereview 规范 </li></ul><ul><li>蚂蚁搬家 </li></ul><ul><li>我们应该心存敬畏,不是对未来,是对过去 </li></ul>
    3. 3. <ul><li>文件目录结构 </li></ul>应用架构——天职
    4. 4. 应用架构——天职 <ul><li>CodeReview </li></ul><ul><li>四个维度 </li></ul><ul><ul><li>- 视觉交互 </li></ul></ul><ul><li>按钮状态齐全( -1 ) </li></ul><ul><li>背景图合并( -1 ) </li></ul><ul><li>链接、文字颜色统一规划( -1 ) </li></ul><ul><li>文字行高统一规划( +1 ) </li></ul><ul><li>列间距、块间距统一( -1 ) </li></ul><ul><li>不存在明显的空白区( -1 ) </li></ul><ul><li>不同浏览器下高度、间距、留白一致( +1 ) </li></ul><ul><li>兼容:双倍边距( -1 ) </li></ul><ul><li>兼容: li 定高内浮 +4px 底距 ( -1 ) </li></ul><ul><li>兼容:垂直方向边距折叠( -1 ) </li></ul><ul><li>( img )与文字同行( -1 ) </li></ul>
    5. 5. 应用架构——天职 <ul><li>CodeReview </li></ul><ul><li>四个维度 </li></ul><ul><ul><li>- 前端代码 </li></ul></ul><ul><li>target=_blank ,新开空白窗口( -1 ) </li></ul><ul><li>不兼容的 js 写法, oncontentchange ( -1 ) </li></ul><ul><li>append 在 DOMReady 之前执行( -1 ) </li></ul><ul><li>onDOMReady 嵌套( -1 ) </li></ul><ul><li>避免使用 eval ( -1 ) </li></ul><ul><li>js 死循环导致内存溢出,典型的 <img onerror=“”/> ( -1 ) </li></ul><ul><li>粗心大意疏忽问题( -1 ) </li></ul><ul><li>CSS|grid 层或 block 层以下才能使用 mt8 这种零碎的 class 名( -1 ) </li></ul><ul><li>CSS| 不允许使用标签级别的样式定义,比如: img{display:block} ( -1 ) </li></ul><ul><li>CSS| 避免使用 id 选择符定义样式( -1 ) </li></ul><ul><li>… </li></ul>
    6. 6. 应用架构——天职 <ul><li>CodeReview </li></ul><ul><li>四个维度 </li></ul><ul><ul><li>- 模板代码 </li></ul></ul><ul><li>预览页面不得出现 velocity 模板变量名( -1 ) </li></ul><ul><li>css 文件有通过宏写入到 head 里,页面独立 js 文件放页底( -1 ) </li></ul><ul><li>同一功能模板 control 控件由一个变成两个,修改成本 X2 ( -1 ) </li></ul><ul><li>生成新的产品线模板 control ( +1 ) </li></ul><ul><li>对 grid 或 block 以下内容切割静态位( +1 ) </li></ul><ul><li>整理了历史遗留的问题页面( +1 ) </li></ul><ul><li>请求使用 form 表单作为容器,杜绝了请求地址写死在 js 里( +1 ) </li></ul><ul><li>使用产品线统一的翻页宏( -1 ) </li></ul><ul><li>… </li></ul>
    7. 7. 应用架构——天职 <ul><li>CodeReview </li></ul><ul><li>四个维度 </li></ul><ul><ul><li>- 文件结构 </li></ul></ul><ul><li>破坏了架构师设计的文件结构( -1 ) </li></ul><ul><li>每个页面都有唯一的 css/js 文件和产品线统一的 css/js 文件( -1 ) </li></ul><ul><li>明显的功能块未做成独立的文件( -1 ) </li></ul><ul><li>竭尽所能的抽象出功能块( +1 ) </li></ul><ul><li>Css 和 js 相对应文件命名一致( -1 ) </li></ul><ul><li>Js/css 文件重复或同一功能的不同版本( -1 ) </li></ul><ul><li>每个文件顶部或代码片断中都有清晰的注释( +1 ) </li></ul><ul><li>… </li></ul>
    8. 8. 应用架构——天职 <ul><li>执行力 </li></ul>
    9. 9. 谢谢!

    ×