易博云天 » 技术周边 http://www.eavea.com/blog 专注技术：学习、交流、分享、免费，每天进步一点点！ Mon, 13 Mar 2023 07:04:16 +0000 zh-CN hourly 1 http://wordpress.org/?v=3.6.1 前后端分离优缺点 http://www.eavea.com/blog/index.php/qianhouduanfenliyouquedian.html http://www.eavea.com/blog/index.php/qianhouduanfenliyouquedian.html#comments Tue, 14 Apr 2020 07:06:36 +0000 eavea http://www.eavea.com/blog/?p=40 前后端分离优缺点

之前有朋友问我：什么是前后端分离。他说北度搜到的都是大篇幅文章，看完还是很懵。
这里我简单总结下，如果有疏漏和不对的地方还请路过的网友指出。

一、先用一张图来解释

what_is_frontend_and backend.jpg

 

二、为什么要前后端分离（优点）

1. 全端适应

PC、APP、PAD等。

2. SPA开发模式开始流行

SPA即Single Page Web Application，俗称单页应用。

3. 前后端开发职责不清

比如JSP、PHP页面，到底是由前端写还是后端写 (所有的模板语言会遇到这样的问题)。

4. 开发效率问题，前后端互相等待

要把html转成template等，效率比较低。

5. 前端一直配合着后端，能力受限

很多交互逻辑要在template里面由后端实现，前端只负责提供静态html，对前端工程师的能力提高不利。

6. 后台开发语言和模板高度耦合，导致开发语言依赖严重

比如后端是Java写的，后期要换成Python，可是模板中嵌入了很多Java语法，等于要重写整个template。

三、前后端分离缺点

1. 前端学习门槛增加、前端工作量加大

前端需要实现一部分的交互逻辑。

2. 数据依赖导致文档重要性增加

接口文档需要很详细，且要及时更新。（一个段子，程序员最痛恨两件事：1.别人的代码没写文档，2.写文档）

3. SEO难度加大

前端渲染的页面不利于搜索引擎爬虫爬取，但有办法解决的，即SSR策略。(以vue为例可以参考这个链接：https://segmentfault.com/a/1190000007933349)

四、综上

1. 一种趋势

前后端分离有一些缺点，但都是可以想办法解决的，总的来说优点大于缺点，而且也是一种趋势。

2. 不过在一些场合其实也没有必要前后端分离

比如写个人网站、内部小运维系统等。这些一般情况下都是一个人完成的，如果前后端分离写，就有frontend和backend两套代码要写，打开两个IDE，颇有左右手互搏的感觉。

当然如果为了练习和学习，写个这样的博客系统也是不错的。

五、补充知识点 – restful api

restful api目前是前后端分离最佳实现

  1. restful api是一种规范，作为开发时的标准
  2. 轻量，直接通过http。不需要额外的协议，post/get/put/delete操作
  3. 面向资源，一目了然，具有自解释性。比如看请求头delete就知道是删除动作。
  4. 数据描述简单，一般通过json或者xml做数据通信
]]> http://www.eavea.com/blog/index.php/qianhouduanfenliyouquedian.html/feed 0 Git迁移仓库并保留commit记录 http://www.eavea.com/blog/index.php/gitqianyicangkubingbaoliucommitjilu.html http://www.eavea.com/blog/index.php/gitqianyicangkubingbaoliucommitjilu.html#comments Tue, 14 Apr 2020 06:57:59 +0000 eavea http://www.eavea.com/blog/?p=36 Git迁移仓库并保留commit记录

在支持 Git 的代码托管平台间进行仓库的迁移，并保留历史 commit 记录。

一、作用

把在 A 托管平台的仓库完全的迁移到 B 托管平台，保留 commit 历史记录。

二、场景

