我心中理想的 Web 开发流程
本文总结一下在几个月的 Web 开发实践后，我认为的目前进行 Web 开发的一些工作流程上的最佳实践。
需要事先声明的是，「最佳实践」这个词是相对的。一方面，Web 开发的世界纷繁复杂，我仅有的经验还远远只是管中窥豹的水平；另一方面，使用不同技术栈的人对某一些问题的答案往往存在争议，不同的人从不同的视角来了解 Web 开发这个庞大的领域，产生不同的理解和世界观也是十分正常的事情，需要理性看待。
前后端分离
都已经是 2016 年了，如果你还只是借助模板引擎在做一些前后端不分离的项目那你已经是 Out 了。
相对于传统意义上的 Web 项目，前后端分离的（本文指的不仅仅是开发模式上的分离，代码上同样也进行分离）Web 开发实践主要有以下几个优点：
前端和后端并行敏捷开发，而不是传统的瀑布式开发模式：大概几年前，主流的 Web 开发模式还是前端基本完成后，后端再在前端基础上进行不分离的开发。而如今，这种开发模式已经跟不上日新月异的互联网世界的步伐。现在，在前后端统一了 API 规范之后，前端和后端的开发完全可以各自独立的进行，甚至是完全不同的立项。不过，在这种模式下，「契约」变得尤其重要。也就是说，一旦前后端对于 API 的约定一旦达成，就不要进行轻易的更改，如果实在是需要更改，则务必及时沟通协调进行修正（关于开发中的「契约」，建议深度阅读这篇文章）。在具体的实践上，我建议前后端先使用 Swagger 进行 API 设计和约定，后端迅速搭建出项目框架并定义好 API（但实际功能尚不实现），这样，一个简单的后端框架甚至可以直接作为 Mock Server 提供给前端进行开发使用，进一步降低前后端之间的耦合（关于 Node.js Web 开发下使用 Swagger 进行 API 文档系统的构建的具体实践，可以参考我的这篇文章）。
适应现在多形态终端的需求：无论是传统的 Browser 还是如今的各种移动端（手机、平板等），在前后端分离之后，后端都只需要进行统一的一次性开发就可以满足各个终端的数据需求，大大减少了工作量。这才是完完全全的后端只处理纯粹的数据，前端来处理应对各种需求的表现形式。
提高 Web 应用的性能：相对于传统模式，不需要进行模板渲染了，而且分离的模式会更有利于利用 HTTP 头来进行浏览器的页面缓存。
以上还只是从实用主义的角度来看待前后端分离的优点，实际上这种开发方式也符合现在流行的「微服务」的理念。各个模块之间完全只通过 API 跟外界通信。只要 API 约定不变，里面怎么改都可以。高内聚，低耦合。
使用现代化的前端框架
商业实践目的的后端开发几乎不可能不使用成熟的框架，前端在近几年也频繁涌现出越来越多良好的开发框架。不过，目前前端在是否使用框架这一点上还是仁者见仁、智者见智。就个人而言，我还是推荐使用诸如 Vue.js、Angular.js、React.js 这样的现代化前端框架。原因在于，使用这些框架可以对前端开发进行更好的分层，从而使得项目变得更加易于维护。是的，我没有说其他原因，而仅仅是分层模型带来的更易于维护的优势。良好的分层架构可以使前端开发摆脱以前混乱且不统一的布局和架构，使得庞大的项目也能得到有效的维护。
Git 与 Code Review
现代开发团队没有不使用团队协作开发工具的，而这之中最重要的工具就是源代码管理工具。
使用 Git（而不是 SVN）吧！Git 是目前设计理念最先进、使用也最广泛的源代码管理工具，相比一些老式的源代码管理工具有诸多优势（不然 Linus 也不会想去重复造新轮子了）。简单举例来说，Git 创建分支只是添加一个引用，十分迅速，而像 SVN 这样的老式工具，几乎只是在 branch 目录下将当前的主分支复制了一遍。如果你们团队还在使用 SVN 等老式的源代码管理工具，那说明你们的开发团队可能已经掉队很久了。
另一个使用 Git 的好处是，方便团队进行 Code Review。我这里说的 Code Review 不仅仅是很多团队口头上说说、实际却只是有空在代码提交 Log 里面随便看看的那种 Code Review，而是要真正落实到制度和规范上的 Code Review。具体来说，你可以利用一些与 Git 相关的现有的工具来实现一些强制的 Code Review 的规则，比如某个人的代码提交之后，会随机抽取团队中的其他三个人在 48 小时内进行 Review，只有三个人全部都 Review 通过之后，代码才真正提交到测试服务器。团队内部甚至可以做一个绩效考核的应用，可视化的展示团队中人员的代码提交以及 Code Review 的次数等指标（排行榜啊什么的，虽然程序员的绩效实际很难考核，但是不涉及实际利益的绩效展示玩具却可以有效激发程序员的创作欲），这样也可以侧面趣味性的激励团队成员进行 Code Review。
对于团队而言，进行 Code Review 的意义在于：
- 代码质量和软件质量的重要保证；
- 缩短团队成员之间技术水平上的差距：看优秀的代码可以有效的提高技术水平，Code Review 不仅会促使成员写出高质量的代码，也会迅速把团队中暂时掉队的成员拉到团队的同一水平线上。实际上，软件开发也是有短板效应的，尤其是涉及到安全领域的开发时（Web 安全是 Web 开发中的重要一环），从这一点上看，Code Review 更加具有非凡的意义了；
- 团队代码风格会更加的统一：简单的制定代码风格规范并不能有效保证团队成员写出风格良好的代码，而 Code Review 机制则可以把良好的代码风格沉淀下去。
自动化测试与 CI
没什么太多可说的，在成熟的团队中，开发人员应该有写单元测试的责任。不写测试的后果是：手动测试浪费大量的人力物力、后期维护极其麻烦且成本高昂（而且任何微小的修改理论上就得手动测试一遍）、代码质量得不到根本上的保证、容易写出架构不合理或者分层不明确的代码。
更进一步来说的话，团队中应该配备有专门的测试人员进行比单元测试层级更高的测试（如集成测试），而且应当尽可能的自动化进行。
如果团队的自动化测试工作做得足够好，那你们应该更进一步考虑整合持续集成（Continuous Integration，简称CI）。这也是前文所说的使用 Git 的优势之一，它对于自动化测试和 CI 都是非常友好的。
至于使用哪种具体的 CI 构建工具，这里没有定论。反正宗旨就是：自动化程度要高、工具鲁棒性要好。
总结
总结一下本文提倡的基本的 Web 开发工作流程：前后端制定 API 规范 –> 前后端完全分离开发（使用框架、Git & Code Review） –> 进行自动化测试 –> CI 整合。