一点点进步和感受-----读代码比写代码还重要

[AlexiaChen]

这里特别是对于工作3-5年的程序员

做了区块链以后，才算真正意义上通过好奇（需求驱动），去阅读了世界上顶尖开源项目的源码，比如BTC的源码。会好奇，别人是怎么做的，以前的读源码漫无目的，枯燥无味，所以还是跟做英语阅读理解一样，首先要解决问题，而解决问题最快的办法就是带着疑问，问题，去看比你牛逼无数倍的人到底是怎么做的。这样阅读源码的效率就高多了，也有收获。

但是其中也有点问题就是，源码告诉了你How，就是它们怎么解决的，但是大部分你不会理解How的背后Why是怎样的，就是他们这些牛人是怎样随着项目发展演进，设计上有什么样的取舍。看似笨拙的方法，到底为什么这样设计？如果能看到详细的内部设计文档，讨论（mailing list）会更好些。所以读issue和Pull Request，研究社区各类牛人的讨论过程，代码评审，在某种程度上又比读源码本身更加重要。

所以，最终的方法是，平时follow社区的讨论issue，PR，这个优先级最高，掌握取舍，高层次的设计是最好的，这是理解Why的最好办法。其次才是源码细节， 也就是How。

之前在知乎写过一个回答 https://www.zhihu.com/question/372800830/answer/1036416740

里面提到我的前Boss，非常厉害的人物，擅长在不短的时间内写复杂系统，包括区块链，BPMN引擎，编解码器。而且复杂度已经远远超过玩具，我请教了他，他说关键还是要看代码，看多了，有体会了，自然就能写比较成品的复杂系统了。

以下摘录一些牛人或非牛人的有价值的语录或者方法论：

• 烂程序员关心的是代码。好程序员关心的是数据结构和它们之间的关系。-----linus
• 读懂开源项目代码，会改开源项目代码，会重写开源项目，是三个渐进式体验。 ----- 褚霸，余锋
• 先把项目编译运行起来，打日志或者加断点调试。------------- 不清楚来源
• 看大项目，首先要看Happy Path，也就是一般来说是对于对于某个模块来说，是BFS的看，而不是DFS。先不要管corner case或错误异常处理，先看主要正常流程。也就是自顶向下。 ------------- 陈硕
• 大项目，不要从最新的commit开始看，不然容易陷入无限细节，从软件的0.0.x版本看，看懂了再逐步跳跃式的看。（但也有人说，从最新的版本开始看，因为热门开源项目，后期会重构多次，重构代码可读性更高）------- 不清楚来源
• 看经典的小项目，容易拆轮子，也容易重写。github上其实有很多星星不多，但是很值得一读的源码 。（不鼓励重新发明轮子，但是鼓励重新造轮子）---------- 不清楚来源
• 写源码分析笔记，多画图，少用文本。理解是最主要的，切勿大段复制代码 -------- 不清楚来源
• 用某个你目前不熟悉但是想学的编程语言去翻译某开源项目的初版源码，比如用Rust翻译早期Spark源码，这样既可以学习Rust，也可以学习其生态，还可以学习Spark的思想。一举三得。------ 不清楚来源
• 带着问题去读源码，切勿通读源码，与做英语阅读理解是一样的。读源码的原因是解决问题。----- 不清楚来源
• 先把握整体结构（目录结构，代码结构），再深入细节，细节看不懂，那就看十遍，死磕，总会看懂的。
• 先看文档，再看单元测试，顺着单元测试往下看。------- vczh
• 多看，猛看，看了几十万行规模的系统再看其他系统就是如履平地。我们早年看了ACE库的代码，熟悉帮助我们抽象了各种基本的OS原语，再到后来的Nginx产品化的东西，最后是Erlang的虚拟机，差不多用了10年时间-------褚霸，余锋

再给些知乎上的相关问题:

• https://zhuanlan.zhihu.com/p/26222486
• https://zhuanlan.zhihu.com/p/114868001
• https://www.zhihu.com/question/26766601
• https://www.zhihu.com/question/23362874