1.多看看「官方文档」程序员
咱们不少的问题和技术细节，其实，只要咱们认真将官方文档过一遍，会发觉大部分的问题和认识模糊的地方都消失了。甚至，你还能发现本身以前经过搜索得到的到一些资料，多是不许确或者已通过时的。官方文档是真正的好东西，由于编写文档的人群，一般就是这些技术或者软件的开发者，他们才是对这些东西最了解的人，所以，他们写的文档质量是很高的，一般也是最新的。算法
官方文档的不足的地方，大概是中文版本很少，看起来可能会比较吃力。不过，请相信我，下载一个翻译辅助软件，慢慢看仍是能够的。另外一方面，就是这些文档编写者，一般是技术界大牛，他们编写文档有时候是基于他们本身的技术认知水平，跳过了不少基础概念，也增长了阅读难度。不过，这个咱们也能够经过多查资料，慢慢看来解决，而且一般会带来额外的学习收获。设计模式
2.比官方文档更重要的是源代码markdown
看源代码 1）意味着你能够看到以及学习优秀的代码；2）意味着即便源代码有坑，你也会提早在大脑有回路更容易找到问题所在。框架
看不懂源码意味着不一样的几点：函数
1）你对这个库或者代码的功能不熟悉 (知道某段源码的功能及特色)工具
2）你不会用 Debugoop
3）你的算法基础薄弱 性能
4）源码太过混乱单元测试
你须要反思本身属于哪一项。针对其中某一类下药上来直接从头看源码学东西通常是不可行的。你须要从上层入侵到下层。先用这段代码才能看懂源码。而不是在上层都不熟悉的基础上开始。任何重复的代码/重复的相似代码。意味着你框架设计有问题，或者开发语言的表达能力不够。
Java 的固定设计模式就是 Java 自己表达能力不够的表现。流程意味着生命周期，即你不只须要抽象已知的流程。还须要在未说起的点留下一个坑 (函数/接口/钩子)。每每这些坑在之后的需求变动和项目扩展和维护中是救命的点。日志很是重要，日志环境也很是重要，debug 是基础技能，对应的是开发状态。日志则对应稳定的线上状态。而不能重现的 bug 占整个开发的很是多的时间。因此错误日志记录详细的环境意味着你能够更快的重现这个错误。
3.提高 debug 的能力
从高层往底层找错
科学方法
不少新手遇到程序执行结果不对（尤为是图形程序员），先认为是机器毛病（浮点精度、硬件故障），而后认为是驱动有错，再认为是系统有错，最后才开始排查本身的程序。其实 99% 的状况下是本身程序有错，而后那 1% 里面的 99% 是系统有 bug，再接着那 1% 里的 99% 是驱动有 bug，最后到硬件问题，已经微乎其微了。
应该从高层往底层查，而不是反过来。debug 通常来讲是知道现象，但缘由未知。这一点和不少天然科学的状况同样，因此彻底也能够用科学的方法来：提假说->根据假说作出预言->作实验确定或否认预言。对应于 debug，那就是假设是某个地方有问题，那么推断它必定会致使除了你看到的现象以外的其余现象，运行程序看你的推断是否成立。掌握这个方法后 debug 不在变成瞎找瞎试，而是有迹可循有系统可依赖的方法。
4.重构是程序员的主力技能
好多设计模式不是提早就设计出来的，而是重构出来的。不少状况是咱们在作设计的时候考虑不到的，是写代码时也考虑不到的，只有在项目上线后，客户使用过程当中才会反应出来，这个时候就须要对项目进行扩展，版本升级，这时就体现老程序员实力的时候了，就是根据已有的情形，结合新的客户需求，使用合适的设计模式，使得代码可以优雅的扩展。
5.先用 profiler 调查 才有脸谈优化
若是作.net 代码的优化，也有对应的 Profiler 工具，这个能够帮咱们快速的定位瓶颈在哪里。找到了瓶颈才有接下来的优化工做。
6.一行代码一个兵
这里说的一个关于函数的规范问题，有一种说法是一个函数的内容不该该超过 7 行，若是超过 7 行，那么确定是把多个 Function 合并到一个函数中的，应该拆分红多个函数。这个要求可能有点高，很难作到。不过上百行，上千行的函数那是不该该的，必须拆分！
7. 最好的工具是纸笔 其次好的是 markdown
纸和笔只适用于在 Face 2 Face 的交流过程当中，交流后顶多拍照留存，根本没法创建有效的知识库，之后想到以前的讨论，怎么检索？怎么修改？。写 Wiki 才是王道，Markdown 只是一种写 Wiki 的方式罢了。
8.宁肯多算一周 不可少估一天
程序员在估计工时的时候老是太乐观。随便开口就是一个小时就能搞定，半天就能作完。彻底没有想到该修改对其余模块的影响。一个修改后的单元测试，可接受测试，UAT 环境测试，再到上线，不少地方都得花时间的。一旦某个测试不经过，而后又得调试，修改，再进行单元测试，可接受测试~~~~，好吧，谁能保证每次修改都是一次经过呢。
9.安装一个调试器（OllyDBG 或者 WinDBG） 并设置为实时调试器
一但有程序崩溃就拦下来，除了能够抢救一些数据之外，还能够顺手分析下崩溃的缘由，找找代码中的坏味道，检讨下本身的代码中哪些设计可能会致使一样的问题。
10.编码不要畏惧变化 要拥抱变化
Embace Change 常被许多新手、XPers 和极端主义者看成老要不停改代码（code and fix）、重构的一个伟大借口——拥抱变化，其实真实缘由是由于他们的经验不足，分析设计能力弱，预见、预构能力差，致使需求和代码不稳定。
11.注释是稍差的文档 更好的是清晰的命名 让代码讲本身的故事
结构清晰、可读性好的代码固然很重要。然而对于许多复杂系统软件，经常只有代码注释还不够，更好的文档实际上是可视化的程序模型，其中包括各类清晰的命名。
12.在动手写代码前先经过循环不变式证实程序正确性
对待 Bug 毫不能想固然, 实际工程中, 当你修正 1 个 Bug, 颇有可能会引发另外一系列 Bug 的产生, 类比于雪崩效应. 再优秀的程序也会有 Bug, Bug 埋藏越久越是致命的, 这就是为何要先证实正确性以减小潜在 Bug 的出现的可能, 一样地, 在编码-调试-编码的过程中修正 Bug 极可能会致使新 Bug 产生, 导致开发效率急剧降低. 另外性能也算是 feature. 不达标也算是 Bug. 二八原则在性能上一样适用, 20% 的代码决定着程序的整体性能 (Profile 的时候要记住)。
13.尽可能利用语言特性来保障代码可靠 避免让本身产生过大的心智负担
例如养成用 const 的习惯，养成多下断言的习惯。这个小 trick 可让不少新手程序员快速摆脱「总感受本身写的东西哪儿有问题」的感受。
14.争取不写超过 40 行的程序 若是超过 20 行 准备把一些逻辑抽出来当函数
为什么 20 行，为了一些 quick and dirty 的修改作准备；
这样 quick and dirty 以后一样，避免有不少 prop 的 class；
避免不了的话应该申请加工资相对于 forloop，用 index 作递归会稍微易读一些泛化是好的，只要泛化以后你写的测试不超过百行便可有时候，你发现相对于写库，不如写 boilerplate 和 snippets 方便 curry 通常只为了一件事情，就是为了调整参数次序，让 default par 在 一些没有 default value 的 par 前面；
其余时候主要为了填一些语言设计很差的坑。
15.提交代码以前 diff 回顾一下本身的全部修改
提交以前，用 diff 每一行修改都确认清楚是为何要这样作，回想一下整个功能是怎么实现的、BUG 是怎么解决的。日子久了就会感受到本身的每次提交愈来愈靠谱了，同时，版本库记录里面诸如「去掉一行注释」、「去掉一行调试代码」等等也就不会出现了。
16.避免踩坑
1）不符合 kpi 的需求不接，一个资深码农是懂得刷选需求的
2） 必定要搞好监控和异常主动发现，监控不是那种让 sa 看看的花架子，资深码农懂得如何刷选监控中的有效信息并指导 bug 主动修复
3）对上下游作到代码级别掌握，这样在甩锅上能够立于不败之地，再牛逼点的，能够作到指导上下游开发的方向，让上下游来配合本身完成开发目标
4）搞好自动化测试和集成测试，不少老鸟的自动化测试写的很是有才，场景覆盖全，业务分析清晰，看一份牛逼的代码，推荐从集成测试和自动测试入手
转自：http://blog.csdn.net/egefcxzo3ha1x4/article/details/78412866
http://blog.didispace.com/cxy-wsm-zml-9/