mirror of
https://github.com/phodal/github
synced 2026-05-22 00:29:47 +00:00
[T] try compile
This commit is contained in:
Phodal HUANG
parent
1e1c65108f
commit
1963f54c5c
3 changed files with 38 additions and 19 deletions
|
|
@ -3,6 +3,25 @@
|
|||
<p>项目首页: <a href="https://github.com/phodal/github-roam">GitHub 漫游指南</a></p>
|
||||
<p>By <a href="https://www.phodal.com">Phodal Huang</a>(微博、知乎、GitHub、SegmentFault: @<a href="http://weibo.com/phodal">phodal</a>)
|
||||
</p>
|
||||
|
||||
<p>我的其他电子书：</p>
|
||||
<ul>
|
||||
<li>《<a href="https://github.com/phodal/ideabook">Phodal's Idea实战指南</a>》</li>
|
||||
<li>《<a href="https://github.com/phodal/designiot">一步步搭建物联网系统</a>》</li>
|
||||
<li>《<a href="https://serverless.ink/">Serverless 应用开发指南</a>》</li>
|
||||
<li>《<a href="https://github.com/phodal/repractise">RePractise</a>》</li>
|
||||
<li>《<a href="https://github.com/phodal/growth-ebook">Growth: 全栈增长工程师指南</a>》</li>
|
||||
<li>《<a href="https://github.com/phodal/growth-in-action">Growth: 全栈增长工程师实战</a>》</li>
|
||||
<li>《<a href="https://github.com/phodal/fe">我的职业是前端工程师</a>》</li>
|
||||
<li>《<a href="https://github.com/phodal/make">写给软件工程师看的硬件编程指南</a>》</li>
|
||||
</ul>
|
||||
|
||||
<p>微信公众号</p>
|
||||
<img src="./img/qrcode.jpg" alt=""/>
|
||||
<p><img src="https://articles.phodal.com/qrcode.jpg" alt=""/></p>
|
||||
<p>
|
||||
当前为预览版，在使用的过程中遇到任何遇到请及时与我联系。阅读过程中问题，不烦在GitHub上提出来：
|
||||
<a href="https://github.com/phodal/hardware-guide/issues">Issues</a>
|
||||
</p>
|
||||
<p>
|
||||
阅读过程中遇到语法错误、拼写错误、技术错误等等，不烦来个Pull Request，这样可以帮助到其他阅读这本电子书的童鞋。
|
||||
</p>
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
<div style="width:800px">
|
||||
|
||||
<iframe src="http://ghbtns.com/github-btn.html?user=phodal&repo=github-roam&type=watch&count=true"
|
||||
<iframe src="https://ghbtns.com/github-btn.html?user=phodal&repo=github-roam&type=watch&count=true"
|
||||
allowtransparency="true" frameborder="0" scrolling="0" width="110px" height="20px"></iframe>
|
||||
<div>
|
||||
|
|
@ -400,7 +400,7 @@ C | 2
|
|||
|
||||
### 我的第一个PR
|
||||
|
||||
我的第一个PR是给一个小的Node的CoAP相关的库的Pull Request。原因比较简单，是因为它的README.md写错了，导致我无法办法进行下一步。
|
||||
我的第一个PR是给一个小的Node的CoAP相关的库的Pull Request。原因比较简单，是因为它的README.md写错了，导致我无法进行下一步。
|
||||
|
||||
const dgram = require('dgram')
|
||||
- , coapPacket = require('coap-packet')
|
||||
|
|
@ -1035,7 +1035,7 @@ Git 提交信息及几种不同的规范
|
|||
|
||||
与我们日常工作稍有不同的是：工作中的 Release 计划一般都是事先安排好的，不需要一些 CHANGELOG 什么的。而开源应用、开源库需要有对应的 CHANELOG，则添加了什么功能、修改了什么等等。毕竟有很多东西是由社区来维护的。
|
||||
|
||||
因此，这里以做得比较好的开源项目 Angular 中为例展示。Angular 团队建议采用以下的形式：
|
||||
因此，这里以做得比较好的开源项目 Angular 为例展示。Angular 团队建议采用以下的形式：
|
||||
|
||||
```
|
||||
<type>(<scope>): <subject>
|
||||
|
|
@ -1147,21 +1147,19 @@ React.render(
|
|||
|
||||
有一天，我发现当我需要我一次又一次地重复讲述某些内容，于是我就计划着把这些应该掌握的技能放到GitHub上，也就有了[Artisan Stack](https://github.com/phodal-archive/artisanstack.github.io) 计划。
|
||||
|
||||
每个程序员都不可避免地是一个Coder，一个没有掌握好技能的Coder，算不上是手工艺人，但是是手工人。
|
||||
|
||||
艺，需要有创造性的方法。
|
||||
每个程序员都不可避免地是一个Coder，一个没有掌握好技能的Coder，算不上是手工艺人，但是手工艺人，需要有创造性的方法。
|
||||
|
||||
## 为什么重构?
|
||||
|
||||
> 为了更好的代码。
|
||||
|
||||
在经历了一年多的工作之后，我平时的主要工作就是修Bug。刚开始的时候觉得无聊，后来才发现修Bug需要更好的技术。有时候你可能要面对着一坨一坨的代码，有时候你可能要花几天的时间去阅读代码。而，你重写那几十代码可能只会花上你不到一天的时间。但是如果你没办法理解当时为什么这么做，你的修改只会带来更多的bug。修Bug，更多的是维护代码。还是前人总结的那句话对:
|
||||
在经历了一年多的工作之后，我平时的主要工作就是修Bug。刚开始的时候觉得无聊，后来才发现修Bug需要更好的技术。有时候你可能要面对着一坨一坨的代码，有时候你可能要花几天的时间去阅读代码。而你重写那几十行代码可能只会花上你不到一天的时间。但是如果你没办法理解当时为什么这么做，你的修改只会带来更多的Bug。修Bug，更多的是维护代码。还是前人总结的那句话对:
|
||||
|
||||
> 写代码容易，读代码难。
|
||||
|
||||
假设我们写这些代码只要半天，而别人读起来要一天。为什么不试着用一天的时候去写这些代码，让别人花半天或者更少的时间来理解。
|
||||
|
||||
如果你的代码已经上线，虽然是一坨坨的。但是不要轻易尝试，``没有测试的重构``。
|
||||
如果你的代码已经上线，虽然是一坨坨的。但是不要轻易尝试``没有测试的重构``。
|
||||
|
||||
从前端开始的原因在于，写得一坨坨且最不容易测试的代码都在前端。
|
||||
|
||||
|
|
@ -1193,7 +1191,7 @@ while ((stra = micromarkdown.regexobject.mail.exec(str)) !== null) {
|
|||
}
|
||||
```
|
||||
|
||||
选这个做重构的开始，不仅仅是因为之前在写[EchoesWorks](https://github.com/phodal/echoesworks)的时候进行了很多的重构。而且它更适合于，``重构到设计模式``的理论。让我们在重构完之后，给作者进行pull request吧。
|
||||
选这个做重构的开始，不仅仅是因为之前在写[EchoesWorks](https://github.com/phodal/echoesworks)的时候进行了很多的重构。而且它更适合于``重构到设计模式``的理论。让我们在重构完之后，给作者进行pull request吧。
|
||||
|
||||
Markdown的解析过程，有点类似于``Pipe and Filters``模式(架构模式)。
|
||||
|
||||
|
|
@ -1895,7 +1893,7 @@ numbers, objects, strings, etc. Lodash’s modular methods are great for:
|
|||
|
||||
|
||||
|
||||
当然了，这种事不能太过，要不是会招来一堆黑。
|
||||
当然了，这种事不能太过，要不然会招来一堆黑。
|
||||
|
||||
### 安装及hello, world 示例
|
||||
|
||||
|
|
@ -2952,19 +2950,21 @@ Lettuce.send = function (url, method, callback, data) {
|
|||
|
||||
|
||||
表格源自一本书叫《Linux内核0.11(0.95)完全注释》，简单地再介绍一下：
|
||||
|
||||
- 版本0.00是一个hello,world程序
|
||||
- 版本0.01包含了可以工作的代码
|
||||
- 版本0.11是基本可以正常的版本
|
||||
|
||||
这里就要扯到《GNU 风格的版本号管理策略》：
|
||||
|
||||
1．项目初版本时，版本号可以为 0.1 或 0.1.0, 也可以为 1.0 或 1.0.0，如果你为人很低调，我想你会选择那个主版本号为 0 的方式；
|
||||
2．当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；
|
||||
1. 项目初版本时，版本号可以为 0.1 或 0.1.0, 也可以为 1.0 或 1.0.0，如果你为人很低调，我想你会选择那个主版本号为 0 的方式；
|
||||
2. 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；
|
||||
3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0，因而可以被忽略掉；
|
||||
4．当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1；
|
||||
5．另外，编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，并不进行人为控制。
|
||||
4. 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1；
|
||||
5. 另外，编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，并不进行人为控制。
|
||||
|
||||
因此，我们可以得到几个简单的结论：
|
||||
|
||||
- 我们需要阅读最早的有核心代码的版本
|
||||
- 我们需要阅读1.0版本的Release
|
||||
- 往后每一次大的Release我们都需要了解一下
|
||||
|
|
@ -3521,7 +3521,7 @@ GitHub 里程碑
|
|||
|
||||
一年前，稍微改变了下策略：暂时以**培养人为主**，同时想着做一个合适的开源框架——只是在今年看来，前端领域已经没有合适的地方可以造轮子了。
|
||||
|
||||
在 GitHub 上有一个很常见的问题是，**大多部分项目的维护者就是发起人**——如果这个发起人发生意外了，那么这个项目怎么办。如果这是一个很火的项目，它就存在着巨大的风险；同时这可能也说明了，缺乏一套合理的机制。
|
||||
在 GitHub 上有一个很常见的问题是，**大多数项目的维护者就是发起人**——如果这个发起人发生意外了，那么这个项目怎么办。如果这是一个很火的项目，它就存在着巨大的风险；同时这可能也说明了，缺乏一套合理的机制。
|
||||
|
||||
你的开源项目不仅仅需要一个使用文档，还需要一个相关设计思想的文档、路线图、未来计划等等。
|
||||
|
||||
|
|
@ -3551,9 +3551,9 @@ GitHub 里程碑
|
|||
|
||||
**家居智能中心**。我仍然对于大学学的知识有点念念不忘，虽然已经写了一本书，但是硬件还是相当的刺激。唯一的问题是：连房子都没有，怎么做智能家居。
|
||||
|
||||
**图形框架**。这是我之前在做一个图形界面的时候，发生没有一个合适的框架可以满足我的要求。然后我就在想，还是自己做一个吧。
|
||||
**图形框架**。这是我之前在做一个图形界面的时候，发现没有一个合适的框架可以满足我的要求。然后我就在想，还是自己做一个吧。
|
||||
|
||||
不过，最好的开源项目就是自己平时用的。于是，我开始将写各种工作来提自己使用——如现在在用的这篇微信编辑工具：[mdpub](https://github.com/phodal/mdpub)。
|
||||
不过，最好的开源项目就是自己平时用的。于是，我开始将写各种工具来给自己使用——如现在在用的这篇微信编辑工具：[mdpub](https://github.com/phodal/mdpub)。
|
||||
|
||||
最后，我做了一个简单的 HTML 5 动画来记录这一时刻，作为这一个里程碑的记念：
|
||||
|
||||
|
|
@ -3573,7 +3573,7 @@ FAQ
|
|||
|
||||
在这种时候，也没有法律来保护这些开源软件作者。你只能从道德上谴责他们，然后指望他们的领导来做出一些什么事。如之前的《[知名公司（努比亚/中兴）拿我的开源软件（ XXL-JOB）申请国家知识专利，我该怎么办？](https://link.zhihu.com/?target=https%3A//www.v2ex.com/t/367424%3Fp%3D1)》事件。
|
||||
|
||||
并且对于大部分的开源软件作者来说，都不大可像 OpenResty、Vue、emqtt 等软件的作者一样，可以从开源软件获得收益来支撑他们开发。还有一些少数人，还能从开源软件中获得一些利益，提高他们今年的 KPI。然后明年的工资，又会多涨一点点。
|
||||
并且对于大部分的开源软件作者来说，都不大可能像 OpenResty、Vue、emqtt 等软件的作者一样，可以从开源软件获得收益来支撑他们开发。还有一些少数人，还能从开源软件中获得一些利益，提高他们今年的 KPI。然后明年的工资，又会多涨一点点。
|
||||
|
||||
可多数人，并没有这样的可能性。我在 GitHub 上有接近 30k 的 star（笑，有接近 20k 是属于电子书的，毕竟思想改变世界），它一点儿也不影响我涨工资。反而多了一个 GitHub “网红” 的称号，要知道在技术领域，“网红” 并不是一个好词。我观察过的大量开源爱好者，怕是比我还惨一些。明明做了很好的工作，因为宣传工作没有做好，连几个 star 都没有，后来就弃坑了。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue