How to improve yourself

Rule 0: Keep improving
这个没有什么好说的，你要提升自己就要不断地去做。所谓不进则退，今天提升一点明天休息一下，实际上你就和大家的平均水平差不多。所谓的提升就是要让自己比别人更好，要保证这一点只能够尽力做到最好，也就是不断的去提升自己的水平。

Rule 1: Balance your self first
每个人都有自己的特性，比如说喜欢思考还是喜欢做事情，或者比如乐观还是悲观等等，这个问题看你怎么去理解。一般来说一个人总是比较容易在某一些方面上有失偏颇的，甚至在某些方面会容易走极端，在我认识的人当中就有自我感觉过于良好的人，也有自己对自己非常没有信心的。一般说来走极端对于自身的发展并不是一件好事，因此需要平衡一下，这就需要你更多的接触一些与你不相同的人，不要老呆在自己的圈子里面。换一下自己的工作环境从这个角度来说是一件好事，就拿我来举例子吧：
这段时间已经到JGTM2004这里工作了几天，发现我有点想得太多了，在JGTM2004不断的要求do it的情况下，我发现了这个问题。一开始还感觉很不习惯很不自然，但是渐渐的找到了另外一种感觉，解决了一些我的困惑。其实思考就是产生困惑的根源，而动手则是解决困惑的基本方法。思考可以给我们带来很多的问题，相应的就有可能解决这个问题，但是在动手解决这个问题之前你是不可能知道解决的方法的。
其实这个问题我以前也观察到过，比如我看到很多刚刚开始学编程的人，以及那些水平不高的人都有一个类似的问题。举一个实际的例子：某个人在调程序，突然出了一个运行时错误，然后不单步也不看变量，就在一个劲的看自己的代码，而且看了五分钟了屏幕都没有翻页。什么问题呢？就是在试图像读散文一样读程序代码，似乎哪一段代码描述了这个程序在什么时候会心情不好所以出错了一样。要知道读代码可是一个高级能力，不是一年半载就能够通过看看代码得知错误根源的，这种能力需要你常年累月的经验积累才能够得到的。你需要的是动手：首先看看出错的数据是什么，然后估计这个错误数据可能的来源是哪里（也就是估计控制流是从哪里来的），然后设置端点重新运行，重复这一步骤知道找到产生错误数据的来源。如果不去动手设置端点调试，只是在试图读代码然后思考问题发生在哪里，那么估计你再写五年的程序当程序运行出错的时候也只能够在屏幕面前发呆。换一句话说，你没有办法提升自己。
其实反过来也一样，我也经常看到另外一些例子：某个人批哩啪啪在屏幕前面敲键盘，也懂得调试，解决Bug也不成问题。但是你会发现这个人有那么一堆的错误或者问题，昨天这么犯，今天这么犯，明天还那么犯。因为缺乏思考，所以没有进步。如果你整天觉得写一个程序整天改来改去的很痛苦，那表示你需要学一学Design Pattern，思考一下了。换句话说，太注重动手了也不是一件好事。
说到这里，我想引申一下这一条Rule：

1.1 When you got a problem, go working on it until it is worked out.
中国的教育制度总是给人灌输思想，而不是灌输解决问题的办法。当我们面对问题的时候总是比较习惯于首先等待别人来帮我们解决或者告诉我们怎么去解决，如果不行就查资料，或者闭着眼睛思考到底发生了什么情况。实际上很多时候尝试动动手，问题也许就会变得简单清晰起来。记住一点，思考只会让问题变得复杂起来。

1.2 When you got a problem continually, go learning, thinking and summarizing.
很多时候该思考的时候我们却不懂得需要思考，当一个问题不断的重复出现的时候，我们就需要去学习和思考。动手确实是解决问题的方法，但是不断地出现这样的问题说明你的方法出了问题，你需要去学习一些新的方法。学习来的东西是死的，指能够给你提供参考，至于你如何去解决你的问题就需要你自己需分析，这里就是思考。而很多时候解决某一个问题的方法也不是只有一种，会有很多方法能够解决问题，不同的方法当然会有优缺点。什么时候用什么方法比较好，或者说当哪方面更重要的时候用什么方法更好，为什么这样，这些都是需要总结的东西。其实这里中间还有一个环节，就是动手。因为你思考了就必然会产生一大堆的问题，要解决这些问题或者证实你的想法，就需要你动手去做，做完了再来总结。

小结：你在提升自己之前首先要做的一件事情就是“平衡”。他可能会提高你的效率，可能会让你突破瓶颈，也可能会带领你进入新的领域里面去，这是一件很重要的事情。需要平衡什么，你只需要看看那些跟你很不一样的人就知道了。当然，平衡不是指平均值，那样就会失去一个人的个性，只要不是走极端就好。

Rule 2: Don't try to make a big step ahead for one time. Divide your target into small pieces, until you can achieve them in days.
比如我要做一个项目的总体设计，很明显我不可能一下子就把整个系统的每一个部件的安放位置，每个模块之间的协作方式，每个协议的具体内容，以致每一个函数的代码都想得清清楚楚。那不是正常人的能力所及的事情，因此我们需要把整个的过程进行细分。首先思考一下整个框架的大体结构是什么样子的，需要哪些东西。然后就开始对其中的一个部分进行粗略的设计，证实我的想法是可行的，尽管可能有一些问题存在。然后对另外一部分进行试验，直到你通过这个方法对每一部分都有了一定的实际了解。这个时候你会发现你的信心大增，并且想法也更加清晰了。然后你再对某一个部分进行改进，添加更多的细节，实现更加接近于成品的功能。如此不断地循环，目标才会离你越来越近，并且整个过程你是能够看得见的，能够确定的。
这里请容许我引申一下：

2.1 Stop thinking about the small pieces of tasks you're not doing. Suppose they're done!
在你解决一个小问题的时候，思考其他需要解决的小问题，对于你解决当前的问题是毫无益处的。前面已经说到过了，思考是产生问题的根源，你在解决某个问题的时候不断地去产生问题，那么这些问题什么时候才能够解决呢？最后你会发现问题不断地膨胀，甚至爆炸了！怎么办？你只好假装那些小问题已经解决了，如果你实在是担心那些你不是正要解决的问题，你只好想办法尽快完成当前的工作。比如说你可以比较粗糙的去解决这个问题，用一个相对简单的框架，减少实现功能的数量，等等等等。总之要解决了一个问题再去解决另一个。

2.2 Keep doing small things right will makes you achieve big goals.
很明显的可以看到，实际上大事情都是有小事情构成的，做好了小事情才能够完成远大的理想。其实这只是一个方面，从另一个方面可以这么说，如果你不是把大事情分成小事情来做，并且一个一个单独的去解决，那么肯定没法有效地完成整件事情。没有好好的做每一件小事，要么是你没有把你的大事分解成小事，要么你分解了之后还在整天想着你的大事，这都是影响你完成你的大事的障碍。

Rule 3: Keep learning how to improve yourself
上面哪几点只是我个人的经验，受限制于我目前的阅历，受限制于我现在写作的时间，不可能写的什么都有。虽然这是我目前认为最重要的几点，并且我想我会经常检阅自己看看是否做到了这几点，但是这不是全部。因此还需要做到的是，不断地去学习那些能够对提升自己的水平有帮助的方法，注意是方法。（不是具体的经验）

明天如果有空的话，我想写一下最近所学到的，可能对进行构造有帮助的经验，这一篇权当是预告吧。