将 Gitlab 上的仓库迁移到 GitHub
将 Coding 上的仓库迁移到 GitHub
将 Gitee 上的仓库迁移到 GitHub
……
迁移前后，保留 commit 历史记录，即在迁移后的新仓库中能查询历史提交信息，同时也能保留小绿点。

三、步骤

  • 建立新仓库
  • 克隆旧仓库
  • 推送新仓库

下面，以 Coding 迁移到 GitHub 为例。

A. Git Bash操作

1. 在 GitHub 建立新仓库

在 GitHub 中新建一个同名项目（不同名也可以），不要添加 README.md，以及任何 License 和 .gitignore 文件，只需要新建一个空的仓库。

只需要一个空的仓库。

2. 克隆 Coding 上的项目

将 Coding 上想要迁移的项目完整克隆到本地。

本地执行

git clone https://git.coding.net/winyuan/blog.git  --bare

3. 将克隆下来的仓库推送到GitHub

克隆完成后，将仓库推送到 GitHub。

使用新仓库页面提供的仓库地址（web URL），推送所有的分支和对象

cd blog.git
git push https://github.com/winyuan/blog.git --all

4. 完成后，再执行推送所有的Tags

git push https://github.com/winyuan/blog.git --tags

这样，整个仓库就全部迁移到 GitHub 了，如果这些commit中的邮箱在GitHub配置中，可以看到小绿点也一起迁移过来了。

B. TortoiseGit 操作

这种简单的操作我不是很喜欢用可视化工具，不过这里也介绍下怎么用「小乌龟」来完成仓库的迁移。

1. 在 GitHub 建立新仓库

同上，不赘述了。

2. 克隆 Coding 上的项目

同上，不赘述了。

3. 将克隆下来的仓库推送到 GitHub

进入项目文件夹，鼠标右键 -> Git Sync…

TortoiseGit同步

点击 Manage。
TortoiseGit同步-管理
填写 GitHub 远程仓库的信息，并 Add New/Save，应用，确认。
TortoiseGit同步-管理-远程信息
Remote URL 选则刚刚添加的 gitHub，然后 Push。
TortoiseGit同步-管理-推送
最后再提交 Tags.
TortoiseGit同步-管理-推送标签

 

四、git命令区别

上面在推送代码至 GitHub（新仓库）时，我们用到了下面这个命令：
git push https://github.com/winyuan/blog.git --all
其实还有另外一个命令：
git push https://github.com/winyuan/blog.git --mirror

关于这两个命令的区别，可以参见Git push –all vs –mirror。

]]> http://www.eavea.com/blog/index.php/gitqianyicangkubingbaoliucommitjilu.html/feed 0 Git提交信息规范 http://www.eavea.com/blog/index.php/gittijiaoxinxiguifan.html http://www.eavea.com/blog/index.php/gittijiaoxinxiguifan.html#comments Tue, 14 Apr 2020 06:54:49 +0000 eavea http://www.eavea.com/blog/?p=34 Git提交信息规范

无论是个人项目还是在团队协作中，commit message 都应该清晰明了，遵守一定规范。
目前，社区有多种 commit message 的写法规范。本文介绍 Angular规范，这是目前使用最广的写法，比较合理和系统化，并且有配套的工具。

一、格式化 commit message 的目的

  • 提供更多的历史信息，方便快速浏览。
  • 可以过滤某些 commit（比如文档改动），便于快速查找信息。
  • 可以直接从 commit 生成 Change log。

二、commit message 的格式

每次提交，commit message 都包括三个部分：Header，Body 和 Footer。

bash
<type>(<scope>): <subject> # header
# 空一行
<body>
# 空一行
<footer>

其中，Header 是必需的，Body 和 Footer 可以省略。
不管是哪一个部分，任何一行都不得超过 72 个字符（或 100 个字符）。这是为了避免自动换行影响美观。

1. Header

Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。

(1) type

