万事开头难，无论是科班还是非科班出身的程序员，最难熬的是最初的半年，毕竟从一个门外汉转化成一个真正的程序员最难的就是过渡期。
不管是科班、非科班（自学、培训），刚入行大家心中都是忐忑的，工作时刻处于崩溃边缘，晚上下班回家自顾自的恶补基础知识，好让自己挺过了试用期。
那我们应该无论通过试用期呢？我们知识点可能不能做到面面俱到，但是遇到问题要有自己的解决思路，比如：
即使我们不知道 profiler 这个东西，通过搜索"代码 每一行 时间"也可以很快知道有这样的工具叫做 profiler，并且学会怎么使用；
即使不知道 rand 这个函数怎么加速，通过搜索引擎也可以找到别人写好的现成代码；
……
我们要的是，站在巨人的肩膀上，事半功倍。以下的几点方法技巧，请别客气的全部收下哟~
1.多看看「官方文档」
我们很多的问题和技术细节，其实，只要我们认真将官方文档过一遍，会发觉大部分的问题和认识模糊的地方都消失了。甚至，你还能发现自己之前通过搜索获得的到一些资料，可能是不准确或者已经过时的。官方文档是真正的好东西，因为编写文档的人群，通常就是这些技术或者软件的开发者，他们才是对这些东西最了解的人，因此，他们写的文档质量是很高的，通常也是最新的。
官方文档英文版？？？一个翻译插件就可以搞定了。
文档超过了自己的技术认知水平？？？查资料，了解基础概念。
2.比官方文档更重要的是源代码
看源代码 1）意味着你可以看到以及学习优秀的代码；2）意味着即使源代码有坑，你也会提前在大脑有回路更容易找到问题所在。
看不懂源码意味着不同的几点：
1）你对这个库或者代码的功能不熟悉 (知道某段源码的功能及特点)
2）你不会用 Debug
3）你的算法基础薄弱
4）源码太过混乱
你需要反思自己属于哪一项，然后再对症下药。
上来直接从头看源码学东西一般是不可行的。你需要从上层入侵到下层。先用这段代码才能看懂源码。而不是在上层都不熟悉的基础上开始。任何重复的代码/重复的类似代码。意味着你框架设计有问题，或者开发语言的表达能力不够。
Java 的固定设计模式就是 Java 本身表达能力不够的表现；流程意味着生命周期，即你不仅需要抽象已知的流程；还需要在未提及的点留下一个坑 (函数/接口/钩子)，往往这些坑在以后的需求变更和项目扩展和维护中是救命的点。
日志非常重要，日志环境也非常重要，debug 是基础技能，对应的是开发状态，日志则对应稳定的线上状态，而不能重现的 bug 占整个开发的非常多的时间。所以错误日志记录详细的环境意味着你可以更快的重现这个错误。
3.提升 debug 的能力
从高层往底层找错
科学方法
很多新手遇到程序执行结果不对（尤其是图形程序员），先认为是机器毛病（浮点精度、硬件故障），然后认为是驱动有错，再认为是系统有错，最后才开始排查自己的程序。其实 99% 的情况下是自己程序有错，然后那 1% 里面的 99% 是系统有 bug，再接着那 1% 里的 99% 是驱动有 bug，最后到硬件问题，已经微乎其微了。
应该从高层往底层查，而不是反过来。debug一般来说是知道现象，但原因未知。这一点和很多自然科学的情况一样，所以完全也可以用科学的方法来：提假说->根据假说做出预言->做实验肯定或否定预言。
对应于 debug，那就是假设是某个地方有问题，那么推断它一定会导致除了你看到的现象之外的其他现象，运行程序看你的推断是否成立。掌握这个方法后 debug 不在变成瞎找瞎试，而是有迹可循有系统可依赖的方法。
4.重构是程序员的主力技能
好多设计模式不是提前就设计出来的，而是重构出来的。很多情况是我们在做设计的时候考虑不到的，是写代码时也考虑不到的，只有在项目上线后，客户使用过程中才会反应出来，这个时候就需要对项目进行扩展，版本升级，这时就体现老程序员实力的时候了，就是根据已有的情形，结合新的客户需求，使用合适的设计模式，使得代码能够优雅的扩展。
5.先用 profiler 调查
先用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 每一行修改都确认清楚是为什么要这样做，回想一下整个功能是怎么实现的、BUG 是怎么解决的。日子久了就会感觉到自己的每次提交越来越靠谱了，同时，版本库记录里面诸如「去掉一行注释」、「去掉一行调试代码」等等也就不会出现了。
16.避免踩坑
1）不符合 kpi 的需求不接，一个资深码农是懂得刷选需求的；
2） 一定要搞好监控和异常主动发现，监控不是那种让 sa 看看的花架子，资深码农懂得如何刷选监控中的有效信息并指导 bug 主动修复；
3）对上下游做到代码级别掌握，这样在甩锅上可以立于不败之地，再牛逼点的，可以做到指导上下游开发的方向，让上下游来配合自己完成开发目标；
4）搞好自动化测试和集成测试，很多老鸟的自动化测试写的非常有才，场景覆盖全，业务分析清晰，看一份牛逼的代码，推荐从集成测试和自动测试入手。
17.心态摆正
企业的程序员是要解决实际客户的问题，面对实际的问题要能解决并且还要不留下后遗症，要学会任务管理，先做好该做的事。
遇到问题先不要慌，大胆假设，小心求证，认真干；工作之余，给自己充充电，手不释卷，方得成长。
学姐有话说
把觉得不靠谱的需求放到最后做，很有可能到时候需求就变了~
如果担心坐太久，正确的做法是多！喝！水！
不要相信产品经理不改需求这种鬼话！
一定要写注释！！
用谷歌不用百度
作为一名（准）软件开发工程师，我们都应该明白活到老学到老，时刻与不断发展的框架、标准和范式保持同步。同时，还要能活学活用，在工作中使用最合适的工具，以提高工作效率。
本文来源于网络整理，仅作分享，侵删
883
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
