提升效率

Basis

我是个很在意效率的人，虽然可能执行力不那么强。但是能省的绝对不会浪费精力去做。

这里的效率也包含了如何获取信息，如何与人交流，总之是对个人有益的总结。

1. 学会阅读

2. 学会提问

这是我遇到的第一个提升效率的方式。

刚接触网络和论坛的时候，我常常会去问一些浪费别人时间去回答的问题，比如："如何XXX"，其实这类问题如果再花几分钟，或者再思考下都是很容易得出答案的问题。但是互联网给人的就是浮躁，很多情况下我们只学会了伸手去索取。

一个好的答案需要一个好的问题。学会提问，你会得到更多的信息。网络上有那个一篇文章:学会如何提问。我是没有读过，但是我理解它的意思。当你被别人问了几次基础或者无脑的问题，你就知道你希望得到的提问是什么样的。那么你其实也学会了如何提问。

3. 善用搜索

学会了如何提问，其实已经能把握住问题的中心，也就可以先使用搜索去尝试解决问题。

4. 程序员效率指南

程序员效率指南

4.1. 挑一款趁手的editor和ide

作为一个开发者，你需要精挑细选一款趁手的用来编辑代码的editor。我使用了几年的vim，又换用过大半年的emacs，为了强制自己习惯emacs，我甚至在bash中把vim alias成emacs。但最终，没能打开emacs下的任督二脉的我实在无法抗拒vim下的那些好用的插件，又回到了vim的阵营。所以在editor这里，我只能先讲讲更为熟悉的vim。

vim下最基本的vundle不提，至少这些插件你值得拥有：

SirVer/ultisnips: 撰写和使用snippet神器，用过textmate/sublime的人应该都知道。一个程序员的效率很大程度上跟他的snippet库有关。如果你的python class，html的标签，erlang/elixir的otp代码还是一个字符一个字符手敲，那么你该好好看看这个插件了。配合着 honza/vim-snippets，大部分代码的snippet都有了；遇到结构类似的代码块（bolerplate），又没有已经定义好的snippet时，调用 :UltiSnipsEdit 立刻定义之，你基本上就走在无敌的路上了。
scrooloose/nerdtree：让你的vim支持文件树。这个插件加上 tpope/vim-eunuch，文件系统的各种操作和显示全在vim里搞定了。
sheerun/vim-polyglot：几乎所有程序语言的源文件syntax/tab等的支持。有此一个插件，就不再需要 vim-ruby，vim-go等一票单独的语言插件了。
Valloric/YouCompleteMe：让vim支持自动补齐。这个几乎是IDE的标配，效率提升的另一大神器。有了它，IDE的需求就减弱很多。

其它的插件就不一一介绍了，感兴趣的可以在我的dotfiles里面一一翻阅。

大部分编程的工作，轻量级的editor就足够胜任，但有些开发语言和框架，bolerplate代码实在太多，整个开发目录太繁杂，这时候不得不使用IDE，比如说java下的很多项目。当你不得不使用IDE的时候，intelliJ系列的IDE是比eclipse系列好很多的选择。

当然，这条rule的核心是尽量使用editor，能不用IDE就不用IDE。

4.2. 把常用的任务命令化/快捷键化

国外的开发高手也都是使用快捷键的高手，我以前不习惯使用快捷键，但看了很多高手的screencast后，发现他们都是当一个任务重复几次后，顺手就定义快捷键或者命令。这里我讲讲vim怎么做，emacs的用户自行脑补。

在进行elixir做TDD开发的时候，我经常需要运行 mix test 来确保我新写的代码或者重构的代码能够跑过已有的test case。这事做多了也就烦了，因为在vim里总需要输入 !mix test，这个时候，我就会为此定义个快捷键。如果快捷键只跟当前项目有关，那么就在当前项目根目录下生成一个 .vimrc，定义快捷键，否则在系统的 .vimrc 中定义：

noremap <leader>et :!mix test<CR>

这样，以后需要运行这个命令的时候，直接敲 key + ed 就好。对于elixir，我有这些定义：

noremap <leader>ed :!mix deps.get<CR>
noremap <leader>et :!mix test<CR>
noremap <leader>ec :!mix compile<CR>

