拿什么心情来阅读我的代码(程序员的必备心理技能)

原文首发于我的微信公众号:GeekArtT .

阅读源代码的开始阶段,最好从感兴趣、自己有直观感受且有相对丰富准确的文档的项目开始。如同最开始阅读数学证明,最好从浅显易懂的教材开始,之后再开始最前沿的paper阅读。

阅读源代码需要同阅读证明一样的耐心,甚至更多。数学的定义或许就在前一页,可是源代码的某个新的类却需要你不断地Google,进而找到适合自己的关于原始概念的定义论述。

阅读源代码一定要放空自己的心,要做好精心死磕的准备。至少要在心理上给自己留出足够多的空间与时间。大不了拿出大段时间去浪费,去阅读、去死磕、去慢慢地把玩这个小片段的内容。(或者更成熟的想法是,完全集中注意力在自己的阅读工作上,根本不去关心它所需要花费的时间。)在这个阶段,最好拿出最为自私的气魄,TMD全世界的事情和期望都不管了,我就要在这个小小的代码片段所形成的逻辑框架里慢慢破解我的问题。

能否继续下去之后的阅读,这个阶段的心理就是绝对的分水岭。不要去想什么意义不意义,不要去思考什么浮躁的进度或者世界期望、又或是想什么此生也就如此的屁话,那些“存在”的问题是在决定是否开始阅读的时候考虑的,而不是阅读之中。在阅读的过程中,就如同已经在雪山上的登山者,已经毫无退路,最优做法就是不要把自己的精力浪费在任何无关事情之上,而是把所有力气花在问题攻坚上。

在这一刻,研究者是世界的王者。世界都必须为他而停止,他要拥有至高无上的心理信心。因为,一名研究者的珍贵价值之一,便是能够完全吃透繁杂深奥的问题和论述。而这项工作兼具思维的复杂性与劳作的漫长艰辛。他需要将自己的智慧挖掘到最深处。并在同时,他要像一名在流水线上劳作的工人,经历无意义的重复劳作和蛮长时间的煎熬。因为破解这些谜题,需要一次又一次西西弗斯式的基础工作。不断地提出一个猜想,然后找寻证据去证明或者否定,然后继续下一个问题,又或是提出另一个思路,继续做探索和验证。

而思路的建立或者潜在可行方案的直觉,都会牢牢建立在你对某个类或者某个文件的认知和相应定义的理解上。例如,向一个初学Android的人直接抛出PreferenceManager的概念会让人一头雾水。你可能会有潜在的猜测,偏好设置?仅仅是某个setting文件的管理?又或是神马?可是为什么在使用它的时候又会用到工厂模式?相应的edit是要去编辑神马呢?

不,这些都只是你一厢情愿的猜测。甚至,你的猜得越远,错得越厉害。而错误的起步,当然就是源自于你对PreferenceManager定义的猜测。这是代码世界中更加tricky的一个坑。不同于数学证明,由于数学领域的大多数术语都是稀奇古怪的或者生僻从未听说过,在阅读证明时,我们反而能更加警觉、仔细地去按图索骥,找到定义最原始的出处,去确保自己的理解无误。而在代码的世界里,由于命名需要可理解、通俗易懂,大多数的命名都会找寻生活中常见的词语。而这里,便是入坑的开始。

如果你对人文历史有足够充分的研究,你便会知道日常用语的多意性以及它所带来的后果的惨痛性。当在代码中充斥着各种似曾相识的名字时,你便会被这个“名”(名字)所迷惑。你会下意识地根据自身的经验去猜测它的作用和所指。虽然好的代码规范总是要求对命名要做到避免模糊和误用的特性,但你凭什么知道你阅读的这份代码遵从了它呢?

所以,真正正确的打开方式是,你必须确保你对其中的每一个术语都真正做到了知道它的原始定义所在。你必须要有可信程度极高的证据来支持你对定义的理解:最可信的莫过于定义这个术语的源代码,其次是它的官方API文档说明。你不可以用自己的历史经验来作为正确理解的论据。相反,你需要把这份艰辛的苦力做好、做扎实,为每一个术语找到最原始的依据,然后根据这个依据来确保自己的理解正确。

有了“术语考据”这一步的坚实基础,之后的代码阅读就会相对轻松。例如在上面的例子中,如果你查询过Android文档,查看过StackOverflow上的解析,你便会发现这个PreferenceManager是特有的存储临时信息(方便App内部沟通共享)的方式。那么,之后运用工厂模式的理由就变得显而易见了。所以,和数学证明的研读极其类似,找准了定义、吃准了最原始的“名”背后的“道”(真正所指),就能够为之后的过程起到四两拨千斤的巨大作用。

当然,这一过程无疑是费时费力的。往往,一个下午的尝试也就只能换取一行代码的正确理解。而身处这一耗尽心力的过程中,你绝望地感觉到,似乎所有的工作都毫无进展。然而,如同对数学证明的学习,这也正是其价值所在。没有多少人能够继续这种耗时耗力的孤独坚持,而这每一步的微小进展,其背后都有难以估量的时间与大量尝试的累积。所以在这一刻,阅读者需要在心里树立起毫无理由的自信心,让世界为自己去停止,让他人的期望在此刻消失。此时此刻,只有代码的破解与思维的运转。

如此耐心劳作,方能习得最精妙的技术,最坚实的设计。



如果你喜欢我的文章或分享,请长按下面的二维码关注我的微信公众号,谢谢!

时间: 2024-12-09 23:53:22

拿什么心情来阅读我的代码(程序员的必备心理技能)的相关文章

如何优化C语言代码(程序员必读)

