├── README.md └── how-to-read-code.md /README.md: -------------------------------------------------------------------------------- 1 | ### 怎样阅读源代码 2 | 3 | 翻译自[How To Read Source Code]。原作者[Aria Stewart]。 4 | 5 | [How To Read Source Code]: https://github.com/aredridel/how-to-read-code/blob/master/how-to-read-code.md 6 | [Aria Stewart]: https://github.com/aredridel 7 | -------------------------------------------------------------------------------- /how-to-read-code.md: -------------------------------------------------------------------------------- 1 | 原题目：[How To Read Source Code]，原作者：Aria Stewart 2 | 3 | 中文翻译： 4 | 5 | [在博客中查看] 6 | 7 | 这篇文章基于我在Oneshot Nodeconf Christchurch的一个演讲。 8 | 9 | 我本来没有想要写这篇文章。程序员不读源代码听起来似乎是很荒谬的。然后我真遇到了一群不读源代码的程序员。接着我又跟更多的人进行了交谈，发现他们除了读代码示例或测试脚本之外什么也不看。最重要的是，我遇到过很多新手程序员，对他们来说，找到从哪个地方开始阅读是非常困难的。 10 | 11 | #### 当我们说读源代码的时候，我们要表达什么意思？ 12 | 我们是为了什么去读源代码？为了理解它。为了找bug，为了知道这些代码和系统中的其他软件是怎样交互的。我们还会为了回顾、品评而去读。为了找出其中的接口信息，为了理解和找到不同模块之间的界线，为了学习，我们都会去读源代码。 13 | 14 | #### 读代码不是一个线性过程 15 | 读代码的过程不是线性的。人们往往认为读源代码就像读一本书一样：先搞定简介或者README，然后从第一章开始一章一章的读，直到结束。其实并不是这样的。我们甚至都不能确定一个程序有没有结束，很多程序是不会终止的。我们应该在章节、模块之间跳转，反复阅读。我们也可以选择通读单个模块，但是这样我们就无法理解这个模块所引用的其他模块的代码。我们也可以根据程序的执行顺序去阅读，但是我们最后并不会清楚程序会向哪里执行。 16 | 17 | #### 读的顺序 18 | 要从一个库的入口开始读吗？对于Node库来说，即从`index.js`或者主脚本开始？ 19 | 20 | 在浏览器中的情况呢？即使是找到程序入口，弄清楚载入了哪些文件，是怎样载入的都是一个很关键的事情。去研究文件之间是怎样关联起来的是一个很好的着手点。 21 | 22 | 除此之外，还可以从最大的一个源文件开始读。或者尝试在debugger中设置一个“浅”断点，通过函数调用去追溯源代码。亦或在某些复杂晦涩的地方设置一个深断点，然后去读函数调用栈里面的每一个函数。 23 | 24 | #### 代码的分类 25 | 我通常习惯于以语言去区分源代码，如Javascript, C++, ES6, Befunge, Forth或者LISP。熟悉的语言读起来相对更容易，对于不太熟悉的语言，我们往往就不会去看了。 26 | 27 | 这里还有另外一种看待源代码的方法，就是基于每一的模块的功能去分类： 28 | 29 | - 连接类代码（Glue） 30 | - 接口定义类代码 31 | - 实现类 32 | - 算法类 33 | - 配置类 34 | - 任务类 35 | 36 | 关于算法类的代码已经有很多研究了，因为学术界就是干这个的。算法就是用数学模型去处理一件事情的方法。其他种类的代码就要模糊很多了，但是我认为它们更加有趣。它们才是绝大多数人在编程的时候写的代码。 37 | 38 | 当然，很多时候一个模块可以同时做以上的很多事情。而读代码首先要做的事情之一恰恰就是弄清楚每一个部分是在做什么。 39 | 40 | #### 什么是连接类代码 41 | 并不是所有的接口都能很好的工作在一起。连接类代码是将各模块连在一起的管道。中间件、Promise和绑定回调函数的代码、将参数导入object中或者解析object的代码，这些都属于连接类代码。 42 | 43 | #### 怎样阅读连接类代码 44 | 关键要弄清楚两个接口是怎样以不同方式构建起来的，以及它们共通的地方。 45 | 46 | 下面的例子来自于Ben Drucker的`stream-to-promise` 47 | 48 | ```Javascript 49 | internals.writable = function (stream) { 50 | return new Promise(function (resolve, reject) { 51 | stream.once('finish', resolve); 52 | stream.once('error', reject); 53 | }); 54 | }; 55 | ``` 56 | 57 | 可以看到，上面两个接口分别是Node的stream和Promise接口。 58 | 59 | 它们的共同点在于两者完成的时候都会执行一个操作，在Node中通过事件（event）来实现，而在Promise中通过调用resolve函数实现。 60 | 61 | 可以看到，Promise只能执行一次，但是stream可以发出同样的事件很多次。 62 | 63 | 更多连接类代码的例子： 64 | ```Javascript 65 | var record = { 66 | name: (input.name || '').trim(), 67 | age: isNaN(Number(input.age)) ? null : Number(input.age), 68 | email: validateEmail(input.email.trim()) 69 | } 70 | ``` 71 | 72 | 在读连接类代码的时候，还可以思考的是报错情况下的处理。 73 | 74 | 一段程序会抛出错误吗？能删除坏值吗？或者可以将其强制转换成可以接受的值？对于它们执行的环境来说，这些是正确的选择吗？类型转换是否是有损的？这些问题都是很值得思考的。 75 | 76 | #### 什么是接口定义类代码 77 | 可能你写过一些只在一两个地方用得到的模块，它们基本是在内部使用的，你不希望有人费很大劲去读这些模块。 78 | 79 | 而接口定义类代码却恰恰和上述情况相反。它们是模块之间泾渭分明的边界线。 80 | 81 | 下面的例子来自于Node的`events.js`： 82 | ```Javascript 83 | exports.usingDomains = false; 84 | 85 | function EventEmitter() { } 86 | exports.EventEmitter = EventEmitter; 87 | 88 | EventEmitter.prototype.setMaxListeners = function setMaxListeners(n) { }; 89 | EventEmitter.prototype.emit = function emit(type) { }; 90 | EventEmitter.prototype.addListener = function addListener(type, listener) { }; 91 | EventEmitter.prototype.on = EventEmitter.prototype.addListener; 92 | EventEmitter.prototype.once = function once(type, listener) { }; 93 | EventEmitter.prototype.removeListener = function removeListener(type, listener) { }; 94 | EventEmitter.prototype.removeAllListeners = function removeAllListeners(type) {}; 95 | EventEmitter.prototype.listeners = function listeners(type) { }; 96 | EventEmitter.listenerCount = function(emitter, type) { }; 97 | ``` 98 | 99 | 上面的代码在定义`EventEmitter`的接口。 100 | 101 | 关于这类代码可以思考的问题包括：它们是否完全？能提供哪些保证？内部的细节信息会暴露给用户吗？ 102 | 103 | 在一个有严格接口定义的架构中，上面就是这类代码应该出现的地方。 104 | 105 | 就像连接类代码一样，我们可以思考它是怎样处理错误和报错的。处理方法前后一致吗？能区分出因为内部不一致而出现的错误和因为用户使用不当而出现的错误吗？ 106 | 107 | #### 实现类代码 108 | ```Javascript 109 | startRouting: function() { 110 | this.router = this.router || this.constructor.map(K); 111 | 112 | var router = this.router; 113 | var location = get(this, 'location'); 114 | var container = this.container; 115 | var self = this; 116 | var initialURL = get(this, 'initialURL'); 117 | var initialTransition; 118 | 119 | // Allow the Location class to cancel the router setup while it refreshes 120 | // the page 121 | if (get(location, 'cancelRouterSetup')) { 122 | return; 123 | } 124 | 125 | this._setupRouter(router, location); 126 | 127 | container.register('view:default', _MetamorphView); 128 | container.register('view:toplevel', EmberView.extend()); 129 | 130 | location.onUpdateURL(function(url) { 131 | self.handleURL(url); 132 | }); 133 | 134 | if (typeof initialURL === "undefined") { 135 | initialURL = location.getURL(); 136 | } 137 | initialTransition = this.handleURL(initialURL); 138 | if (initialTransition && initialTransition.error) { 139 | throw initialTransition.error; 140 | } 141 | }, 142 | 143 | ``` 144 | 145 | 上面的示例取自`Ember.Router`。 146 | 147 | 这里往往是需要在“为什么”上作更多说明的地方。 148 | 149 | 读这类代码的时候应着重思考它是怎样跟更大的整体相融合的。 150 | 151 | 从公共接口中传入的值是怎样的？哪些需要验证(validation)？包含我们认为该有的值吗？会影响到其他哪些部分？当需要改写以加入新功能的时候会有哪些潜在危险？可能会导致程序崩溃的地方有哪些？有测试代码来对其进行测试吗？变量的生命周期是什么？ 152 | 153 | #### 算法 154 | 算法类代码是实现类代码的一种，通常是封装起来不对外暴露的。它可以说是程序的血肉。也是一款软件的业务逻辑和主进程所在。 155 | 156 | ```Javascript 157 | function Grammar(rules) { 158 | // Processing The Grammar 159 | // 160 | // Here we begin defining a grammar given the raw rules, terminal 161 | // symbols, and symbolic references to rules 162 | // 163 | // The input is a list of rules. 164 | // 165 | // The input grammar is amended with a final rule, the 'accept' rule, 166 | // which if it spans the parse chart, means the entire grammar was 167 | // accepted. This is needed in the case of a nulling start symbol. 168 | rules.push(Rule('_accept', [Ref('start')])); 169 | rules.acceptRule = rules.length - 1; 170 | 171 | ``` 172 | 173 | 上面的代码出自一个叫做`lotsawa`的解析引擎。 174 | 175 | 人们常说好的注释应该告诉读者为什么这件事情要这样来做，而不是一段代码在做什么。算法类代码通常需要更多的解释，因为如果是一个很简单的算法的话，那通常它就已经被吸纳进标准库中了。 176 | 177 | 下面这段代码是计算机系学生喜欢的（或者有糟糕记忆的）： 178 | 179 | ```Javascript 180 | // Build a list of all the symbols used in the grammar so they can be numbered instead of referred to 181 | // by name, and therefore their presence can be represented by a single bit in a set. 182 | function censusSymbols() { 183 | var out = []; 184 | rules.forEach(function(r) { 185 | if (!~out.indexOf(r.name)) out.push(r.name); 186 | 187 | r.symbols.forEach(function(s, i) { 188 | var symNo = out.indexOf(s.name); 189 | if (!~out.indexOf(s.name)) { 190 | symNo = out.length; 191 | out.push(s.name); 192 | } 193 | 194 | r.symbols[i] = symNo; 195 | }); 196 | 197 | r.sym = out.indexOf(r.name); 198 | }); 199 | 200 | return out; 201 | } 202 | 203 | rules.symbols = censusSymbols(); 204 | 205 | ``` 206 | 207 | 读起来像是数学论文，对吗？ 208 | 209 | 在读算法类代码的时候需要关注的事情之一就是其运用的数据结构。上面的程序建了一个符号列表，并确保其中没有重复元素。 210 | 211 | 读的时候同时也要注意有关程序时间复杂度的线索。上面的代码中，有两个循环。用大O来记的话，时间复杂度就是O(n * m)。但已经有人注意到，循环之中还有`indexOf`的调用。这在Javascript中也是循环操作。因此这又在时间复杂度上加了一个因子。还好这段代码并不是该算法的主要部分。 212 | 213 | #### 配置 214 | 源代码和配置文件之间的界线非常的窄。对配置文件来说，表达力强、可读性强和直接之间永远是冲突的。 215 | 216 | ```Javascript 217 | app.configure('production', 'staging', function() { 218 | app.enable('emails'); 219 | }); 220 | 221 | app.configure('test', function() { 222 | app.disable('emails'); 223 | }); 224 | ``` 225 | 226 | 上面是一个用Javascript进行配置的例子。 227 | 228 | 在这里可能会遇到的问题是不同选项的组合爆炸性增长。应该配置多少个环境？在每一个环境实例中又配置哪些东西？我们很容易就会过度配置，去考虑所有的情况，但是bug可能只出现于其中一种情况中。时刻注意配置文件给我们多少自由度是非常有用的。 229 | 230 | ```Javascript 231 | "express": { 232 | "env": "", // NOTE: `env` is managed by the framework. This value will be overwritten. 233 | "x-powered-by": false, 234 | "views": "path:./views", 235 | "mountpath": "/" 236 | }, 237 | 238 | "middleware": { 239 | 240 | "compress": { 241 | "enabled": false, 242 | "priority": 10, 243 | "module": "compression" 244 | }, 245 | 246 | "favicon": { 247 | "enabled": false, 248 | "priority": 30, 249 | "module": { 250 | "name": "serve-favicon", 251 | "arguments": [ "resolve:kraken-js/public/favicon.ico" ] 252 | } 253 | }, 254 | ``` 255 | 256 | 上面是一小段`kraken`的配置文件。 257 | 258 | Kraken采取了“低功耗(low power)语言”的路，其配置文件采用JSON。更多一点“配置”，而相对少一点“源代码”。其目的之一就是让可选择项的数目可控。很多工具都采用简单的key-value对或者ini类的文件来做配置是有道理的，即使这样会使配置文件的表达力受限。 259 | 260 | 配置类的代码有如下一些值得思考的有趣而独特的限制： 261 | 262 | - 生命周期 263 | - 机器可写性 264 | - 对一段代码负有责任的人会多很多 265 | - 怎样适用在一些奇怪的地方，比如环境变量 266 | - 往往有涉及安全的敏感信息 267 | 268 | #### 任务类 269 | 对50张信用卡计费，用编译器和其他构建工具开发一个复杂的软件，发出100封电子邮件。这些事情有什么共同点？ 270 | 271 | 事务性。通常一个系统的某一部分只需严格执行一次，而遇到错误的话则完全不执行。编译器遗留下的错误构建文件是bug的一大来源。对客户重复收费是很糟糕的。因为重试而向用户邮箱滥发邮件也很可怕。 272 | 273 | 重启性。能根据系统状态，在之前退出的地方继续运行。 274 | 275 | 序列性。对于不是严格线性的程序，通常都有一个方向明晰的执行流程。循环是其中一大块。 276 | 277 | #### 阅读杂乱代码 278 | 一般人会怎样入手下面的一段代码： 279 | ```Javascript 280 | DuplexCombination.prototype.on = function(ev, fn) { 281 | switch (ev) { 282 | case 'data': 283 | case 'end': 284 | case 'readable': 285 | this.reader.on(ev, fn); 286 | return this 287 | case 'drain': 288 | case 'finish': 289 | this.writer.on(ev, fn); 290 | return this 291 | default: 292 | return Duplex.prototype.on.call(this, ev, fn); 293 | } 294 | }; 295 | ``` 296 | 297 | 对，这就是反向缩进，要怪就怪Issac吧。 298 | 299 | #### 美化一下！ 300 | `standard -F dc.js` 301 | ```Javascript 302 | DuplexCombination.prototype.on = function (ev, fn) { 303 | switch (ev) { 304 | case 'data': 305 | case 'end': 306 | case 'readable': 307 | this.reader.on(ev, fn) 308 | return this 309 | case 'drain': 310 | case 'finish': 311 | this.writer.on(ev, fn) 312 | return this 313 | default: 314 | return Duplex.prototype.on.call(this, ev, fn) 315 | } 316 | } 317 | ``` 318 | 319 | 读代码的时候使用工具是很好的。 320 | 321 | 又比如下面这段代码： 322 | 323 | ```Javascript 324 | (function(t,e){if(typeof define==="function"&&define.amd){define(["underscore"," 325 | jquery","exports"],function(i,r,s){t.Backbone=e(t,s,i,r)})}else if(typeof export 326 | s!=="undefined"){var i=require("underscore");e(t,exports,i)}else{t.Backbone=e(t, 327 | {},t._,t.jQuery||t.Zepto||t.ender||t.$)}})(this,function(t,e,i,r){var s=t.Backbo 328 | ne;var n=[];var a=n.push;var o=n.slice;var h=n.splice;e.VERSION="1.1.2";e.$=r;e. 329 | noConflict=function(){t.Backbone=s;return this};e.emulateHTTP=false;e.emulateJSO 330 | N=false;var u=e.Events={on:function(t,e,i){if(!c(this,"on",t,[e,i])||!e)return t 331 | his;this._events||(this._events={});var r=this._events[t]||(this._events[t]=[]); 332 | r.push({callback:e,context:i,ctx:i||this});return this},once:function(t,e,r){if( 333 | !c(this,"once",t,[e,r])||!e)return this;var s=this;var n=i.once(function(){s.off 334 | (t,n);e.apply(this,arguments)});n._callback=e;return this.on(t,n,r)},off:functio 335 | n(t,e,r){var s,n,a,o,h,u,l,f;if(!this._events||!c(this,"off",t,[e,r]))return thi 336 | s;if(!t&&!e&&!r){this._events=void 0;return this}o=t?[t]:i.keys(this._events);fo 337 | r(h=0,u=o.length;h READY -> FINISHED` 432 | 433 | ```Javascript 434 | isReadied | isFinished | state 435 | ----------|------------|------------ 436 | false | false | START 437 | false | true | invalid 438 | true | false | READY 439 | true | true | FINISHED 440 | ``` 441 | 442 | 443 | #### 找构造（composition)和继承 444 | 这段代码有我认识的部分吗？它们有名字吗？ 445 | 446 | #### 找相同的操作 447 | `map`, `reduce`, cross-join。 448 | 449 | 是时候开始读源代码了，Enjoy！ 450 | 451 | [How To Read Source Code]: https://github.com/aredridel/how-to-read-code/blob/master/how-to-read-code.md 452 | [在博客中查看]: http://blog.yongfengzhang.com/cn/blog/how-to-read-source-code/ 453 | --------------------------------------------------------------------------------