type用于说明 commit 的类别，只允许使用下面7个标识：

  • feat：新功能（feature）
  • fix：修补bug
  • docs：文档（documentation）
  • style：格式（不影响代码运行的变动）
  • refactor：重构（即不是新增功能，也不是修改bug的代码变动）
  • test：增加测试
  • chore：构建过程或辅助工具的变动

如果 type 为 feat 和 fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。

(2) scope

用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

(3) subject

subject 是 commit 目的的简短描述，不超过 50 个字符。

  • 以动词开头，使用第一人称现在时，比如 change，而不是 changed 或 changes。
  • 第一个字母小写。
  • 结尾不加句号（.）。

2. Body

用于对本次 commit 的详细描述，可以分成多行。下面是一个范例：

bash
More detailed explanatory text, if necessary.  Wrap it to 
about 72 characters or so. 

Further paragraphs come after blank lines.

- Bullet points are okay, too
- Use a hanging indent

有两个注意点。
(1) 使用第一人称现在时，比如使用 change 而不是 changed 或 changes。
(2) 应该说明代码变动的动机，以及与以前行为的对比。

3. Footer

Footer 部分只用于两种情况。

(1) 不兼容变动

如果当前代码与上一个版本不兼容，则 Footer 部分以 BREAKING CHANGE 开头，后面是对变动的描述、以及变动理由和迁移方法。

bash
BREAKING CHANGE: isolate scope bindings definition has changed.

To migrate the code follow the example below:

Before:

scope: {
  myAttr: 'attribute',
}

After:

scope: {
  myAttr: '@',
}

The removed `inject` wasn't generaly useful for directives so there should be no code using it.

(2) 关闭 Issue

如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue 。

bash
Closes #234

也可以一次关闭多个 issue 。

bash
Closes #123, #245, #992

4. Revert（可忽视）

还有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以 revert: 开头，后面跟着被撤销 Commit 的 Header。

bash
revert: feat(pencil): add 'graphiteWidth' option

This reverts commit 667ecc1654a317a13331b17617d973392f415f02.

Body 部分的格式是固定的，必须写成 This reverts commit <hash>.，其中的 hash 是被撤销 commit 的 SHA 标识符。

如果当前 commit 与被撤销的 commit，在同一个发布（release）里面，那么它们都不会出现在 Change log 里面。如果两者在不同的发布，那么当前 commit，会出现在 Change log 的Reverts小标题下面。

三、提交频率

关于什么时候提交一次：
每次你写完一个功能的时候，就应该做一次提交（这个提交是提交到本地的 git 库中）。
当
然，这里的写完表示的是你的这个功能是没有问题的。

四、Angular规范

Angular规范见上图：

Angular规范

 

附：团队协作风格指南

在团队协作中，不管有多少人共同参与同一项目，我们期望每一行代码都像是同一个人编写的。因此需要永远遵循同一套编码规范。
我基于国内大厂规范，整理了一套《团队协作风格指南》，仅供参考。
整理自《Commit message 和 Change log 编写指南》-阮一峰
参考［译］AngularJS Git提交信息规范

]]> http://www.eavea.com/blog/index.php/gittijiaoxinxiguifan.html/feed 0 群里提问的艺术 http://www.eavea.com/blog/index.php/qunlitiwendeyishu.html http://www.eavea.com/blog/index.php/qunlitiwendeyishu.html#comments Tue, 14 Apr 2020 06:42:01 +0000 eavea http://www.eavea.com/blog/?p=32 群里提问的艺术

在技术交流群里，只有正确地提问，才能最有效地得到期望的答案。
提问，是一门艺术。

经常会看到有人在，xxx 交流群 / xxx 技术交流群 / xxx 学习交流群 里问问题，然而总是得不到想要的答案，最后无奈地吐槽完一句后默默离开。

其实这种问题地频繁出现，最终会让好端端的技术群成为车友群。之所以有这样的现象，跟提问者不会提问有很大的关系。

