提高代码水平

1.读高质量的代码，比如高手写的代码，思考他们编程时在思考什么？，还有就是源码
2.读完代码，其次要亲手学习编写，这样才能脚踏实地，系统的提高。
3.调试，需要熟练使用有效的工具，注重模块化调试，单元测试。
4.遇见问题，总是一时的，要耐心对待每一个自己遇见的问题，遇见问题，其实是提高代码的关键，需要重视，如果不重视，哪怕工作时间再长，编程能力同样没有多大的提高，写出来的代码质量不高。

这问题很大程度上是个开放性的问题，行业界基本还没有出现统一的答案。最关键的是注意模块化。把程序分成小的功能模块，每个模块要能单独拿出来测试。模块间注意去掉循环依赖，这样所有模块会自然分层，遇到问题的时候可以一层一层往下调试。用IDE和debugger其实有很大功能局限性，更好用的办法往往是打印log分析log。printf基本是万能的。训练可以这样。写一个稍微有点规模的项目，大于2000行代码的那种，然后尝试把它分成小模块，每个模块一个文件，每个文件不超过300行（或者500行，有的语言可能本身更啰嗦一点），每行不超过80个字符。每个模块尽量只做一件小事情。注意让模块之间没有循环依赖。给每个模块写单元测试。然后，写出来这个project之后，把模块之间的依赖关系画个图（像这个：Go standard library DAG visualization），拿着这个图给你的一个（同样高数没有问题的）朋友看，让他参照着这个图去读你的源代码，看他能不能读懂你的代码要做什么，是怎么做的。如果他能读懂，说明你模块分得非常好。如果他读不懂，可以具体看他读哪个模块读不懂了，研究一下有没有更好的模块化方式或者写法。如果你的所有代码都能模块化成这个水平，那么你的代码质量（尤其是在代码可读性和可维护性上）已经是世界一流的了。真心的。

Debug这个问题显然是相当的开放。我相信对于每个程序员都会有自己Debug的具体方法。但是由于Bug这个东西的出现一般相当的诡异，有很多不确定的因素。在找出来之前也不知道具体是什么原因造成的，所以说可能还是没有通用的一套方法来找出Bug。那么我抛个砖，来说说平时我Debug过程中的一些奇技淫巧吧。首先，从Bug产生的可能情况来看，越是复杂的工程，产生Bug的数量就会越多，而且实际情况是，这两个之间的关联是非线性的。所以一定要畏惧代码的复杂度。对于短小的代码而言Bug显然会更容易调通一些。一个非常重要的工作就是进行单元测试。一个非常重要的工作就是进行单元测试。（因为真的很重要，所以我要说两遍）对于每个单一的函数、模块、程序等，依次进行测试。去生成一组范围内的数据（尤其是一些极限情况的数据），保证每个函数、模块、程序都能够在任何情况下返回正确的结果。单元测试的另外一个重要意义是为了防止一种我个人认为Bug中最最恶心的东西。那就是重合Bug。我的意思是，一个程序有多个Bug，他们一起存在在你程序中时，互相发生了奇怪的作用，导致只有某些特定的数据下才会出错。而当你调通其中一个的时候，你所有数据都出错了。你下意识就会以为自己之前的修补出了问题。虽然这种情况听起来非常扯，但是实际上，我经常遇到这样的问题。除了单元测试，一个非常重要的技巧是封装封装再封装。把所有可能需要重复调用的东西都封装成接口、抽象类、方法或者函数。这样所带来的好处是不言而喻的。一旦出了问题，可以一次性修改掉所有的代码。而且调试程序的时候代码非常短，可以很容易确定出出问题的究竟是哪个部分。对于具体代码的调试，我想上面一些答主已经说的很不错了。最常用的还是打印log的方法。当然，一个擅长去使用一个IDE在开发工程的时候也是必要的。它可以更好帮你跟踪每个变量在运行过程中是怎么变化的，当然这些个也是没有固定的方法的。不用去比较哪个IDE好用，哪个IDE不好用。我觉得对于大多数情况而言，并不需要IDE一些奇奇怪怪的特性支持，能断点能显示变量就基本够用了。至于很多同学提到可以进一步采用Test Driven Development的方法规避Bug。个人认为这在大工程下是很有效的，但是也相当地反人类。我觉得还是要依据工程的规模和自身团队的情况进行选择，或者进行变化。毕竟一个人的命运啊，当然要靠自我奋斗，但也要考虑历史的进程。根据业内多年的经验，Pair Programming也能大大提高代码的可靠性。

