如何正确高效的学习程序开发_第1页
如何正确高效的学习程序开发_第2页
如何正确高效的学习程序开发_第3页
如何正确高效的学习程序开发_第4页
如何正确高效的学习程序开发_第5页
已阅读5页,还剩9页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、如何正确高效的学习程序开发 程序开发是一种非常类似于学习的一种艺术形式或一种运动的技能,通过用心练习,不断地从别人那里学习,才会编写的更好。以下是学习啦分享给大家的高效的学习程序开发的方法,希望可以帮到你! 1. 主动学习新的技术和非技术两方面的知识 不好的程序员只有在实在不行的时候才开始进行知识学习。良好的程序员会主动学习新的技术知识。 伟大的程序员不仅会自行学习新的技术知识, 而且还会学习非技术方面的知识,对各种知识都有一种开放的心态,而不会象有的人那样固步自封。 具体点说,不好的程序员只有在参加了采用WPF的项目时才开始学习 XAML;良好的程序员一年前就学习了XAML,因为他感觉它很有

2、意思;而伟大的程序员还阅读了WPF应用程序的设计指南、可用性(usability)理论或者什么类似的学习课程,因而他能够制作出卓尔不群的UI。 2. 务实而不教条 严格遵守那些不成文的“编程规则”往往是一种奢侈品,没有多少开发人员能够承受得起。如果你们的规格不是由顶尖的开发人员编写的,也不是在顶尖的开发人员指导下编写的,我就可以向你保证,你可能也承受不起。 我经常能够碰到一些程序员,他们无法或者拒绝做某个任务只是因为完成这个任务的做法通常不为最佳实践所接受。 业务需求很少会受到实现需求所采用的技术的制约;没有人会说,“这我们不应该把这个需求写到规格说明书里,因为要实现这个需求,程序员就不得不写

3、一段很臭的代码。” 在结束的那一天,程序员的任务是要生成一个有效的应用程序,而绝不是要求在技术方面达到十全十美。我可不是在为垃圾代码做辩护。 我想说的是,总会在有些时候,你会写出一些代码,这些代码你永远不会作为范例向别人展示做事的正确方法。 如果只有一种写法,那么这种代码就不是糟糕的代码 但要保证你已穷尽了其它所有可能的方案。 3. 懂得如何通过研究找到答案 通过研究找到答案可不仅仅只是在搜索引擎中键入几个关键字那么简单, 也不是到Stack Overflow或者MSDN forums这类网站发个问题帖。 我就碰到过在搜索引擎里根本搜不到答案的问题,然后我Stack Overflow 或者MS

4、DN forums里发的所有问题贴都没有一个像样的答案,不过我还是解决了我所碰到的问题使得工作得以继续。我不是师 我只是懂得如何找到答案,如何找出问题的根本原因。 有许问题都属于情景式的问题,如果你依赖于搜索引擎或者论坛,就会在各种链接中浪费大量的时间而最终无法得到真正的答案。 要学习如何进行根本原因分析,学习底层系统方面的知识才能够找到其它的线索和解决方案,还要学习如果在对问题有个全局性的认识后才对其进行深入分析。 1. 遵循单一责任原则 在程序员的代码库中,是最重要的形式。可以重用的代码越多,编写的代码就越少,它们的可靠性也就越高。遵循单一责任原则的小功能代码就更有可能被重用。 2.最小化

5、共享状态 你应该最小化函数之间的隐式共享状态,无论它是文件作用域变量还是对象的成员字段,都支持显式的值作为参数。当代码明确了该函数需要什么来产生期望的结果时,代码就变得更容易理解和重用。 这种情况下,你应该优先选择静态无状态变量,而不应该选择对象上的成员变量。 3.本地化的副作用 理想的副作用(例如:控制台打印、日志记录、改变全局状态、文件系统操作等等)应该放在单独的模块中,而不是分散在整个代码中。功能上的副作用常常违反单一责任原则。 4. 优先使用不可变对象 如果一个对象的状态在其构造函数中被设置一次,并且再也不会发生变化,那么调试就变得容易得多了,因为一旦构造正确,它仍然有效。这是减少软件

6、项目复杂性的最简单方法之一。 5.多用接口少用类 使用接口(或在C+中使用模板参数或概念)的函数比在类上运行的函数更容易被重用。 6. 将好的原则应用于模块 寻找机会,将软件项目分解为更小的模块(例如:库和应用程序),以鼓励模块级的重用。模块的一些关键原则是: 依赖最小化 每个项目都应该有一个明确的功能 不要重复 你应该努力使你的项目小而明确。 7. 避免继承 在面向对象编程中,特别是在虚函数中,继承在可重用性方面往往是一个死死穴。我几乎没有地编写或使用那些能覆盖类的库。 8. 在设计和开发过程中进行测试 我并不是测试驱动开发的铁杆拥护者,但随着开始编写代码,测试代码会而然地遵循许多指导原则。