因为每个语言都有类似的 dependency，test，compile等任务，如果要定义在全局的 .vimrc 文件里，可以为每种语言附不同的前缀（elixir为 e）区隔。如果你喜欢按项目定义，那可以把 t 统一定义为UT的命令，这样可以省去敲一个字符的时间。

4.3. 培养自己好的重构习惯

这里讲的重构和代码里的重构大体意思一样，就是不断优化自己的工作环境。Rule 6其实就是一种重构。

经常问问自己这些问题：

常用的命令是不是做了alias？比如：总敲 ls -l，是不是应该alias出一个 ll 来？
常用的服务器信息是否写在了 .ssh/config 里？服务器登录是否使用了pub/private key（毋须输入密码）？
对于某些操作，可不可以定义一些快捷键（比如说google search）？
项目里重复的工作是不是写成了makefile（或是其他任务脚本，如rake，jake）？
常写的代码结构是否定义了snippet？

讲讲snippet。我特别喜欢vim的ultisnips，它能让我按语言很方便地定义snippet。比如在elixir里总要写的 GenServer 代码，大体结构是 Public API + GenServer API，我可以定义一个snippet，在敲入 defgen 的时候，可以展开成为下面的代码（并且我可以在代码中跳至需要我修改的地方）：

defmodule name do
  @moduledoc """

  """
  use GenServer

  ### Public API

  def start_link do
    {:ok, server} = :gen_server.start_link __MODULE__, [], []
  end

  ### GenServer API
  def init(state) do
    {:ok, state}
  end

  def handle_call(, _from, state) do

  end

  def handle_cast(, state) do

  end
end

这将省去我多少bolerplate的时间 —— 更关键的时，我的思绪不会被撰写这些无趣，但又不得不写的bolerplate打断。

4.4. 使用git管理个人文件

大部分开发者对于自己的代码项目都有很好的习惯：使用git（或者其他scm）管理。但代码之外的文档，管理起来就有些随意，即没有历史记录，单纯存储在本地也容易丢失。建议大家对 $HOME 下的文件，只要是自己生成的文档（太大的二进制除外），一律用git管理（在目录下 git init）。你们看到的这个公众号的所有文章就是用github存储（private repo）。然而github上存储private repo毕竟要花钱 —— 不想花钱，又想很多私人的文档想管理怎么办？可以在dropbox（或者其他类似的网盘）上生成一个git的bare project，然后把本地的文档push上去。

4.5. 多看高手的screencast

很多时候我们没有机会近距离看高手是怎么工作的，但观看他们的screencast不失是一种提高自己的好办法。在这个方面，其他语言的爱好者估计都要妒忌ruby的拥趸 —— ruby社区的各种screencast多得令人发指！通过订阅这些screencast，你不仅能快速学到语言相关的知识和实用的技巧，更重要的是，你知道高手都在用什么工具，如何写代码。11年的时候我看过一个php的screencast，一个法国人介绍如何用symfony撰写项目。那是我第一次领略什么是指尖如飞，也给我播下了snippet的种子（他用的是textmate）。从那以后，我会时不时地看一些各种各样的screencast（以rails的居多），学习点新东西的同时，还能学习高手的习惯。

团队合作

除了独立开发者，大部分技术人员还是要进行团队合作的。

可惜程序员大多数都喜欢单打独斗，不管难易如何，全部都要自己拿下。

一个好的程序员，不单单关注的是程序本身，还应该关注到整个团队，帮助大家协同合作，减轻自己的压力，也提高了团队的效率。

搞技术的，不缺千里马，却的是伯乐。

我们要强大自己的团队，就需要招聘到对的人：技术和思想都一致的人。

1. 面试

一般程序员的面试分为：代码笔试+问答面试。

代码笔试主要就是考察能力，问答主要是对项目以及个人的情况了解。

1.1. STAR面试法

这里提到了一种面试原则，叫做STAR面试法.STAR”是SITUATION（背景）、TASK（任务）、ACTION（行动）和RESULT（结果）四个英文单词的首字母组合。