如何提高编程能力，这个问题几乎是媒体们采访大神们必问的问题。就我所敬仰的一些大神们（Linus，Yukihiro Matsumoto，TJ，多隆等）的回答都会提到多读源码，当然每个人还会列出其他的一些内容，但是我觉得读源码是十分核心的提升编程能力的方法。（debug其实也是编程能力的一部分，区别可能是需要熟悉一些debug的工具，不过我觉得就题主来说这都是浮云。编程能力本身是核心。等编程能力上去了，读代码的时候读到不对的地方就会感到硌牙，设计模块设计不好就会觉得难受，然后debug自然而然就顺当多了。。。）读高质量的源码有什么好处呢？ 这和大量的阅读对于写作有什么好处是十分类似的，我想题主作为一个很高阅读量，文字功夫也非常好的人对此应该也是深有体会的。这种好处难以用条条框框来说清楚。套用文学上的说法那叫语感。写代码也有语感。创作自己的东西之前首先就是阅读别人创作的东西。多看了高手们是怎么写代码的，试图去理解高手们写代码时在想什么，久而久之（其实也不用太久，两个礼拜细心的读代码就能让能力上升一大截。）自己就会模仿就会慢慢地学会如何像大神一样写代码。等阅读量和写作量积累到一定程度，很多业界所谓的设计规范，模块流程会自然而然的理解并遵照执行，因为这已成习惯。（其实没说的那么自然啦，据传TJ大神是纯看代码流。[TJ Holowaychuk’s answer to How did TJ Holowaychuk learn to program?] 正常人会看些书同步补充些规范啊之类的相关知识来帮助看懂代码。）相反如果一开始强套规范，容易遇到瓶颈，那时就只好说，臣妾做不到啊。----------------------------------------------------2/15更新-我觉得适合（以学习目的）阅读的代码有一下几个特点。1。高质量。比如千锤百炼的基础库。2。上下文环境熟悉。在读一个函数或组件的代码之前应该用过它，最好是经常用它，对于它的用法十分熟悉。恩，这也是我首先推荐阅读基础组件库的原因，因为这些总是经常用到的。3。不涉及过于专业的知识。基础库很多代码并不适合这一条，特别是为了性能考量，代码中会涉及一些比较难的算法和罕见的处理手段。所幸的是这种东西出来的时候一般都会带上大把注释。开始时候回避一下，后来还是很值得读一读的。是在看不懂的话多读一两篇paper也能搞定，一般注释中都给出线索的。（当然了，有些就变成迷了，比如这段非常有名的代码，就只是留了个很邪恶的注释。 Fast inverse square root。）读了代码以后可以做的两件事。1。 默写。读完代码以后等感觉基本把细节忘干净了，比如一周到一个月后。像我这种小短脑三天就够了。。。自己把阅读的代码实现一遍。如果实现不下去了，或者觉得自己实现得很丑，就看看原版代码。我自己在实践过程中最常碰到的就是模块设计上的障碍，核心的算法往往记得，数据结构也大致记得，但是模块是怎么设计的就忘得一干二净了。写起东西来总是磕磕绊绊的，然后再回头去看“正确答案”，会对别人的设计理解更深一层，发现在美好的设计下那些磕磕绊绊都自然消失了。或者忘了其他什么部分，总之忘了什么就说明缺什么，回头看一下大师的代码就能赶快补上。2。翻译。现在很多开源项目的项目介绍中都会写“inspired by balabala”，基本是说我看了某某项目的源码（语言A），然后依着他的框架结构功能在语言B里实现了一套。这件事情其实是十分好的锻炼编程能力的方法，算法、逻辑、设计别人都已经做好了，需要做的只是迁移。迁移的过程中需要对原项目的代码结构有清晰的认识，还需要在现项目中对应的实现，但是对于原算法的理解和一些其他业务性的考量要求却不高（毕竟只要抄就好了）。如此一来，几乎就是集中锻炼了纯纯地编码能力。-------------------------------------------------------关于debug，我觉得这其实是小事，还有那么多人还在用printf debug呢! 但是也是很烦恼的一件事，很多时候总是觉得debug很不顺手。这里也说一下我的看法。debug首先是编程能力的一部分，如果都搞不太清楚程序再干什么又怎么debug呢？如果模块设计很差，算法实现混乱，出错的概率和debug的难度当然会增加。相反，设计的好，编程习惯好，想出错都不容易。debug主要有三种工具，debugger（mike zhang 给出的 26.2. pdb — The Python Debugger 是一个很好的debugger工具。），log（print大法），assertion & testcase （可以视为一种工具化再抽象的print大法，其实本质和log没区别）。可以从这样一个视角去看这三种工具：工具： debugger——log————assertion可操作度（对人灵活性）： 高————中————低表述能力（对机器灵活性）：低————中————高请按需取用，对于离机器端较远，逻辑抽象度较高的应用，一般会更看重debug时对内部状态的表述能力而不是具体的运行细节。相反离机器端比较近的，逻辑抽象度并不高的场景，一般更喜欢用debug一步一步跟，希望能了解程序具体的运行细节。以上仅仅是我个人的理解，实践出真知。各种debug方法都用一下，然后再判断该怎么debug吧。况且实际使用时各类工具是可以混合使用的。另外当程序规模渐渐超出一个程序员能力范围的时候，debug有时的确是十分苦恼的，大神也不例外，他们也会抱怨，然后说“我不想再写XXX了”。例如：Why should I have written ZeroMQ in C, not C++ (part I)Farewell Node.js（记得linus也吐槽过linux kernel变得越来越大而越来越难以维护和调试，文章我找不到了。如果有线索的童鞋希望能告知一下。）所以当觉得调试很难时请不要灰心。那些说着不干了的大神们后来还是都回到了自己原来的位置。困难总是一时的。------------------------------------------------------对于python来说有一步很重要的debug步骤静态类型检查不是python环境自带的。它可以在运行期之前就解析并探知python代码中的类型错误，十分有用。可以减少很多的麻烦。现在比较好的工具如下。Sourcegraphhttps://github.com/yinwang0/pysonar2------------------------------------------------------然后就如同教别人怎么读书一下，现在应该写推荐书目了：先弱弱的问一句除了python还会什么？一般而言读源码我会先推荐别人当前语言的标准库，先从二分搜索和排序开始看起。这两个算法几乎每个语言的标准库中都有，它们是将逻辑本质从事物本身表象中解耦的典范，而且除了语言本身以外它们对其他知识和上下文语义的依赖很小，十分适合作为最早的读物。很可惜的是python的这部分标准库是C写的，所以并不能靠读这些立杆见影地提高python的编码能力。（当然那些C代码也很有价值，特别是python的排序实现，很精彩，后来被java啊，octave啊，gnome啊都抄了去。其实编程能力总是相通的，读了对python还是很有好处的。）入门"书籍"都不知道推荐什么，真让人团团转。（我猜其实题主既然是用python在做机器学习，应该底层实际接触的还是C。其实cpython的标准库也可以读～～）恩，推荐"书目"之前我能问一下题主的编程水平吗？比如写过多少代码。然后看看这里Problems | LeetCode OJ的题目，用python做一下感觉如何？（这里的题目也很好，做做也是很好的提升代码能力的途径。）描述一下，然后我帮你找找看合适的阅读材料。其实我觉得呐你只要双手一摊问你导师要他的代码或许就可以了，虽然程序写的最漂亮的还是那些大师级的程序员。啊对了，光读不练是不行的，如果追求高强度，高效，那就请刷题吧。题主坐拥世界上最好的计算机教育资源，我这里就不献宝了。就把码代码当做写作，我相信题主你可以的！