姓名:王明骞 学号:16050510061
转载自:http://mp.weixin.qq.com/s/ 9PsM9CNdhWwRjNaJXCXeXw 有删改
[嵌牛导读]
本文核心并不是程序优化的具体技巧，而是拿到一个问题如何思考和利用工具的通用方法。比如即使我们不知道 profiler 这个东西，通过搜索"代码 每一行 时间"也可以很快知道有这样的工具叫做 profiler，并且学会怎么使用。即使不知道 rand 这个函数怎么加速，通过搜索引擎也可以找到别人写好的现成代码。另一方面是发现瓶颈之后也不要着急自己修复，如果不是特别一目了然的话，先看看别人是怎么做的。站在巨人的肩膀上，事半功倍。
[嵌牛鼻子]
安装一个调试器，编程不畏惧变化，清晰的命名，通过循环证明程序的正确性，用语言特性保障代码可靠，争取不写超过40行的程序，difd回顾自己所有的修改，避免踩坑
[嵌牛提问]
如何使新手程序员能写出更好的代码，达到事半功倍的效果？
[嵌牛正文]
安装一个调试器（OllyDBG 或 者 WinDBG） 并设置为实时调试器
一但有程序崩溃就拦下来，除了可以抢救一些数据以外，还可以顺手分析下崩溃的原因，找找代码中的坏味道，反省下自己的代码中哪些设计可能会导致同样的问题。
编码不要畏惧变化 要拥抱变化
Embace Change 常被许多新手、XPers 和极端主义者当作老要不停改代码（code and fix）、重构的一个伟大借口——拥抱变化，其实真实原因是因为他们的经验不足，分析设计能力弱，预见、预构能力差，导致需求和代码不稳定。
注释是稍差的文档 更好的是 清晰的命名 让代码讲自己的故事
结构清晰、可读性好的代码当然很重要。然而对于许多复杂系统软件，常常只有代码注释还不够，更好的文档其实是可视化的程序模型，其中包括各种清晰的命名。
在动手写代码前先通过循环 不变式证明程序正确性
对待 Bug 绝不能想当然, 实际工程中, 当你修正 1 个 Bug, 很有可能会引起另一系列 Bug 的产生, 类比于雪崩效应. 再优秀的程序也会有 Bug, Bug 埋藏越久越是致命的, 这就是为什么要先证明正确性以减少潜在 Bug 的出现的可能, 同样地, 在编码-调试-编码的过程当中修正 Bug 很可能会导致新 Bug 产生, 致使开发效率急剧下降. 另外性能也算是 feature. 不达标也算是 Bug. 二八原则在性能上同样适用, 20% 的代码决定着程序的总体性能 (Profile 的时候要记住)。
尽量利用语言特性来保障代码可靠 避免让自己产生过大的心智负担
例如养成用 const 的习惯，养成多下断言的习惯。这个小 trick 可以让很多新手程序员快速摆脱「总感觉自己写的东西哪儿有问题」的感觉。
争取不写超过 40 行的程序 如果超过 20 行准备把一些逻辑抽出来当函数
为何 20 行，为了一些 quick and dirty 的修改做准备；这样 quick and dirty 之后同样，避免有很多 prop 的 class；避免不了的话应该申请加工资相对于 forloop，用 index 做递归会稍微易读一些泛化是好的，只要泛化之后你写的测试不超过百行即可有时候，你发现相对于写库，不如写 boilerplate 和 snippets 方便 curry 一般只为了一件事情，就是为了调整参数次序，让 default par 在 一些没有 default value 的 par 前面；其他时候主要为了填一些语言设计不好的坑。
提交代码之前 diff 回顾一下自己的所有修改
提交之前，用 diff 每一行修改都确认清楚是为什么要这样做，回想一下整个功能是怎么实现的、BUG 是怎么解决的。日子久了就会感觉到自己的每次提交越来越靠谱了，同时，版本库记录里面诸如「去掉一行注释」、「去掉一行调试代码」等等也就不会出现了。
避免踩坑
1）不符合 kpi 的需求不接，一个资深码农是 懂得刷选需求的
2） 一定要搞好监控和异常主动发现，监控 不是那种让 sa 看看的花架子，资深码 农懂得如何刷选监控中的有效信息并指 导 bug 主动修复
3）对上下游做到代码级别掌握，这样在甩 锅上可以立于不败之地，再牛逼点的， 可以做到指导上下游开发的方向，让上 下游来配合自己完成开发目标
4）搞好自动化测试和集成测试，很多老鸟 的自动化测试写的非常有才，场景覆盖 全，业务分析清晰，看一份牛逼的代 码，推荐从集成测试和自动测试入手
