刚学 C 语言的时候有种上下求索，欲上九天揽月的豪情壮志，结果老师的冷水当头泼下：刚开始写代码会觉得很有意思，等写了一百万行后，其中滋味自己体会吧!
搞程序的累计写到一百万行代码，到底是什么体验呢?
如果一百万是标量的话，我来和大家研究一下这个数据：
假设***的情况，一天 100 行高质量代码，一年 36500，100 / 3.65 = 27 年多。即便从 20 岁开始编码，要到 50 岁左右方可完成。
但实际上关于平均代码量的问题，即便把所有工作日都算上，大概也就是 20 - 30 行的样子;如果仅讨论集中的开发期，高峰也不会超过 200 行。
一百万代码就像找女朋友一样不靠谱。。。。
看完之后小编就头皮一阵发麻，让我写一万行的代码?!are you kidding me?我估计写到 20 万的时候就会突然有个疑问----“咦?我的头发呢?”。
针对累计写到一百万行代码，看看网友们怎么说：
网友 A
我写两千行代码功能都得琢磨个两三天，一百万行真的是好多啊，最多了五年写了也就 20 - 30 万行代码左右，还是有任务在身的情况被逼着写的，让我写一百万行代码，恐怕这辈子得死在电脑前了...
网友 B
我是觉得如果说你一个工作写了一百万行代码，那你在公司的地位应该算资深员工了。如果你一个项目写了一百万行，那你肯定是参与了一个比较大的项目了。
如果你一个类写了一百万行，请问你用的是什么编辑器?如果你一个方法写了一百万行代码的话，请问你有没有被同事打死?
网友 C
据说要从初学者成长为程序员，那个得需要 10 万行代码的积累才可以呢。不过话说回来这样说也很对，毕竟入门阶段嘛，确实需要多打代码才能积累经验。
不过修炼一段时间之后，再注重代码的量，那就不对了。这时候肯定是注重数学还有算法思维，按这样算的话，假如 20 万是修炼门槛，真积累到了一百万行代码，肯定代码质量越来越高了，估计是某个领域的小专家也说不定。
至于真敲了一百万行低质量代码，听哥一句话，还是转行吧。程序员不适合你这种锲而不舍的精神。
网友 D
切，一群渣渣。给你们看看一张网图就知道我连续熬夜写几千行代码是什么状态了。我感觉我快要窒息了，如果时间可以倒流，我希望我不做程序员!!!
网友 E
这简直就是一个伪***啊，哪有什么人能打一百万的代码，从业五六年的程序员，如果按正常工作量的话一天也就一百多行，这五六年估计也就五六万行吧。
如果是外包公司代码量估计翻倍了，那就按五十万行来算。但是谁会那么拼命去奋斗在一线一天一千行的去工作啊。写五六十万行肯定都转行创业了，还继续下去不猝死估计也脱一层皮了。
当一个项目里的代码超过一百万行……
关于代码的量，从初学者成长为程序员，需要代码的积累，而以后数学功底和编程思维的深化更加重要。
一味的追求量并没有任何实际意义，通常，越核心的部分代码量越小，越容易写大量代码的，大概是没什么技术含量的 UI、业务逻辑。而一些部分，用脚本或 DSL 实现可以更精简。写代码和考试一样，做题最多的不一定是成绩***的。
怎么做高质量的代码
打好技术基础
写出高质量代码，并不是搭建空中楼阁，需要有一定的基础。
这里我重点强调与代码质量密切相关的几点：
- 掌握好开发语言，比如做 Android 就必须对 Java 足够熟悉，才能够写出高质量 Java 代码。
- 熟悉开发平台，不同的开发平台，有不同的 API，有不同的工作原理，同样是 Java 代码，在 PC 上写与 Android 上写很多地方不一样。
要去熟悉 Android 编程的一些特性，iOS 编程的一些特性，了解清楚这些，才能写出更加地道的代码，充分发挥各自平台的优势。
- 基础的数据结构与算法，掌握好这些在解决一些特定问题时，可以以更加优雅有效的方式处理。
- 基础的设计原则，无需完全掌握 23 种经典设计模式，只需要了解一些常用的设计原则即可，甚至你也可以只了解什么是低耦合，并在你的代码中坚持实践，也能写出很不错的代码。
代码标准
代码标准在团队合作中尤为重要，谁也不希望一个项目中代码风格各异，看得让人糟心，即便是个人开发者，现在也需要跟各种开源项目打交道。
标准怎么定是一个老生常谈的话题，我经历过很多次的代码标准讨论会议，C++，C#，Java 等等，大家有时会坚持自己的习惯不肯退让。可现如今时代不一样了，Google 等大厂已经为我们制定好了各种标准，就用这些业界标准吧。
想好再写
除非你很清楚你要怎么做，否则我不建议边做边想。你真的搞清楚你要解决的问题是什么了吗?你的方案是否能有效?有没有更优雅简单的方案?
准备怎么设计它，必要的情况下，需要有设计文档，复杂一些的设计需要有同行评审，写代码其实是很简单的事情，前提是你得先想清楚。
代码重构
重构对于代码质量的重要性不言而喻，很难一次把代码写得让自己满意、无可挑剔。
技术债务
很多问题归根结底都是技术债务，这在一些大公司尤为常见。技术债务话题太大，但就代码质量而言，我只想提一下不要因为这些债是前人留下的你就不去管。
现实是没有多少机会让你从一个清爽清新的项目开始做起，你不得不去面对这些，你也没法完全不跟这些所谓的烂代码打交道。
当你负责一个小模块时，除了把它做好之外，也要顺便将与之纠缠在一起的技术债务还掉，因为这些债务最终将是整个团队来共同承担，任何一个人都别想独善其身，如果你还对高质量代码有追求的话。
作为团队的技术负责人，也要顶住压力，鼓励大家勇于做出尝试，引导大家不断改进代码质量，不要总是畏手畏脚，停滞不前，真要背锅也得上，要有担当。
代码审查
我曾经听过一些较高级别的技术分享，竟然还不时听到一些呼吁大家要做代码审查的主题。
我以为在这个级别的技术会议上，不应再讨论代码审查有什么好，为什么要做代码审查之类的问题。同时我接触过相当多所谓国内一线互联网公司，竟有许多是不做代码审查的，这一度让我颇为意外。
这里也不想多谈如何做好代码审查，只是就代码质量这点，不客气地说：没有过代码审查的经历往往很难写出高质量的代码，尤其是在各种追求速度的糙快猛创业公司。
静态检查
很多代码上的问题，都可以通过一些工具来找到，某些场景下，它比人要靠谱得多，至少不会出现某些细节上的遗漏，同时也能有效帮助大家减少代码审查的工作量。
Android 开发中有 Lint，Find bugs，PMD 等优秀静态检查工具可用，通过改进这些工具找出的问题，就能对语法的细节，规范，编程的技巧有更多直观了解。
建议***与持续集成(CI)，代码审查环境配套使用， 每次提交的代码都能自动验证是否通过了工具的代码检查，通过才允许提交。
单元测试
Android 单元测试，一直备受争议，主要还是原生的测试框架不够方便，每跑一次用例需要在模拟器或者真机上运行，效率太低，也不方便在 CI 环境下自动构建单元测试，好在有 Robolectric，能帮我们解决部分问题。
单元测试的一个非常显著的优点是，当你需要修改大量代码时，尽管放心修改，只需要保证单元测试用例通过即可，无需瞻前顾后。
充分自测
有一种说法：程序员最害怕的是他自己写的代码，尤其是准备在众人面前 show 自己的工作成果时，因此在写完代码后，需要至少跑一遍基本的场景，一些简单的异常流。
在把你的工作成果提交给测试或用户前，充分自测是基本的职业素养，不要总想着让测试帮你找问题，随便用几下就 Crash 的东西，你好意思拿给别人吗?
善用开源
并非开源的东西，质量就高，但至少关注度较高，使用人数较多，口碑较好的开源项目，质量是有一定保证的，这其中的道理很简单。
即便存在一些问题，也可以通过提交反馈，不断改进。最重要的是，你自己花时间造的轮子，需要很多精力维护，而充分利用开源项目，能帮助你节省很多时间，把精力专注在最需要你关心的问题上。
从另一个方面来说，开源项目中的一些知名项目，往往是领域内的翘楚所写，学习这些高手的代码，能让你了解到好的代码应该是怎样的，培养出更灵敏的嗅觉，识别代码中的各种味道。