下面就 如何正确地提问 分成以下三部分进行介绍：

  • 提问之前
  • 提问之时，怎么提问注意事项
  • 提问之后

一、提问之前

遇到问题首先你得尝试自己解决自己的问题。

我相信很多群里都有这样的幽默公告：本群已和谷歌，百度，360，搜狗，必应等搜索引擎公司达成战略合作，有什么疑问可以先咨询他们，不用在群里问了。

尝试自己解决是非常重要的一步，这也是我们能否经过这个问题能够成长的关键所在。自己动手丰衣足食，这是亘古不变的道理，遇到难题也是如此，自己不首先动动脑子，只知道一个劲的问「为什么」「怎么做」，到头来，即使你解决了问题，你也没有学到解决的思路和方法。

那么如何自己尝试着解决呢？按下面的步骤走一遍：

  1. 通过搜索引擎搜索：Baidu 或者 Google（推荐），搜索结果中前三页如果找不到你想要的信息，就进行下一步吧。对于成熟的开源项目，你遇到的问题，很可能别人也遇到过。这时通过 Google、StackOverflow 等网站的搜索服务，可以帮你快速定位并解决问题。永远记住，地球上的你并不孤单，包括你遇到的问题。
  2. 查阅手册/文档：确保自己阅读过至少一次官方文档。这样在遇到问题时，如果能回忆起只言片语，就可以再去读一遍相关文档，问题往往也就解决了。
  3. 查阅社区/论坛：阅读常见问题文件（FAQ）或者开源项目的 issue，或者论坛（类似 react china）。
  4. 询问朋友：如果你使用的开源软件，在朋友圈或同事圈里也有人使用，那么抬起你的脚、或拿起你的电话，真挚诚恳的探讨不会遭遇拒绝，而会增进友谊。相信我，同样是请教别人，有时候寻求身边看得见摸得着的人，会远比寻求网络上的水友更有效。当然，如果你是妹子，恰好群里的单身狗们闲着没事干就另当别论了。
  5. 自检并不断测试：反复尝试自己检查以找到答案。
  6. 阅读源码（这步非必须）：如果你是程序开发者，尽量尝试阅读源码以找到答案，有的第三方库文档漏写的东西，在源码的注释中会体现，实在不行还能直接看相应的函数（方法）。

经过以上 6 步或者 5 步你都无法解决遇到的问题，那么你确实针对这个问题能力有限，准备去群里请教了，那么在尝试自己解决之后无果，应该做哪些准备呢？

你一定要准备好下面这些才能去群里提问。

  1. 一定要明白自己想要问什么问题：不能自己都说不清自己想要问什么问题，那么群里提问你也问不出什么来。
  2. 请梳理好您的问题：要说明之前你都干了些什么。
  3. 要用言简意赅的语言：这个是我们作为职场一个必备的技能，说重点，言简意赅。

二、怎么提问

抱着平和对等的心态，找到合适的途径后，就得静下心来将遇到的问题写成文字。书写文字不是一件简单的事情，我们可以从遵循一些简单的规则开始。

用词准确，问题明确。

标题要简洁清晰，要言之有物。

反例：有人会用Vue吗？
正例：在使用 xxx 版本的 Vue ，我操作了 xxx，也写了 xxx，但是 xxx 组件渲染不出来。

一个好标题范例是目标 —— 差异式的描述，许多技术支持组织就是这样做的。在目标部分指出是哪一个或哪一组东西有问题，在差异部分则描述与期望的行为不一致的地方。

描述清晰，信息充足。

  1. 准确有效的信息：描述事实，而不是猜测，如果你想给出你的猜测，一定要先描述事实，给你的猜测一些证据，不然就不要猜测。
  2. 问题表现/内容：按照时间顺序列出问题症状。问题发生前的一系列操作，往往就是对找出问题最有帮助的线索。因此，你的说明里应该包含你的操作步骤，以及机器和软件的反应，直到问题发生。在命令行处理的情况下，提供一段操作记录（例如运行脚本工具所生成的），并引用相关的若干行（如 20 行）记录会非常有帮助。
  3. 简单的做过什么尝试：在描述你做过什么尝试的时候，简单的你描述你做了哪些尝试就行，为什么要这么做其实不是那么重要。

