10个真言,希望对进阶中的程序朋友有所帮助。
1.橡皮鸭调试法
不知道各位有没有这样的经历,当你正在给别人描述问题的时候,突然灵机一动想到了解决方案?
这种情况的产生是有科学依据的。高谈阔论能让我们的大脑重新有条理地组织问题。在这种情况下,你的聊天对象就是“橡皮鸭”。团队中的每个人都应该积极主动乐意地成为彼此的“团队”。有时候,如果你幸运的话,你的“橡皮鸭”搞不好还能给出有效的建议呢。
2.快速反馈信息
一旦写好代码就要尽快得到反馈。当收到大量的Pull请求,不妨做些细微的改动,然后立马打开PR,讨论设计和代码。
和你的“橡皮鸭”交流一下,请他们提点建议。要知道,迭代原型可远比纠正成品要节约成本。
有的团队结构,最初可能并不要求写代码。因为实体模型、白板设计等等,这些成本都比一下子删改上千行代码的成本要低。
3.搞定端至端
当我们在解决问题和完成功能时,很容易深入到细节问题的研究。这里有一个好方法,能让我们尽快搞定端至端。
例如,假设我需要在网页上设置一个功能,能在用户点击之后做一些复杂运算并把结果存储到服务器中。有些童鞋可能想着想着就先去研究这个运算方式了。
我们的做法是,先为用户的操作设置事件处理程序,用一些固定的值来模拟计算,然后调用API向服务器请求数据。这样一来,我们就没必要先考虑每一个具体细节,可以直接端至端地测试系统。
不要发明你自己的框架
不夸张地讲,已经有几千个框架存在了,大多数还是开源的。很多框架都是极完美的解决方案,并已被用到成千的系统中。我们只要关注最新的流行的框架,至少表 面上要熟悉一下。一个最成功的、也是被广泛使用的例子是Struts框架,这个开源的web框架是建立web系统的极佳选择,不要试图构造你自己的 Struts版本,会累死的。但你必须记住第2条(译注:原文是“第3条”,显然不对)戒律 —— 不要把简单事情复杂化。如果你要开发的系统只有3个界面,就不要用Struts. 对于这样一个系统,没有足够的需要被“控制”的东西(译注:Struts将界面做MVC划分,C即controller,所以作者说there isn’t much “controlling” required)。
4.有良好的开发环境
总是使用源代码控制——尤其我建议你学习git,因为它会教你概念。始终备份工作。所有这一切将防止你在你不使用它们时可能会遭遇的极度灰心丧气,从而失去工作。
5.秉持开放的态度
阅读你尊敬的程序员的Twitter Feed和博客。(如果你想的话,可以看看我的twitter feed——大多是程序员。)RSS阅读器,例如Ruby Inside或者老式的Planets,都可以是很好的新闻来源,因为它们会添加突出的新程序员,而不必你去搜索。选择一些你通常不会阅读的主题的博客,并订阅它们。
6.阅读优秀的代码
想想你喜欢的一些软件,然后看看软件的源代码。有什么问题?你如何从中学习,或者更好的是,你可以怎么改善这个软件?有很多好代码的源,但GitHub必然是最好的之一。GitHub博客上的GitHub Rebase系列列出了一些值得注意的新项目,如果你想要了解更多细节的话。
适当离开电脑
有时候在调试时,console.logging无处不在,最好的方法就是测试代码。也有的时候,你绞尽脑汁呕心沥血地想要解决一些复杂的设计和问题而不得其法,那么你最好先暂时离开一会。
虽然这听上去有点不可思议,但是有的时候,的确是在其他地方想到了问题的症结所在。
我的朋友,她也是软件工程师,曾告诉我,当她睡觉的时候常常会有各种奇思妙想(有时闭上眼睛天马行空,有时想到各种方案纷至沓来)。打个盹、散散步、上个厕所……都可以,总之适当离开电脑。
给自己写的每个代码集都贴上标签(how,what)
我发现区分程序员优劣的一条很明显的分割线就是,是否有这个热情去知道“what and how”。有的程序员对于自己的代码是如何执行的以及执行结果等知道得一清二楚。我也理解有时候因为时间紧迫,我们不得不在只知道这些代码可以完成工作的 情况下就立刻进行下一步。虽然这对解决问题而言,似乎是另一个方向的话题,但是作为一个程序员,我们应该尽可能地深入研究问题以达到最高水平。相信我,随 着时间的推移,你会在不知不觉中养成这个好习惯,然后受益无穷。。
通过帮助他人从而学到更多
可能我们中的大多数人只有在自己需要帮助的时候才会上论坛和群。有一条区别程序员是否优秀的分割线就是,优秀者经常会去这些地方以帮助他人。而 且他们在帮助别人的同时,自己也能学到很多东西。如果是在一个团队中,也应该互相帮助。相信我,理解别人的问题背景、研究并提出解决方案会让你学到的更 多,成长的更快。
转载自网络 不用于商业宣传 版权归原作者所有,侵权删。