码迷,mamicode.com
首页 > 其他好文 > 详细

程序员16个建议

时间:2017-12-15 18:16:30      阅读:158      评论:0      收藏:0      [点我收藏+]

标签:集成   崩溃   自动   搜索   消失   def   而不是   修改   项目上线   

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 调查 才有脸谈优化

如果做.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/

程序员16个建议

标签:集成   崩溃   自动   搜索   消失   def   而不是   修改   项目上线   

原文地址:http://www.cnblogs.com/yorkyang/p/8044319.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!