为何找程序员必定要看他的 GitHub

http://www.myexception.cn/other/1857745.html
javascript

http://www.myexception.cn/other/1857745.html
php



为何找程序员必定要看他的 GitHubhtml

据说

最开始听到这句话是某知名互联网公司大牛告诉个人,我很不觉得然,不过迫于他是“leader”我也注册了一个 highsea (广告 0.0);固然我可懒得 push 更别提 contributed 了,尽管在其淫威下仍是 Create 了一个小库……前端

时间过得很快 离职 再就任,见过很多高等级p的大牛,除了 技能上的差距让我拜服,更多的就是大牛们高效的工具让我忧心…… 我毕业才开始学的 web前端开发,他们说 web前端开发工程师 是这样子的:java

前端开发工程师必备技能

通过当时半年的努力 我只完成了右上角小部分…… 后来发现除了每种语言必备的 技能标准+脚手架+社区 外老是有这么一项: GitHubgit

重视

我表示很遗憾,到 2014 年中旬才发现它的重要功能,如下是我的粗浅的见解:程序员

  • 版本管理: 若是你以为他是高级版 Subversion 那你能够关掉这个页面了,继续摸摸你的小龟龟github

  • 项目分支: 他也不单是 SourceForge 或 Google Code ;他把项目分支的操做发挥到了极致(分支能尝试新想法,又不会影响主分支的产品代码。)web

  • 程序员交流: 若是你还没 fork 还没 pull request ,只是 git clone 和 git add 再 push ,那你根本就不算玩过 Github ,没有交流总以为本身“精通”了某个语言面试

  • 重视开源: Preston-Werne 曾说过:“开源(几乎)是一切”

  • 说明文档: 以 markdown 为例,有人说 “文档编写风格决定了咱们能不能愉快的玩耍!” 好的文档能让别人省事,让团队高效…… 固然也会有人认为“这都不是事儿”他的 code 水平最高才是最重要的

传送门 Git 参考手册

这里从“招聘君MM”的角度看下,知乎的回答(有木有英雄所见略同的感受?)

GitHub

GitHub诞生于08年春天,第一年便产生了4万6千个公共项目,大约一年半以后用户就已经达到10万用户之巨。
而到2012年九月份,GitHub已经迎来了百万级用户。Host超过两百万个项目。
增加的太快了!就像Twitter同样。
这样疯了通常的增加只能说明一个事实——人们等待这个产品过久了。

Social Coding。

真实的项目,真实的流程,真实的人名,一切代码review, check-in, test, build, document, 甚至讨论,计划,brianstorming,流程,一切的一切,都是项目历史的一部分,均可以像棋局那样复盘。

有经验的面试者只要稍稍扫两眼一我的的GitHub历史,挑出几个check-in历史看一看,便彻底可以迅速判断这我的是否知足他的要求。再也不须要费劲心机地去想题目,去观察,去揣测,去花费大量的时间的同时还只能采样到几个极为有限的点。

不像象牙塔里面大做业,这里有源代码管理系统,自动化build,有check-in,有review,有分工,有合做,最重要的是——这是一个集市,一个超出象牙塔的集市,牛人相互吸引,你能够在互联网上找到和本身拥有共同兴趣的一帮人,真正作起一点事情,而不是交差,不须要受限于几十我的的一个小班级。Here Comes Everybody。

传送门: 如何在twitter或者github上找靠谱程序员?

记录: GitHub 第一次 Commit 的记录 by Chris Wanstrath :

GitHub 第一次 Commit 的记录 by Chris Wanstrath

对招聘君说:

张三的简历上写着:精通 javascript、 Css三、 php五、 Nginx、 Mysql、 Mongodb、Python、 Nodejs……
参与了 AA产品的开发,BB系统的架构,担任过 CC公司的 如 CTO、产品经理、架构师……
却没有贴出我的技术博客,没有 Github 帐号,没有混迹开源社区,没有对任何框架作贡献……
你却问我: 我以为他很NB要不要约出来聊聊?

200天连续提交的目标

固然 拥有 github 帐号还算不上是一个优秀的程序员,如今招聘大都会附上这一句(意思):

github 能够加分

因而就变成了这样子:

Nothing

我想,确定很多人躺枪,包括1年前的我…… 看 Github 大都是看以下这些:

  • 有什么项目(本身的、fork的、contributed的),类型、数目

  • 有没有编码风格, 固然也有人提倡“编写 不可 维护的代码”的“精英”逻辑

  • commit -m 详细程度

  • 版本工程管理习惯如何

  • 连续提交数目

  • following 、 followers 、 Starred

  • ……

分享一篇 177 Days of GitHub : 推荐每一个人均可以尝试一下,用这个方法去打破一个旧习惯或者创建一个新习惯,但它可能过于强大以致于会让人不能自拔,因此当心点!