一些问题总结（垃圾，请勿入）

当你有机会面对面向牛人请教一项技术时，你应该如何去提问。

实在是总结不出来步骤，就以自己的一些经历来谈一谈自己的看法吧。

一、网络中的tcp ip模型：
了解以下几个问题：

• 网络是如何工作的
• tcp/ip的每一层分别是干什么的，它们解决的都是些什么问题，以发送一个文本文件为例，这个文件是怎么通过协议栈一层一层地进行传递，然后发送到网络上的。网络中的中间节点又是如何找到目的机器，然后经过目的机器的协议栈，一步步解析成为那个文本文件的。这里至少要明确一下两类问题：
  • 文本文本在经过协议栈处理，变成了什么样子。变成这个样子的原因是什么。
  • 当包发送到网络上后，它是如何找到目的机器的。

每一层要实现的功能，会面临什么样的问题，每层又是怎么解决的。这就会解释，为什么每层包的结构会设计成这个样子。

你可以自己先想想，每层会遇到什么问题，并且自己有没有一个解决方案。然后，和现实的解决方案进行对比。看看自己的考虑遗漏了些什么。各种备选方案，可能又会产生出来一些新的问题，为了解决这些问题，又提出了哪些想法。

总的来说，就是你要解决个什么问题，直观的解决方案是什么？然后看答案，做对比。同样的，在看答案的时候，想想这个答案有没有什么缺陷，会不会带来新的问题。

这种带着问题去了解一个东西的方式，特别高效。特别是当你向一个牛人请教的时候，这种从问题的起点出发，带着疑问的探寻，会让你发现现实解决方案中的一些奇思妙想。

另外，想象这个系统是如何工作的，也大有裨益。通过想象，模拟网络的运行过程，可以让你对问题有个更加全局的认识。在这个过程中，你会生发出很多很多问题，也就知道自己要询问些什么东西了。

二、rime
rime是一个输入法后端的框架。

我首先想象，一个输入法前端，会怎么和rime交互。我的想法是，前端读取用户的输入，比如用户输入zuguo，然后前端将zuguo发送给后端，后端把可能的候选项返回给前端，前端显示给用户。结果发现，自己的想法不对。rime接收的是一个个的键码（keycode），而不是一个键码序列，也就是说，用户每敲一个键，前端就要把这个键传给后端。问题来了，这就要求后端要记录用户敲击的历史记录了。比如，当后端收到一个u,它得知道用户之前敲的是z，才能返回正确的候选字zu。所以，后端要保存一个状态机。那它由只是一个api，它是如何保存状态的呢？看看rime提供的api，process_key(session, keycode ,mask)。第一个参数session其实就是之前输入的状态。所以，rime通过将状态变成参数的形式，将维护状态的任务分离了出来。于是，使用rime的流程为 create_session --> process_key(session, ...) --> getcommit(session) --> getcommittext(session)，其中getcommit()询问后端，是否准备好了候选字，getcommittext()获取候选字。

你看，通过对比你自己的设计方案和他的设计方案，以及人家的设计方案可能面临的问题，你是不是对他的设计有了更加深刻的认识。可以认识到，rime的设计目的是，把所有输入法的算法部分，全部封装到它后端，而前端只要管输入法的界面，并且把用户的输入原封不动地搬运给后端即可。

rime还有一个值得称道的地方，就是它的内部设计，将输入法的处理流程由进行了细化，把整个输入法又分成了四个阶段，processor --> segmentor --> translator -->filter。每个阶段都可以进行私人订制，从而打造最适合自己的输入法。扩展后端也变得容易了很多。