《产品前端架构》课堂交流区问题汇总

本课程为网易云课堂 - - 前端开发工程师 - - 《产品前端架构》学习总结

版本管理

问题一：分布式版本控制(DVCS) 对比集中式版本控制系统(CVCS)

  由于Git的持续火热， 对于DVCS与CVCS的争论和对比越来越多了， 似乎很多文章都倾向于这个观点：

" Git这种DVCS 要比SVN这些DVCS要优越" 

  实际情况真的是这样吗？ 现在请同学们各抒己见， 以各个方面来分析下CVCS与 DVCS之间的优缺点.

回答：

  分布式版本控制 (DVCS) :一种不需要中心服务器的管理文件版本的方法，但是它也可以使用中心服务器。更改可以被合并到 DVCS 的任何其他用户的系统中，因此可以实现非常灵活的工作流。

主要优点：

• 版本控制更加灵活，因为它除了支持传统的（集中式）工作流，还支持其他各种工作流；

• 比集中式服务器快得多，因为大多数操作在客户机本地进行，而不需要网络操作。

  集中式版本控制（ CVCS）：这类系统，诸如 CVS、Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。

优点与缺点：

• 每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。

• 最显而易见的缺点是中央服务器的单点故障。 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。

DVCS 和集中式版本控制系统的主要差异：

  在 DVCS 和集中式版本控制系统之间有三个关键差异：

• DVCS 通过本地提交支持离线工作，这是由 DVCS 的操作方式决定的。这与集中式版本控制完全不同，集中式版本控制要求通过到中心服务器的连接执行所有操作。这种灵活性让开发人员在飞机上也能够像在办公室中一样轻松地工作，可以一次又一次地进行提交。

• DVCS 比集中式系统更灵活，因为 DVCS 支持许多不同类型的工作流，从传统的集中式工作流到纯粹的特殊工作流，再到特殊工作流和集中式工作流的组合。这种灵活性允许通过电子邮件、对等网络和开发团队喜欢的任何方式进行开发。

• DVCS 比集中式版本控制系统快得多，因为大多数操作在客户机上进行，速度非常快。另外，在需要进行推（push）操作（与另一个节点通信）时，速度也更快，因为两个客户机机器上都有完整的元数据。速度差异相当显著，根据使用本地存储库还是网络存储库，DVCS 比Subversion 快大约 3-10 倍。

观点分析：“Git这种DVCS 要比SVN这些DVCS要优越”

• SVN属于集中化的版本控制系统，SVN使用起来有点像是档案仓库的感觉，支持并行读写文件，支持代码的版本化管理，功能包括取出、导入、更新、分支、改名、还原、合并等。SVN大都采用图形界面操作，直观，上手快。

• Git是一个分布式版本控制系统，操作命令包括：clone，pull，push,branch ,merge ,push,rebase，Git擅长的是程序代码的版本化管理。不支持中文，图形界面支持差，使用难度大。不易推广。

• SVN更适用于项目管理， Git仅适用于代码管理。

• 一个研发队伍的成员正常包括：需求分析、设计、美工、程序员、测试、实施、运维，每个成员在工作中都有产出物， 包括了文档、设计代码、程序代码，这些都需要按项目集中进行管理的。SVN能清楚的按目录进行分类管理， 使项目组的管理处于有序高效。而很容易的实现了对本地代码修改的记录，而这整个过程中，根本没出现服务器。

其他详细内容参考下面推荐文章。

• Git和SVN之间的五个基本区别；

• SVN和Git比较，哪个好用，适用？

• 版本控制：SVN和GIT的一些使用感受

• 关于本地、集中式、分布式三种版本控制系统

• 分布式版本控制系统入门

问题二：在命令介绍中 多次提到的 – 是用来做什么的？

在课程中， 可以发现讲师多次在命令中使用到了 – 符号， 比如

git checkout -- <filename>

事实上 很多时候 你使用 git checkout 也不会有问题。

那么问题来了， – 到底是用来做什么的呢？

回答：（这个是参考别人的）