7、它还可以帮助我们更早地发现很多错误。但是,要避免编写无用的测试代码,良好的编码意味着更高级别的测试(例如:集成测试或单元测试以及功能测试),而且在揭示缺陷方面更有效。 9. 优先选择而不是手写标准库 我无法告诉你我多久才能见到一个std:vector 或std:string更好的声明,但这几乎总是浪费时间和精力的。除了显而易见的事实,你正在引入一个bug(参见技巧10),其他程序员不太可能重用你的代码,因为这不是那些被广泛理解、支持和测试的代码。 10. 避免编写新的代码 这是每个程序员都应该遵循的:“The best code is the code that isnt written”(最

8、好的代码是不用被复写的代码)。你拥有的代码行数越多,你的缺陷就越多,发现和修复bug的难度就越大。 在编写一行代码之前,问自己,是否有一个工具、函数或库已经完成了你所需要的工作?你真的需要那个功能而不是调用另一个已经存在的函数吗? 1.不正确的学习动机 在谈及壁垒之前,我想先着重说明学习动机的重要性。不要只是为了编程而学编程,也不要因为听说它很酷,很划得来就来学编程。 你得因为要解决问题而学习编程,你得因为想要自动化和改善生活而学习编程,你得因为想要构建应用程序以造福社会来学习编程。 如果你只是喜欢编程,并希望以此作为职业的话,那么在之后的学习过程中,你可能会有一种强烈的冲动想要放弃。这通常发

9、生在事情变得艰难,学习体验变得痛苦的情况下。这时你会告诉自己,你不喜欢编程了,编程操作不适合你,觉得自己天生就成不了程序员。 这就是为什么你应该考虑围绕着完成项目设置目标的原因。如果你的心里有计划,或者你想要解决更高层次的问题,那么你可以对自己说:“这可能不是一次愉快的经历,但是我真的想要解决这个大问题,所以我一定要克服这个障碍。” 2.不知道从什么技术入手 很多人会问:“我应该先学什么编程语言?”之所以会提出这个问题,是因为他们不知道自己为什么要学习代码。 一旦你下定决心去完成一个特定的项目,那么从什么语言入手这个问题就变成一件很容易的事情: 如果你想构建iOS app,那么你需要学习Obj

10、ective C或Swift。 如果你想构建Android app,那么你需要学习Java。 如果你想构建Web app,那么你需要学习JavaScript。 其实现在我们可以使用JavaScript来创建任何类型的项目无论是简单的web和移动app,还是高级的硬件项目。大多数行业中都有它的身影:音乐、医疗、时装。这种语言非常值得学习。 如果你还是不能确定要选择哪种语言,那么不妨咨询下某个程序员的。只要你确定要构建什么项目,那么他就能很快地为你推荐适合你使用的技术。 另外,知识都是相通的,所以,不要过于拘谨,选择语言这一步骤几乎没什么风险。 3.不能学以致用,以及责备自己 选择好技术堆栈之后,

11、刚开始学习理论总是很轻松的,而且网上也有许许多多和付费的在线课程。 很快大多习者掌握了理论知识,甚至完全可以自己来解释某个代码片段的工作原理。理论只是概念的有限集合。任何人都可以在几天之内记住它,如果她/他真的想的话。那么,关键的问题是什么? 学习者碰到的最大问题在于,实际应用理论来解决问题并编写新代码的时候。这中间的差距实际上就是技能空白。 比如说。你可以阅读大量的技术文章,然后解释得就像一个专业教练。但是,要想实际应用这些理论,就需要大量的实践、斗争和错误你肯定会吞下大量的水! 然而更糟糕的是你开始责备自己。或者认为自己不够聪明,或者觉得自己没有天赋。这其实跟聪明天赋没有关系,你只是需要练

12、习技能的过程: 1.选择一个复杂的项目。理想情况下,这项目得能够激发你的。 2.将这个任务分割成既小又独立的任务。例如,“实现登录页面”是一个很大的任务。解决一个任务不应该超过20行左右的代码。下面这些提示有助于成功做到这一点: 如果你不能解决这个任务,那么进一步将它分割成更小的任务。 一个任务一次不应该使用太多的理论概念。 3.一次专注一项任务,而不是并行解决多任务。不要跳到下一个任务,除非你已经 _测试过当前任务,并确信没有问题。 如果你不这么做,而此时应用程序又出现了问题,那么你就不知道你正在并行解决的多任务中到底是哪个出了问题,寻找起来就麻烦多了。 4.确保自己在开始任务之前知道所有必

13、要的理论知识。有时候,你可能不知道需要学习什么理论,这很正常,所以你需要向他人寻求帮助:程序员朋友,导师,或类似StackOverflow的社区。 5.最后,你解决了任务。在解决任务的过程中,你可能会碰到很多问题,你需要做的就是吸取教训,这也是下面要说的要点: 4.不吸取解决任务中获得的教训 最好的情况是,你解决了任务并且结果证明非常有效。此时,很多人往往就直接开展下一个任务。但是如果你这样做的话,那么你浪费了一个绝佳的学习机会。 希望你能够用以下问题来挑战自我,帮助自己成长: 哪些边界情况会导致我的代码失败?即使现在还没有失败,有哪些应用程序状态可能会破坏代码? 我的代码是否足够整洁?对其他

14、开发人员,甚至是自己而言,代码是否易于理解和改变?因为以后可能需要修复隐藏在这段代码中的问题,或者根据其他产品规格改变代码。 我的方法是最好的吗?有没有其他选项是我可以选择使用的?各个方案的利弊?这任务是否值得用不同的方式解决? 此模块与其他模块是如何交互的?是否会对其他模块造成负面影响?是否容易被其他模块影响? 然而,很多时候,你会进退维谷: 5.你不知道如何处理一个任务 你不知道从哪里开始?你可能会随机地去尝试,或者从其他地方复制一些你自己也不明白的代码。但是,这是没有帮助的。即使你复制来的代码有效也没用。因为当你今后再一次碰到类似的任务,你依然不能解决。 如果你想妥善解决任务,那么首先你得知道你为什么卡壳。下面是一些可能的原因:

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论