送给新手 22 个编程经验.docxVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
送给新手 22 个编程经验

送给新手的 22 个编程经验开发1. 从小事做起,然后再扩展 无论是创建一个新的系统,还是在现有的系统中添加新的功能,我总是从一个简单到几乎没有任何所需功能的版本开始,然后再一步一步地解决问题,直到满意为止。我从来没有妄想过能够一步登天。相反,我一边开发一边学习,同时新掌握的信息还可以用于解决方案中。 我很喜欢 John Gall 的这句话:“复杂系统总是源于简单系统的演化。”2. 一次只做一件事 当我们在开发时,碰到测试失败和功能无效的情况,如果你一次只研究一个问题,那将会更容易找到问题的关键。换言之,就是使用短迭代。必须确保这个问题解决之后,再转移到另一个问题上。这适用于向下提交。如果在你添加新功能之前需要先重构代码,那么先提交重构,然后再添加新的功能。 3. 尽早地添加日志和错误处理 在开发新系统时,我做的第一件事就是添加日志和错误处理,因为这两者从一开始就非常有用。对系统来说它比一大把代码更有用,你需要一些了解程序状态的方法。如果系统不能照常工作,那么你就需要知道程序中发生了什么——这是日志的作用。错误处理也是如此——错误和异常越早处理越好。 4. 每一行新代码必须至少执行一次 在你真正完成一个功能之前,你必须对它进行测试。不然,你怎么知道它是不是按照你的想法在执行呢?通常情况下,最好的方法是通过自动测试,但并非总是如此。不过,不管怎么说,每一行新代码必须至少执行一次。 一般,我们想触发某种条件很难。但幸运的是,我们可以作弊。例如,数据的错误处理可以通过临时拼写错一个列名来触发。或者,一个if语句可以暂时颠倒过来(从 if error 变成 if not error),这样来触发那些平时很难触发的条件,这样只是为了确定代码是否正常运行和它会出现什么结果。有时,我发现有一些行代码永远都不会被运行。当我们做代码检查是它看起来没有什么问题,但就是不工作。你要避免这样的尴尬状况,如果你想你的每一行新代码都会被执行。 5. 在整体测试之前先进行模块测试 先进行部分模块测试可以节省时间。通常说来,我们在整合不同的模块时也会出现问题,例如模块之间的接口不匹配。但是如果我们能够信任各个组件的话,那么跟踪集成问题就会变得简单得多。 6. 所有事情所花费的时间总是比你预期的要长 特别是在编程中,即使一切进展顺利,我们也很难对功能所需的时间做出正确的预算。并且,开发软件时碰到各种意想不到的问题是非常常见的。一个简单的合并操作会导致一系列小bug,一次框架升级意味着一些函数必须改变或者一些API不按照你想象的那样工作。Hofstadter Law( 霍夫施塔特定律)其实道出了真谛:做事所花费的时间总是比你预期的要长,即使你在预期中已经考虑了 Hofstadter Law( 霍夫施塔特定律)。7. 先了解现有的代码 大多数的编码都需要以某种方式改变现有的代码。即使是新功能,也需要适应现有的程序。所以,在你加进去新的内容前,首先需要了解当前的解决方案。否则,你一不小心就很有可能会打破现有的功能。这意味着,阅读代码和编写代码都是必要的技能。这也是为什么看似微小的变化仍可能需要很长时间才能解决的原因之一,因为你首先必须了解上下文。 8. 阅读和运行代码 幸运的是,对于理解代码,我们有两种互补的方法。你可以阅读代码,也可以运行代码。运行代码的确是个非常棒的好方法。所以,请确保充分利用这两种方法。 故障排除 9. Bug 总是难免的 我不喜欢那些宣称软件开发可以“一蹴而就”的高谈阔论。不论你再怎么努力,bug总是难免的(BUG的定义基本上是:“我们没有想到”)。最好能够做成可以快速故障排除、修复bug和部署修复的系统。 10. 解决故障报告每个开发人员都应该花时间去处理来自客户的故障报告,并修复bug。这能让你更好地理解客户的意图,明白如何使用系统,知道排除故障的难易程度,了解系统的设计情况。这也是为自己的开发成果负责的好方法。不要错过这些好处。 11. 重现问题 修复bug的第一步就是重现问题。然后你得确保修复之后,问题能够彻彻底底地消失。这样一个简单的规则,可以确保你不会误将非问题当作是问题,并确保解决方案真的能够奏效。 12. 修复已知错误,然后再看看有没有其他不对的地方 有时候,可能同时存在着几个不同的问题。它们之间的互相作用,可能会让你毫无头绪,束手无策。不要纠结于搞清楚发生了什么,先去解决所有已知的问题,然后再看看还有什么不对的地方。 13. 没有巧合 在测试和故障排除时,不要相信会出现什么巧合。就像你改变了定时器的值,那么就会改变系统重启的频率。所以一切都并非是巧合。添加新功能,另一个不相干的功能变慢了?这绝对不是巧合。相反,是你应该仔细调查的内容。14. 关联时间戳 在故障排除时,事件的时间戳

文档评论(0)

317960162 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档