实习月报（下）
在大数字的实习工作逐步进入尾声了，写写最近一个月的心得感悟。
工作流
团队协作是软件工程中最重要的部分，人们为提高协作效率开发了各种协同工具以及工作流（Workflow）。工作流是一系列工作过程的标准化描述，核心是人；协同工具则是对工作流的辅助，在特定的工作流下提高协作效率，作用于事物。实际过程中，很多开发者局限于对协作工具的使用，而忽视了编码流程的规范，反而导致协作工具成为了开发过程中的阻力，使用效果适得其反。例如，不及时更新 Issue 状态，或者将正在开发的 Axure RP 原型设计稿导出为文件而不是提供在线访问。
团队沟通
有些公司没有协同工作的概念，使用微信、QQ 等公共即时聊天工具作为沟通方式。这不仅为工作环境引入了外部的干扰（非工作内容），也带来了安全隐患（信息泄露、不可控因素）。电子邮件也曾是主流的内部沟通方式，因为其低时效性的特点，比较适合异步通讯（例如缺陷跟踪、事务通知），而不再适合节奏较快的工作环境。现在，企业微信、钉钉、Slack 等平台被广泛使用，解决了传统 IM 的一些缺陷，也引入了电子邮件的群发通知功能。尤其是其可作为 SaaS 以订阅方式提供，也可以进行私有化部署，比较灵活。
对于进行同一项工作且存在异地分支的团队，定期的电话会议是很有必要的。成员之间可以互相提供开发建议，统一工作进度和节奏。
代码质量
代码审查（Code Review）是敏捷开发中很重要的一个部分，每位开发者所提交的代码都将被至少一位开发者进行审计，有效改善了代码质量以及潜在的安全隐患。除此之外，新手程序员能通过 Code Review 的讨论过程学习到一些开发技巧和项目结构，能够更快的融入团队。
在我看来，开发需求较紧张时，开发人员可能会放弃单元测试以及模糊测试，而试图将测试任务甩给 QA 团队甚至永久地搁置。尤其是当项目管理不接触具体开发工作，无法对开发周期做出准确估计时，为开发者下发“加班加点加新功能”的任务会造成非常严重的后果（较差的代码质量）。
知识库
为项目团队维护一份知识库还是挺重要的，不仅便于开发人员理解项目的系统架构，还有助于提高接口测试与沟通效率。
对于编写 API 开发文档，可以使用 Swagger、ApiDocJS 或是由阿里妈妈 MUX 团队出品的 RAP2，嫌麻烦也可以选择 Markdown 或者 Github Wiki（如果项目 Repo 位于 Github）。Swagger 和 RAP2 是非内联形式的独立文档系统，文档数据独立于项目代码，不限制 API 语言类型。ApiDocJS 则是一个内联文档系统（inline documentation），提供从代码注释自动生成静态文档的能力，受编程语言类型的限制。由于文档编写于代码注释，会对项目代码有影响。其所生成的静态页面可以单独部署至 Web 服务器或者进行本地访问。
知识库可以视项目大小选择 Github Wiki 或者 DokuWiki。Github Wiki 可以直接使用 Markdown 进行编写并通过 Git 管理，使用起来较方便，适合项目内小范围使用，但有局限性：只能为有此 Github repo 访问权限的用户提供访问。而 DokuWiki 作为一个轻型的 Wiki 系统，在权限管理上更加自由，允许匿名编辑和访问，也可以通过插件来对接 LDAP 进行集中认证，比较适合公司内部使用。诸如 Confluence 这样的文档协作解决方案也很不错，但是相对的，成本也很高。当然，相比于研发人员的工资，这些生产力工具还是值得企业去选购的。
预定义规范
“所见即所得”的开发模式只适合于 WordPress 这样抽象后的 CMS 表层设计。对于一个从零开发的具体产品来说，还是得有一套预定义的设计规范。包括但不限于：色彩搭配、字体样式、界面布局以及中英文混合排版规范。除此之外，编码规范也很重要，例如接口命名风格、RESTful API 样式以及代码缩进定义。在规范下协作，能很大程度上降低开发人员间的沟通成本，提高团队协作效率。