如果你想弄清楚如何做某事（而不是报告一个Bug），在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。

经常寻求技术帮助的人在心中有个更高层次的目标，而他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。

玉伯有句话是这么说的：

提问者选择的路本身就是一条崎岖之路，对于要解决的问题，实际上有更好的方式。这种情况下，描述清楚目标，讲清楚要干什么非常重要。

  1. 想要问到什么：提供建议？发送一段代码？检查你的补丁或者别的？在群里经常会出现这种情况，当某个人发了一段文字，另外的人说：你想问什么？

所以我们在问问题的时候一定要把你想要问到什么，这个目标想清楚。

  1. 提供尽量多的信息：尽量提供可重现的例子，你可以在 jsbin、runjs、jsfiddle、codepen 等这些地方提供一个可重现的例子。即使你是一个很大的项目，想办法把你需要验证的点提取出来，如果确实无法提取，就贴一些代码，出现问题那行代码周围的代码（周围的相关代码都要，因为你可能觉得不是他们的问题，但也许就是，不然你觉得的都是对的，你就不会不知道怎么解决了）。

避免一些毫无意义的问题。

经常会有人问一些毫无意义的问题，比如这样的：

反例：有没有人会xxx？
反例：有没有人在？
反例：谁能帮我解决一个问题？

面对这种问题，别人就很难预估你这个问题需要解决多久，也很难判断自己是否能解决这个问题，如果他回答了你，意味着他就是有空而且很在行，所以他还是选择不出声。这个就跟微信私聊的时候说：「在吗？」 这种一个意思。

反例：ES6是什么？

这种问题也是，很明显通过搜索引擎就能搞定的，要是下次还有这种问题，你就把这个图发给它。

鸟哥语录

 

建议的问法。

  1. 有问题直接问。比如：vue2.0什么时候出，bootstrap表格插件有什么推荐的？
  2. 直接说场景：我在做xx端东西的时候，在 window 7 平台的 IE7 版本下遇到了左右不对齐问题，具体如图所示img，代码地址：http://www.jsbin.com/xxxx，在百度中找到的答案，试了之后还是有同样的问题。请有空的同学帮我看看是什么问题？

三、提问之后

  1. 如果有人花时间帮你理清了思路、解决了问题，记得表示下感谢。不强迫说一定要发个红包道谢，但如果一个群里能养成解决问题后发红包的风气，那也是很正能量的。
  2. 无论问题有没有在群里得到解决，都要对参与讨论的人说声「谢谢你的建议，我再看看。」
  3. 经常主动帮别人解决问题，你在群里自然就混了个眼熟，那么当你遇到问题的时候，别人也会乐意读完你的提问。能不能替你解决是另一码事。

四、心态放平

  • 提前做好冷场的准备：也许别人在忙，也许这个问题太简单了，也许没人做过这块，如果冷场了，没人回答，赶紧换下一个群。
  • 谦虚，别人没有义务帮你解决问题，往往大牛的时间比你少，比你珍贵。
  • 没有一定的自学能力，遇到问题就伸手的不适合玩这个。
  • 群唯一的作用就是：扯淡、交流、分享，以上几条为前提。

其实根据我的经验，选型问题 和 求资源/求推荐 这类问题在群里得到的反响比较多。真正遇到难点的技术问题，尤其还是跟业务紧密耦合的，还是要养成自己摸索解决的习惯。

五、懒人必看

最后，如果嫌上文太长懒得看，收藏一下这个图吧：

群里提问的艺术

 

]]> http://www.eavea.com/blog/index.php/qunlitiwendeyishu.html/feed 0