管理小型团队创建大型前端应用的9个经验

• 引言
• 1. 工程师需要自我帮助
• 2. 伟大的产品/代码不能急于求成
• 3. 持续代码重构
• 4. 永远不要承诺紧迫的排期
• 5. 分层架构可以最快交付
• 6. 通过工具严格控制代码质量
• 7. 提升团队成员效率
  • 讨论或指导然后分派任务
  • 告诉开发人员，如果需要，可以稍微改变设计
  • 尽早进行代码审查
  • 时刻跟踪他们遇到的障碍
  • 增加跨团队合作
  • 周五进行内部技术讨论
  • 明确实现标准
• 8. 同相关人员进行快速反馈
• 9. 分离界面和业务逻辑
• 译者注

引言

我从2008年开始用JavaScript作为主要语言编写代码。

2011年11月，我加入了Clickable公司，开始写单页应用程序。

1. 工程师需要自我帮助

在Clickable公司, 前端团队使用tomcat上运行war包启动本地服务器。

配置本地服务器对于UI团队至少我来说十分麻烦。

我就是不愿意在本地机器上运行MYSQL或Java代码。

为了解决这个问题，我启动基于nodejs的http-server用做静态资源服务。

空index.html文件内加载远程load.js脚本。

load.js主要负责从其他服务器加载剩余的资源(js/样式/图片)。

load.js内部有判断逻辑，如果LocalStorage中存在_DEVELOPER_CONFIG变量，它会从开发机器中加载本地资源，否则

继续加载远程CDN服务器资源。

这个小技巧帮助UI团队提升编码效率。因为我们不需要本地配置任何后端服务器，开发过程中只用一些静态服务器。

它也很容易修复线上问题。

以前，我需要在本地环境重现bug，十分耗时。

有了本地服务后，我可以打开线上站点，只需要添加LS变量， 就可以加载本地资源，然后修改本地文件查看变化。

工程师应该在修复别人问题之前首先修复自己的问题。

2. 伟大的产品/代码不能急于求成

离开Clickable后，我加入一家被Snapdeal收购的公司，叫 Unicommerce。

我设计了他们整个前端，他们给我三个月的时间用来调研和设计基础架构。

如果没有这三个月，我不会写出这么好的产品。我知道很多创业公司希望第一天就交付部署。

许多以前的CTO和几乎所有CEO不明白前端日益变化的趋势。JavaScript比时尚业还要流行。

我注意到Unicommerce很多页面都是基本的表单。我编写了一个框架，可以基于配置自动生成表单。

写这个内部框架花了相当长时间。以前写页面也很慢。

完成表单框架后，我们可以相当快的发布新表单。

许多技术人会因为压力而在质量上妥协。他们会采取短期临时方法，但最终会导致不好的产品。

产品业务会赢得一些客户，但你不能发展壮大。

总是听取你内心的想法而不是外部压力，祝你的产品拥有最好的架构。同时向CEO/CTO要求充足的时间。

3. 持续代码重构

一直以来，我意识到一开始追求完美不会有什么益处。

你可能会收获一堆华而不实的架构代码。

相反， 我青睐于持续代码重构。

通过重构，你不会定论任何代码，即使上线后，代码也需要一直改进。

如我直言，线上部署只是提供给客户而已。 你的代码总是伴随你，它是你git仓库的一部分。

如果你仍然有想法改进，赶紧重构。

旧代码一定不能成为新版的瓶颈。

持续重构代码，你可以开发出最佳代码。

永远不要专注于一开始写出最完美的代码，即使上线后，持续改进代码库，持续代码重构可以创造完美代码。

4. 永远不要承诺紧迫的排期

由于承诺紧迫的排期，我吃了很多亏。

排期会打乱你的心态、睡眠和快乐。

我们早上醒来时，我们不会想到今天会因为上班路上的事故而死去。我们都不会这样想。因为我们很乐观。

因为乐观，我们倾向于同意紧迫的排期，但现实中，交付日期会深受未知问题和团队内部误解的害处。

永远不要同意紧迫的排期

5. 分层架构可以最快交付

采用REST架构可以在客户端和服务端进行良好分离。

代码可以不限制分层。分层有两个好处:

• 扩展性

• 快速并行开发

我在最近的项目中把客户端代码分成了:

• 功能界面

• 可重用组件

• 业务逻辑

我们通过npm发布私有包。组件有独立仓库。

这个方法有点耗时，但是如果你有多个产品想要相同的界面行为，这会十分有用。

业务逻辑层应该和界面层保持独立。

多亏React, 我们现在有外部状态管理的好法子。

我会对代码进行分层，代码开发会很快。

任何重复层或代码应该后续被替换。

尽可能把代码分成多层，分离业务逻辑和独立UI界面层。

6. 通过工具严格控制代码质量

使用对应编程模式的严格检查工具， 你可以添加或改进代码质量。

为了保证持续代码质量，我用过很多工具，像: Eslint和很多git预提交钩子脚本。

我一直用git预提交钩子，任何人都不会绕过检查。

如果有人绕过检查会被处罚。

下面是严格检查的几个方面:

• 一致的缩进，eslint规则

• 检查本地配置

• 代码复制粘贴检查器，用来定位跨项目重复代码检查

重复代码检查定位十分有用。

当我发现两个文件的重复代码时，它会提示改进架构。

最简单处理就是删除相同位置的代码然后转移到合适的位置。

一开始，我习惯通过代码审查告知工程师错误。

后来我开始不看重代码审查。