--代表后面的参数是命令，如果没有--，一般指分支或者路径。

主要是用来区分文件目录和命令的关系。

题目中“--”后面的表示把后面连接的参数当做文件名，不管它长什么样子。它是unix的命令行规范。通常，我们使用“--”去区分后面的是一个命令还是一个参数。比如下面例子：


rm -f      # does nothing

rm -- -f   # deletes a file named "-f"

一般我们通过使用它来区分文件名和命令参数，如果一个文件名刚好和我们常用的命令冲突了，--就可以很好的解决这个问题。


通常都会加上“--”来区分使用。

具体规范和标准可以看unix命令行参数语法规范标准，IEEE Std 1003.1, 2013 Edition标准

Guideline 10:

The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character.

问题三：某文件在暂存区与工作目录的内容不一致时， 使用git checkout HEAD – 将导致什么结果？

解答：

**结论：**git checkout HEAD – 将内容从上次提交复制到工作目录。当某文件在暂存区与工作目录的内容不一致时， 使用git checkout HEAD – 将导致工作目录被上次提交的覆盖，这时候暂存区也就没有修改了，clean掉了。其实就是本地和暂存区都被上一次的提交覆盖了。

简单实验了下，测试过程如下：

1、首先新建了一个test.txt文件，文件是空的。这时候我们将test.txt add到暂存区，此时暂存区存在新的文件test.txt。

2、将暂存区的修改提交到提交区，这时候暂存区也就没有需要提交的东西了。

3、本地修改test.txt文件，随便输入一些字符。此时test.txt文件大小为1KB

4、此时，查看暂存区，发现暂存区存在修改文件，test.txt，这时候，test.txt文件在暂存区与工作目录的内容不一致

5、执行git checkout HEAD – ，发现暂存区不存在修改文件，查看本地目录，test.txt文件已经为空，被上次提交区的空test.txt覆盖

此时test.txt文件为空，0KB

问题四：为什么大部分情况下，git fetch 要优于直接使用 git pull?

不难发现， 课程中对于可能常用的 git pull 命令着墨不多. 而把大量的时间放在了 git fetch + git merge 的工作原理上。

同学可以总结下，为何使用git fetch来分步骤处理 要优于直接使用git pull？

回答：

  git pull的问题是它把过程的细节都隐藏了起来，以至于你不用去了解git中各种类型分支的区别和使用方法。当然，多数时候这是没问题的，但一旦代码有问题，你很难找到出错的地方。

  将下载（fetch）和合并（merge）放到一个命令里的另外一个弊端是，你的本地工作目录在未经确认的情况下就会被远程分支更新。当然，除非你关闭所有的安全选项，否则git pull在你本地工作目录还不至于造成不可挽回的损失，但很多时候我们宁愿做的慢一些，也不愿意返工重来。

  前面那些行显示出“git fetch”命令会将哪些文件下载到本地，这些文件一旦下载到本地之后，就可以在本地进行任意操作了。

  “git fetch”命令执行完毕之后，还不会立即将下载的文件合并到你当前工作目录里，这就给你了一个选择下一步操作的机会，要是想将从远程分支下载的文件更新到你的工作目录里，你需要执行一个“合并（merge）”操作。

  单独进行下载和合并是一个好的做法，你可以先看看下载的是什么，然后再决定是否和本地代码合并。而且分开来做，可以清晰的区别开本地分支和远程分支，方便选择使用。

文章推荐：Git 少用 Pull 多用 Fetch 和 Merge

技术选型

问题一：市面上这么多种模块系统， 它们之间可以相互转换吗

  AMD、COMMONJS、CMD、UMD、ES6 Module、IIFE… 这么多的模块写法， 一旦你选择了一种模块写法，那它在另一个系统中就可能无法运行了。 值得庆幸的是，现在越来越多的工具可以帮助我们将js从一种模块写法转换为另一种写法， 你能帮助同学们列举出一个或多个转换工具吗？

回答：

1、Browserify

