共计 2742 个字符，预计需要花费 7 分钟才能阅读完成。
身为前端，不应该只会做网页。应该时刻对产品保持深刻的思考：这个产品的价值是什么？它是如何带来收益的？如何更好地满足需求、实现其价值？在这篇文章我将分享一些我的思考，以应用的类型来分类讨论。
发布 / 展示型
比如论坛、博客平台、微博、新闻门户、信息展示平台（如 58 同城、大众点评）。发布者可以是管理员、商户、普通用户。
业务分析
业务上，产品的目标是促进双方沟通和互动（比如 58 同城连接买卖双方、大众点评连接消费者和消费者）。分类、搜索、推荐、SEO 对于业务有很重要的作用，产品应该竭尽全力地将用户引导到最有价值的内容上。
技术分析
服务端主要负责存储，前端负责展示。前后端的交互相对比较简单，主要是提交和获取数据。在这种应用中，最重要的页面应该就是首页、列表页和详情页了。对于首页，一个很重要的特性是：不同用户看到的首页应该是不一样的，首页应该针对具体用户展示个性化的数据。即使没有能力用机器学习来做推荐信息流，至少也应该允许用户选择自己感兴趣的内容、允许用户将经常访问的专栏放在首页，将用户最快地引导到最有价值的内容。对于列表页，应该做好内容分类、过滤、检索。在这方面可以学习 leetcode：
严格来讲 leetcode 不属于这里讲的发布 / 展示型应用，它的主要卖点在于在线评测。不过，好的 UI 设计理念是通用的。另外要注意，好的 UI 设计应该是有自己的风格的，或紧凑务实，或简洁大方，或特立独行，考虑用户群体和应用的定位以后再做决定。
对于详情页，需要具体分析。做好 SEO 往往有很大的帮助，利用用户发布的内容吸引更多的用户。另外，在主要内容的结尾展示一个”相关推荐“也是一个好主意，引导用户浏览更多的内容。如果对于业务有帮助，可以考虑加入更多的多媒体形式，比如视频、图片、更多的文本格式（富文本）。
这种应用复杂性相对较低，开发人员不会很多，协作成本比较低，因此做好代码复用是一个基本要求，这有助于最大化开发效率，并为后续迭代降低工作量。加载性能对于这种应用也非常重要，前端应该投入更多精力。在性能优化上我会专门写后续文章，读者可以先参考 awesome-learning-resources 中的资料。可以看出，在发布 / 展示型应用中，前端要解决的问题主要是代码上的问题（UI 优化、性能优化、代码复用）。
业务流程在线化
比如淘宝、美团外卖、滴滴打车、企业内部采购平台。大部分业务流程都是交易流程、事务处理流程。
业务分析
将业务流程搬到线上，其意义包括：
各参与方可以方便地、流水线式地完成自己的业务部分，减少各参与方的沟通成本和闲等时间。
将流程步骤标准化和清晰化，从而减少失误和意外。
记录流程，以便进行追溯和统计分析。
业务流程中涉及到的信息交流应该全部在线完成（比如填写 / 审批申请单）。如果业务流程有不可避免的线下操作、系统外部操作（比如收 / 发快递），那么系统也应该接入相关外部服务 (比如快递、银行)，对这些操作提供记录和追踪的功能，保证系统能参与到、影响到业务流程中的每一个方面。
技术分析
用户与系统之间的交互大大增加，前后端交互也大大增加。不同的流程有不同的交互方式（不过基本都是表单），后台逻辑甚至更加复杂。业务流程多种多样，业务逻辑纷繁复杂，并且出现 BUG 会有相对更加严重的后果。因此，质量管理在这种情况下非常关键，测试应该覆盖到各个业务场景和逻辑。发布前构建，引入工程链的体系，搭建低容错、自动化的开发流程。使用前后端监控，从而能够尽早发现问题、方便排查故障、为性能优化提供指标。
整个系统需要很多开发人员来共同完成，分别负责各自的业务流程。并且不同的业务流程之间可能需要共享数据、互调接口。这大大增加了开发人员的沟通协作成本。为了降低它，可以通过以下手段：
做好模块化管理和前后端分层，解耦不同层的工作。分层的好处如下：
将瀑布式的开发流程转变为并行开发流程。瀑布式流程：程序员 A 需要等待程序员 B 开发完成（从而 A 能使用 B 开发的功能），程序员 B 需要等待程序员 C 开发完成。并行开发流程：各个负责人在约定好接口以后就能同时开始开发。
降低单层的复杂度。有利于开发者的关注点分离、面向接口编程。提高系统灵活性、开发效率。
解耦以后能够对各个层进行单独的测试、性能监控、异常监控，更加有针对性。解耦以后更新维护也更加容易。
统一代码规范和接口规范，以降低接手成本。
识别出能够被进一步抽象和标准化的逻辑，进行封装。
采用微服务架构，有助于解耦业务逻辑、独立演化。
如果用户量很大，还会对系统的性能提出更高的要求。根据业务特征，进行以下优化：
优化代码，从而能够更加高效地完成业务计算；
优化通讯开销，降低不同服务之间、前后端之间的通讯量和通讯时间；
优化应用架构，提高系统的可扩展性，增加高并发处理能力。
可以看出，在业务流程在线化这种类型的应用中，开发者要解决的问题主要是人的问题（管理的问题）和系统效率的问题。前端不能局限于用框架写页面，更要从工程师的角度来优化开发流程和系统效率。不仅要关注软件最终的运行结果，更要关注开发流程建设、团队建设、基础设施建设、系统架构建设。
委托系统进行某种操作
比如系统控制平台、运营平台、leetcode。
业务分析
这种产品的业务逻辑比较简单。用户使用它们的目的，主要是委托系统（主要是后端）完成某种操作 / 计算，这个操作的结果能够满足用户。比如用户通过系统控制平台来修改其他系统的配置和行为。有一些控制平台还拥有监控的功能，后端会持续收集某个系统个各个指标，前端对这些指标进行可视化展示。又比如用户通过使用 leetcode，让后端运行评测，从而检验自己答案的正确性（leetcode 的主要部分就是发布 / 展示平台 + 评测系统）。
技术分析
技术上的主要难点在于如何进行模块划分，为其他开发者、用户提供简单的抽象（思维模型）。
一个好的抽象的例子：一个控制系统用来管理上万台机器（节点）的运营。系统将这些节点按照树状结构组织起来，就像文件系统一样：同一个机房的节点用一个文件夹（大节点）组织起来，同一个城市的节点用一个文件夹（大节点）组织起来。然后，提供一幅世界地图，每个城市节点在其中标注出来。通过 UI 或脚本，可以批量选择、批量操作节点。
前端上，如果需要展示的数据（操作的结果），还需要将数据充分可视化。提高用户高效操作（大批量）数据的能力。后端的技术特点取决于它为用户完成什么样的操作。后端的 API 应该提供比较合理的抽象和封装。
注意，这些产品分类不是互斥的，有可能一个产品在某个功能上像 A，在另一个功能上像 B。我们应该学会分析产品的方法，而不是套用现有案例。
你的产品是什么样的？这个产品的价值是什么？它是如何更好地满足用户需求、实现其价值的？欢迎与我分享！
相关阅读
阿里 9 年，我总结的前端架构演进 3 大阶段及团队管理心法