在招聘面试中，仅仅通过应聘者的简历无法全面了解应聘者的知识、经验、技能的掌握程度及其工作风格、性格特点等方面的情况。而使用STAR技巧则可以对应聘者做出全面而客观的评价。

背景（SITUATION）: 通过不断提问与工作业绩有关的背景问题，可以全面了解该应聘者取得优秀业绩的前提，从而获知所取得的业绩有多少是与应聘者个人有关，多少是和市场的状况、行业的特点有关。
工作任务（TASK）: 每项任务的具体内容是什么样的。通过这些可以了解应聘者的工作经历和经验，以确定他所从事的工作与获得的经验是否适合所空缺的职位。
行动（ACTION）: 即了解他是如何完成工作的，都采取了哪些行动，所采取的行动是如何帮助他完成工作的。通过这些，可以进一步了解他的工作方式、思维方式和行为方式。
结果（RESULT）: 每项任务在采取了行动之后的结果是什么，是好还是不好，好是因为什么，不好又是因为什么。

1.2. 面试人员应该具备的技能

一个优秀的程序员应该具有怎样的技能:

基础扎实
主动思考
爱学习
有深度
有视野
扎实的编码经验

1.3. 校园招聘与社会招聘

校招和社招的是不一样的，校招会更加关注基础知识，而社招会更加关注之前做过的项目情况。

1.4. 需要注意的地方

面试题目：根据你的等级和职位变化，入门级到专家级：广度↑、深度↑。
题目类型：技术视野、项目细节、理论知识，算法，开放性题，工作案例。细节追问：可以确保问到你开始不懂或面试官开始不懂为止，这样可以大大延展题目的区分度和深度，知道你的实际能力。因为这种关联知识是长时- 期的学习，绝对不是临时记得住的。
回答问题再棒，面试官（可能是你面试职位的直接领导），会考虑我要不要这个人做我的同事？所以态度很重要。（感觉更像是相亲）
资深的工程师能把absolute和relative弄混，这样的人不要也罢，因为团队需要的是：你这个人具有可以依靠的才能（靠谱）。

2. 招聘

2.1. STAR原则

所谓STAR原则，即Situation（情景）、Task（任务）、Action（行动）和Result（结果）四个英文单词的首字母组合。STAR原则是结构化面试当中非常重要的一个理论。

S指的是situation,中文含义是情景，也就是在面谈中我们要求应聘者描述他在所从事岗位期间曾经做过的某件重要的且可以当作我们考评标准的事件的所发生的背景状况。

T指的是task，中文含义为任务，即是要考察应聘者在其背景环境中所执行的任务与角色，从而考察该应聘者是否做过其描述的职位及其是否具备该岗位的相应能力。

A指的是action,中文含义是行动，是考察应聘者在其所描述的任务当中所担任的角色是如何操作与执行任务的。

R指的是result,中文含义为结果，即该项任务在行动后所达到的效果，通常应聘者求职材料上写的都是一些结果，描述自己做过什么，成绩怎样，比较简单和宽泛。

而我们在面试的时候，则需要了解应聘者如何做出这样的业绩，做出这样的业绩都使用了一些什么样的方法，采取了什么样的手段，通过这些过程，我们可以全面了解该应聘者的知识、经验、技能的掌握程度以及他的工作风格、性格特点等与工作有关的方面。而STAR原则正是帮我们解决上述问题的。

3. 领导

招聘，培训，下面就是领导力了。正巧，我最近也做一段时间的leader，负责培训。

3.1. 责任

作为一个leader，自己也是有上级的。所以应该做到几点：

合理的分解，分配工作。
保持和上面的良好沟通。
团结成员，不要偏心。
能帮团队成员说话，顶得出去。
在业务上能帮助成员成长。
有胆放手让别人去做。

对于一个小公司来说，虽然一开始可能必须得靠管理者亲力亲为，但是当业务逐渐成型、走上正规之后，一定要把团队成员的能力都锻炼出来。否则公司的发展可能会受到限制，因为管理者的精力有限，被日常琐事缠绕就无法集中精力思考发展方向，或者是谋求外部的合作机会。所以要学会彻底的放权，让团队的成员都忙起来。在可以承受的范围内让大家去犯错，去成长，去做一线的决策，最终成为能独当一面的人。

工作