兼容 Node 模块引用语法和 Node 模块化文件加载方案, 
浏览器端运行前需要完成代码的合并, 并配合 SourceMap 进行调试. 

2、Webpack

它能把各种资源，例如JS（含JSX）、coffee、样式（含less/sass）、图片等都作为模块来使用和处理

3、Component

是一个对客户端 JavaScript 包进行管理的工具，用于更好的构建 Web 应用，编写模块化 commonjs 组件

4 rderjs

一个开源的 JS 按需、异步加载工具，同时也是 JS 模块化管理工具。

5 systemjs

一个最小系统加载工具。

问题二：关于通信解决方案 xhr 与 socket的取舍

  视频里介绍了一个双向实时通信解决方案socket.io。你能说出一些这种解决方案的适合场景吗？
  实时上在规范中，还有一个Server-Send-Event的规范， 可以帮助我们实现服务器端->浏览器端的反向消息推送，同学们可以下去学习一下。

回答：

  Socket.IO设计的目标是构建能够在不同浏览器和移动设备上良好运行的实时应用，如实时分析系统、二进制流数据处理应用、在线聊天室、在线客服系 统、评论系统、WebIM等。目前，Socket.IO已经支持主流PC浏览器(如IE、Safari、Chrome、Firefox、Opera等)和 移动平台上的浏览器（iOS平台下的Safari、Android平台下的基于Webkit的浏览器等）。

  参考自《Socket.IO：支持WebSocket协议、用于实时通信和跨平台的框架》

问题三：大型的组件库为什么都用到了预处理？

  事实上处理bootstrap、foundation. 还有一些其它类似规模的组件库， 它们或许在设计和css构建上理念上有部分区别， 它们都非常一致的使用了css预处理器来管理css文件， 你能说出这么做的好处吗？

回答：

• 让 CSS 更见简洁，适应性更强，代码更直观，节省了大量的重复工作和痛苦的代码编辑；

参考自：《为您详细比较三个 CSS 预处理器（框架）：Sass、LESS 和 Stylus》

• 缓解多浏览器兼容造成的冗余；

参考自《为什么要使用CSS预处理器？》

• 提供CSS缺失的样式层复用机制，提高CSS代码的可维护性

开发实践

问题一：采用文档形式的规范输出有哪些弊端？

  采用文档形式的规范输出有哪些弊端？可以从协作、后续对规范的重用等方面进行讨论

回答：

• 假设题目里面说的是开发规范。文档类型的规范的效力依赖于开发人员的对规范的理解，和遵守规范的程度，需要再有一层QA进行保障。还有就是文档规范需要根
  据技术和业务的发展定期更新，更新后还要宣贯。否则可能就过时或者成为纸上的规范。尽量还是能通过工具、统一的框架、模块来规范输出。

• 从协助上来说：没有统一规范的管理，可能导致更新不及时，协助起来大家阅读时存在一些问题等。从后续重用性来说：文档形式的规范输出难以保证完全的统一和规范性，后续的修改和重用还需要先了解前面的具体规范再做进一步修改，学习成本更大，且容易导致问题。

问题二：实际项目中对系统进行分解的难点有哪些？

  实际项目中对系统进行分解的难点有哪些？

回答：仁智见仁，智者见智。没有实际经验回答个毛！！

问题三：如何根据交互提取通用组件

  如何根据交互提取通用组件？交互稿中哪些可以作为通用的组件进行封装？

回答：

  视觉说明中包含各个情况下用户界面的显示样式，其定义了交互稿中的所有效果。之后则需要从中提取出通用组件，其中包括：

• 通用原件（Logo，提示，输入框，图标，按钮等）

• 通用列表（以网易云音乐为例，一般歌单，排行榜，收藏列表，歌手等）

• 复合组件（留言板类，评论控件）

• 浮层弹出

问题四：项目发布时需要做哪些优化？

回答:

• 图片的优化，压缩大小

• CDN的配置

• 代码的压缩和合并

问题五：实际项目中发布工具的哪些功能是你比较关注的？

回答：仁智见仁，智者见智。没有实际经验回答个毛！！