当我发现任何工程师的错误时，我会尝试在流程中增加脚本或严格检查。

例如，我有时发现有人忘记在git中提交文件，一般其他人检出代码，在本地运行时才会报错。

我会写个小脚本添加到预提交钩子检查中，提示工程师避免类似的错误。

严格控制代码质量，通过工具增加严格检查。

7. 提升团队成员效率

为了提升团队效率，我用了很多招。

人们会误以为，通过增加工时或工作量能够提高效率。

我有个提高效率的理论，好招其实是：扫除开发过程中的一切障碍

下面是用来移除工程师障碍的几种方式:

讨论或指导然后分派任务

如果你指导成员选用哪个库或代码以及如何实现，你的成员效率一定很高。

例如，我指派了一个添加全屏按钮的任务，当点击按钮时，应用会变成全屏。

当我指派任务给成员时，他可能会花时间理解全屏API或浏览器兼容性。

如果他好奇心很重，可能会花很多时间在找一个最好看的图标。

找完了图标后，会发现图标无法放到按钮里面。

我就碰到这样的情形，然后为成员提供清晰的建议。

• npm上面有包可以实现全屏API，无需理解内部实现细节

• 可以用font-awesome字体图标

• 按钮要有切换行为，通过管理store或state实现。我给他演示现有组件如何通过切换state变量实现功能，这样他可以直接复用。

• 按钮只是用来网页全屏和其他随机DIV容器全屏。

清晰的方法帮助切断开发人员无用的想象和无尽的搜索，这可以提升效率，一味的要求工程师加快速度无济于事。

告诉开发人员，如果需要，可以稍微改变设计

产品团队的设计文档不会考虑底层架构实现，所有会发生设计文档要求的某行为很难再当前代码中实现。

但设计团队对行为做微调，开发人员就能很容易实现。

如果简单调整设计就可以提升效率，那就直接和设计团队讨论解释。

我称之为设计团队和UI团队之间的谈判。

尽早进行代码审查

组员用4天时间完成代码开发，结果却不能过关，白白浪费4天。

这就为什么需要早期代码反馈或审查？

可以保证工程师在正确的效率轨道上。

时刻跟踪他们遇到的障碍

很多时候，工程师很害羞去分享他们遇到的障碍。

有时他们无法确认他们遇到的问题以致耗费时间。

因此你需要询问他们在哪儿碰到障碍，这样你可以解决他们的问题或者帮着他们继续开发。

增加跨团队合作

我们整个学校和大学都是基于竞争和个体努力。

在学校里，合作意味着欺骗。几乎很多工程师在学校时光中会受挫。

我们成长和团队写作无缘。

你需要指导工程师明白除了孤军奋战，他们也可以求助其他团队的成员。

公司要的是完成任务，但不是100%由一人独自完成任务。

周五进行内部技术讨论

我们在周五下午进行内部技术讨论，大家反响很好，内部技术讨论和展示会让大家充满活力。

这些会帮助提升效率。

明确实现标准

当你找艺术家给你画像时，他可以1个小时或2天完成。这依赖细节具体到什么程度。

一个小时，他可以画出动画或简单素描。

两天，他可以画出十分精细的高品质图画。

同样的规则的适用于软件开发。

每个功能或子功能、简单任务都需要就质量和细节进行讨论。

例如, 工程师可以花2分钟添加一个上传文件图标，设计师需要花一整天时间设计文件图标，因为他人认为

添加一个不同的图标会很赞。

这里我们定义一个质量指数，从0到5。

实现方案质量最高是5，最低是0。

因此，当你指派任务或子任务时，总是告诉清楚质量指数，帮助他们完成任务。

我一般告诉工程师特定任务我需要的的质量等级和执行速度，可以实现高效任务交付。

一些小方法和持续参与和理解工程师遇到的问题可以提升团队效率。

8. 同相关人员进行快速反馈

创业公司里面，即使CEO/CTO也不能确定他们想实现的想法。

许多时候，工程师工作10到15天，结果可能全部或部分被废弃，因为上层并不满意结果。

一般多种原因，错误传达、理解错误等等。

大部分会议中，所有人会远程讨论产品和工作流。

我们也面临同样的问题，所有想到快速反馈循环方法。

采用这个方法后我们开始针对开发分支进行持续部署。

自动部署工程师分支能够帮助上层能够看到工程师的成果以便给出早期反馈，

十分有助于减少生产环境上线新功能的时间。

采取快速反馈循环能让工程师尽早获得产品经理或负责人的反馈。

9. 分离界面和业务逻辑

创业过程中，我们看到需求频繁变更或重新布置。

如果你把业务逻辑和界面逻辑进行清晰分离，即使重构或页面重新设计也很简单。

使用React + Store + Flux开发模式，你可以清晰分割界面和业务逻辑。

曾经Unicommerce公司的一个产品页面很复杂，我花了近一个月的时间编码和保证没有bug。

7个月后，公司要求我重新设计整个页面，重新设计会导致新的bug。

当我开发这个页面时，把业务逻辑和界面层做了隔离，抛弃旧版设计实现新版变得很容易。

大部分的业务逻辑代码不变，或者小改，只有界面层完全重写。

重新设计过程中也不用担心bug, 大部分bug来自业务代码，但我不会去改。

你写的页面会在8到10个月重新实现，大部分业务逻辑不会动。所以对业务逻辑和界面逻辑进行清洗分离。

译者注

• 原文链接

• 因译者水平有限，如有错误，欢迎指正交流