HQY 一个和谐有爱的空间

大暑已至，实习的日子也过去了一半。在短短的四周中，接触了不少新技术，也总结出了许多经验。

1. 思想理论对于编码实践有着极其重要的指导作用。

   月初逛论坛时看到一条回复：

   标题：前端的技术更新换代速度是不是有点快？ - V2EX
   @xuanbg：MVC 模式还是 76 年提出来的呢，前端的同学用上才几年。。。

   大概十多年前，互联网还没有前端开发者这个概念。由于当时网站基本使用表格布局或 Flash，而不是如今的 DIV + CSS 的布局，前端开发工作基本由后端完成。许多站点通过将前端代码硬编码于后端代码，配合 iframe 和后端语言的 include 语句，构造标准的表格式单页。

   Web 2.0 技术之后，UGC 内容逐渐成为主流，前端技术也不再局限于简单的表格布局，各种技术栈百花齐放，诞生了 jQuery、Dojo 等一系列开源 JavaScript 框架。CSS3 与 HTML5 标准的出现也极大地推动了前端技术栈的发展，人们开发出各种炫酷的交互动画，甚至可以通过 WebGL 实时渲染 3D 模型。Bootstrap 等前端 UI Kit 的出现则将前段开发者们从手写代码中拯救了出来，模块化的响应式布局成为主流，Web 前端页面的基本构建逐渐变得简易上手，由此也催生了一大批前端培训班。

   在我看来，一个优秀的前端工程师除了掌握各种 Web 技术与开发框架之外，还需要具有一定的审美能力与设计理念。对于 to B 的产品可能不需要考虑太多用户体验上的需求，但是如果是面向普通用户，用户体验很大程度上影响了用户留存与活跃时间。

2. 慢下来，提高代码质量。

   没经验没能力的软件开发团队一开始就冲刺/加班加点地加新功能，几个月后就慢下来了，所有时间都在修 bug，没精力去加新功能。
   —— 软件开发过程中，先慢下来，才能将来跑得更快

   前期开发过程中缺少 Code Review 及自测等评估环节，加上一些不合理的产品设计，我们耗费了大量的时间在变更需求和寻找代码缺陷上。和一位曾在某一线手机厂商工作的朋友聊起工作流，其公司生产环境代码小版本一月一更，大版本甚至一年才发布一次。当然，处于开发期的项目迭代本就应该比维护期的项目快许多，但是如果不使用 CI/CD 以及自动化测试等解决方案，后期推进将变得非常困难。

3. 预留数据审查中间件，做好安全措施。

   如果发现一个产品在安全（包括但不限于权限管理）方便不讲究了，说明他们内部在为 KPI 赶进度了。因为安全领域是花费最大却看不到成果的地方。
   —— Weibo@老毒师

   2018 年是区块链的风口，但不知有多少交易所和私链因为代码缺陷所致的安全问题而崩盘，无论是运营者还是用户都损失惨重。但就目前看来，各个项目（除了互联网金融方向）的开发过程中仍然是业务线优先，安全、风控最后。在我们的项目初期，前端未考虑对用户做防呆设计以及数据预过滤，后端也基本未对接口数据做鉴权或合法性校验。作为一个暴露在公网的在线服务，是非常危险的。

4. 产品需求一定要明确，做好任务进度可视化。

   在前段时间的课设中，我们尝试应用了 Github Kanban 作为敏捷开发管理工具，对项目进度进行把控。作为一个辅助工具，它并不具有什么魔幻能力，但却能直观地掌控项目的功能粒度上的开发进度，优化需求下发流程。使用 IM（如微信、蓝信等即时聊天工具）及电子邮件作为需求下发方式的形式是一个没有缓冲区的 [生产者-消费者] 问题。通过引入看板作为缓冲区，开发者完成手头任务后即可查看后续需求，产品经理也无须为此在群里 at 全体成员，打断所有人正在处理的事情。这不仅可以避免开发人员工作时间不饱和，还有助于提升开发效率。

在大数字的实习工作逐步进入尾声了，写写最近一个月的心得感悟。

工作流

团队协作是软件工程中最重要的部分，人们为提高协作效率开发了各种协同工具以及工作流（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 样式以及代码缩进定义。在规范下协作，能很大程度上降低开发人员间的沟通成本，提高团队协作效率。

推荐本站淘宝优惠价购买喜欢的宝贝:

本文链接：https://hqyman.cn/post/8654.html 非本站原创文章欢迎转载，原创文章需保留本站地址！

休息一下~~