如何优化C语言代码(程序员必读) 5.减少运算的强度 可以使用运算量小但功能相同的表达式替换原来复杂的的表达式.如下: (1).求余运算. a=a%8; 可以改为: a=a&7; 说明:位操作只需一个指令周期即可完成,而大部分的C编译器的“%”运算均是调 用子程序来完成,代码长.执行速度慢.通常,只要求是求2n方的余数,均可使用 位操作的方法来代替. (2).平方运算 a=pow(a,2.0); 可以改为: a=a*a; 说明:在有内置硬件乘法器的单片机中(如51系列),乘法运算比求平方运算快得

python代码 程序员编程艺术 2.1

首先一般考虑"万能的"暴力穷举(递归.回溯).但因为穷举时间复杂度通常过高,所以需要考虑更好的方法,如分治法(通过分而治之,然后归并),以及空间换时间(如活用哈希表). 此外,选择合适的数据结构可以显著提升效率,如寻找最小的k个数中,用堆代替数组. 再有,如果题目允许排序,则可以考虑排序.比如,寻找和为定值的两个数中,先排序,然后用前后两个指针往中间扫.而如果如果已经排好序了(如杨氏矩阵查找中),则想想有无必要二分.但是,如果题目不允许排序呢?这个时候,我们可以考虑不改变数列顺序的贪心

python代码 程序员编程艺术 1.1

<程序员编程艺术:面试和算法心得>http://taop.marchtea.com/ https://github.com/julycoding/The-Art-Of-Programming-By-July/tree/master/ebook/code/python 1.1 旋转字符串 1: def simpleShift(str, n): 2: tmpStr = str[n:] + str[:n] 3: return tmpStr 4:   5: def LeftShiftOne(str):

高效能程序员的修炼阅读

入门 宣扬 "每个人都需要知道如何去编程" (乔布斯说的) 是 一种倒退!举个例子: 马桶堵住了,你不需要特地去学 高级水管工 的课程. 生命中最苦难的是想清楚自己真正要做事情,如果你探索的道路上,决定仍然走上 编程之路,那应该用尽一切方法去学.我的祝福与你同在,当然我的祝福 你听听 就算了,他帮不了你. 绝不要为了学编程而学编程,学编程应该是为了追求快乐 . 我成为程序员是因为我想改变我所玩电脑游戏的规则,而学习编程是唯一的途径. 代码是一种信仰. 善于写作,学会表达,即使没人看 八

《程序员修炼之道--从小工到专家》阅读笔记02

<程序员修炼之道--从小工到专家>在第三章中为我们提到纯文本的好好处,书中给我们提醒到,通过纯文本(XML.SGML以及HTML都是纯文本的好例子)我们可以让事情变得更容易.文本对于我们来说有三大好处:保证不过是.杠杆作用.更易于测试.对于程序员,不仅要善于使用纯文本,还必须掌握shell命令行,即使在Windows下我们也要精准掌握.Shell对于我们来说就是我们的工作台,在shell命令下我们可以操作调用我们想要的东西.可以说shell功能是非常强大的,所以对于我们程序员来说掌握它是对我们

从阅读Discuz的核心代码并给出注释的经历分析程序员该如何阅读代码?

本文标签:   程序员 php Discuz的核心代码 框架 深度学习框架 阅读优秀的代码,是技术水平成长的最佳途径.记得每个进来的新人,我都做过阅读优秀代码的要求,但几乎都只能坚持很少一段时间而已. 前晚大家还在开玩笑的讨论,都是因为看了前人的一些写法,才学会了一些乱七八糟的花招. 晚上我又开始重新阅读Discuz的核心代码,花了1h多的时间,才完成一个core文件的注释. 注释后的代码: <?php /** * [Discuz!] (C)2001-2099 Comsenz Inc. * Th

如何通过阅读别人的代码提高自己的编程能力

代码阅读的必要性 阅读别人的代码作为研发人员是一件经常要做的事情.一个是学习新的编程语言的时候通过阅读别人的代码是个最佳的学习方法,另外是积累编程经验.如果你有机 会阅读一些操作系统的代码会帮助你理解一些基本的原理.更有就是在你作为一个质量确保人员或一个小领导的时候如果你要做白盒测试的时候没有阅读代码的能力 是不能完成相应的任务.最后一个就是如果你中途接手一个项目的时候或给一个项目做售后服务的时候是要有阅读代码的能力的. 收集所有可能收集的材料阅 读代码要做的第一件事情是收集所有和项目相关的资料

程序员的进步从阅读自己的老代码开始

英文原文:Look at your old code 关于如何成为一个更优秀的程序员这个问题,互联网上比比皆是.而答案大同小异:看书.同行评审.参与开源项目等等.但是,关于如何检测自己是不是真的进步了这个问题,却一直悬而未决. 我经常鼓励我的同行说,对于自己写的代码,无论是什么语言什么项目都应该不遗余力地尽可能长时间地保存下来,放到安全的地方(即 GIT/ SVN).几年过去之后,再拿出来翻一翻.回过头来看自己的代码,会有一种神奇的喜剧效果,“OMG,这么狗屎的代码居然是我写的!!”,但是相信我

如何阅读一份代码?

https://zhuanlan.zhihu.com/p/26222486 ****************************** 上文谈到了像读书一样阅读源码的重要性,今天谈谈如何阅读一份代码.我所谓的一份代码,其范围可能从几千行到数万行,有时甚至可多达数十万行.这些代码作为一个有机体,共同完成某些重要的功能.比如说几个著名的 full fledged web framework,祖师爷 rails,师叔 django 和小师妹 phoenix: 三者对比很有意思 - rails / d