最牛B的编码套路

最近,我大量阅读了Steve Yegge的文章。其中有一篇叫“Practicing Programming”(练习编程),写成于2005年,读后令我惊讶不已:

与你所相信的恰恰相反,单纯地每天埋头于工作并不能算是真正意义上的锻炼——参加会议并不能锻炼你的人际交往能力;回复邮件并不能提高你的打字水平。你必须定期留出时间,集中锻炼,这样才能把事情做得更好。

我认识很多杰出的程序员——这是在亚马逊工作最好的额外“福利”之一。如果仔细观察他们,你会发现他们时时都在锻炼。他们已经很优秀了,但他们仍然不忘锻炼。他们锻炼的方法林林总总,而我在这篇文章中只会介绍其中的几种。

据我了解,这些杰出程序员之所以如此成功,就是因为他们一直在锻炼。完美的身材要靠定期的锻炼才能获得,而且必须坚持锻炼才能保持,否则身材就会走形。对于编程和软件工程来说,道理是一样的。

这是一个重要的区别——我每天都开车去上班,但我的驾驶水平远远不如专业车手;类似的情况,天天编程可能并不足以使你成为一名专业的程序员。那么,什么才能把一个普通人变成一名专业车手或者专业程序员呢?你需要锻炼什么呢?

答案就在《科学美国人》的一篇名为“The Expert Mind”(专家思维)的文章里:

爱立信提出,重要的并不是经验本身,而是“努力的学习”,也就是要不断地挑战自身能力之外的东西。一些狂热的爱好者花费了大量的时间去下棋、打高尔夫球或者玩乐器,但他们可能始终停留在业余水平上,而一个训练有素的学生却可以在相对较短的时间里超越他们,原因就在这里。值得注意的是,在提高水平方面,花费在下棋上的大量时间(即使参加各种比赛)似乎还是比不过专门的训练来得更为有效。训练的主要价值在于发现弱点,并有针对性地进行提高。

“努力的学习”意味着,要常常去处理那些刚好在你能力极限上的问题,也就是那些对你来说有很大可能失败的事情。如果不经历一些失败的话,你可能就不会成长。你必须不断地挑战自我,超越自己的极限。

那样的挑战有时会在工作中碰到,但也未必。将锻炼从职业工作中分离出来,这在编程领域常被人称为“编码套路”(Code Kata)。

Code Kata的概念是由David Thomas提出的,他是《程序员修炼之道:从小工到专家》的作者之一。这个概念主要指的是,针对某一种特定技术或技能进行重复性的练习,从而将其熟练掌握。——译者注

所谓套路,就是一系列的招式。这个概念借鉴于武术。

如果你想要看一些编码套路的例子(也就是努力学习和磨练编程技能的方法),SteveYegge的文章里倒是提出了一些不错的建议。他把它们称作为“实践演练”:

1.     写一份自己的简历。把自己所有的相关技能都罗列出来,然后把那些在100年后还用得到的标出来。给每个技能打分,满分为10分。

2.     罗列出你所景仰的程序员。尽量包括那些与你一起工作的人,因为你会在工作中从他们身上获取一些技能。记录下他们身上的1 ~ 2个闪光点,也就是你希望自己有所提高的方面。

3.     查看维基百科上的“计算机科学”栏目,找到“计算机领域先驱者”这个分类,从这个列表中挑选一个人,阅读他的事迹,并且在阅读时打开任何你感兴趣的链接。

4.     花20分钟通读别人的代码。读出色的代码和读糟糕的代码都是有益的,两者都要读,轮流切换。如果你无法感觉出它们之间的区别,可以求助于一位你尊敬的程序员,让他给你展示一下什么是出色的代码、什么是糟糕的代码。把你读过的代码给别人也看看,问问他们的看法。

5.     罗列出你最喜欢的10个编程工具——那些你觉得你用得最多、非有不行的工具。随机挑选其中的一个工具,花一个小时去阅读它的文档。在这一个小时里,努力去学习这个工具的某个你不曾意识到的新功能,或者发现某种新的使用方法。

6.     想一想,除了编程之外你最擅长什么事情?再想一想,你是通过怎样的锻炼才变得如此熟练和专业的?这对于你的编程工作又有什么启发呢?(怎么把这些经验应用到编程方面?)

7.     拿出一叠简历,并和一组面试官在同一个房间里待上一个小时。确保每份简历都至少被3个面试官看过,并且要给出1 ~ 3分的评分。针对那些不同面试官评判大相径庭的简历展开讨论。

8.     参与一个电话面试。事后写下你的反馈,抛出你的观点,然后与主持电话面试的人聊一聊,看看你们是否达成了一致的结论。

9.     进行一次技术面试,并且被面试的人应该是某个你不太了解的领域里的专家。让他假定听众在该领域里一无所知,因此请他从最基础的讲起。努力去理解他所说的,必要时问一些问题。

10.   有机会参与别人的技术面试。期间,你只是认真地听、认真地学。在应聘者努力解决技术问题的同时,你也要在自己脑子里尝试解决这些问题。

11.   找到一个能和你交换实际问题的人,每隔一周,相互交流编程问题。花10 ~ 15分钟来尝试解决这些问题,再用10 ~ 15分钟进行讨论(无论能否解决)。

12.   当你听到任何你一时之间也无法解决的面试问题时,赶紧回到你的座位上,把这个问题用电子邮件发给自己,以留作日后的提醒。在那一周里找出点时间,用自己最喜欢的编程语言来解决它。

我之所以喜欢Steve开出的这个清单,是因为它看上去很全面。有些程序员一想到“锻炼”,总认为就是一些编码上的难题。但在我看来,编程更在于人,而不是代码。因此,通过解决世上所有的、并且晦涩的编程面试题目,在提高你的个人能力方面,这种方法是有局限的。

关于“努力的学习”,我也很喜欢Peter Norvig在“Teach Yourself Programming in TenYears”(花10年时间自学编程)一文中提出的诸多建议:

1. 与别的程序员交流。读别人的代码。这比任何书籍或培训课程都更重要。

2. 动手写程序!最好的学习方法就是边做边学。

3. 在本科或研究生的课程中学习编程课程。

4. 找一些项目来做,并且需要与其他程序员形成团队来合作。在项目的进行过程中,学会辨别最出色的程序员以及最糟糕的程序员。

5. 在项目中跟随别的程序员一起工作,了解如何维护那些不是你写的代码,并且学习如何写出利于他人维护的代码。

6. 学习多种不同的编程语言,特别是那些与你现在所熟悉的语言有着不同的世界观和编程模型的。

7. 了解硬件对软件的影响。知道你的电脑执行一条指令需要多少时间,从内存中取出一个字(在有缓存或没缓存的情况下)需要多少时间,在以太网(或者因特网)上传输数据需要多少时间,从磁盘中读取连续的数据或者在磁盘上跳转到另一个位置需要多少时间,等等。

你还可以从Dave Thomas的21种实用的编码套路中获取灵感(CodeKata.com),或者你更愿意加入一个你家当地的“编程武馆”(CodingDojo.org)。

对于“努力的学习”,我无法像Steve,Peter或者Dave那样提供一个长长的建议列表。我远不如他们有耐心。实际上,在我看来,“编程套路”只需两个招式:

1.      写博客。我在2004年初创办了CodingHorror.com博客,作为我自己努力学习的一种形式。它在一开始很不起眼,到后来成为我职业生涯中做过的最重要的一件事。所以,你也应该写博客。最后“闻达于天下”的人,往往就是那些能够有效书写和沟通的人。他们的声音最响亮,是他们在制定游戏规则,并且引领世界的潮流。

2.      积极参与著名的开源项目。所有的高谈阔论听起来都很好,但是,你是一个大话王还是一名实干家呢?别光说不练,这个非常重要,因为人们会用你的行动来衡量你,而不是你的言论。努力在公众面前留下些实实在在有用的东西吧,到时候你就可以说,“我在那个项目中出过力。”

当你能编写精彩的代码、并且能用精彩的言辞向世人解释那些代码时,到那时候,我会觉得你已经掌握了最牛的编码套路!

时间: 2024-10-30 21:11:15

最牛B的编码套路的相关文章

这是我看过的最牛的编码套路,给大家分享下

最近,我大量阅读了Steve Yegge的文章.其中有一篇叫"Practicing Programming"(练习编程),写成于2005年,读后令我惊讶不已: 与你所相信的恰恰相反,单纯地每天埋头于工作并不能算是真正意义上的锻炼--参加会议并不能锻炼你的人际交往能力:回复邮件并不能提高你的打字水平.你必须定期留出时间,集中锻炼,这样才能把事情做得更好. 我认识很多杰出的程序员--这是在亚马逊工作最好的额外"福利"之一.如果仔细观察他们,你会发现他们时时都在锻炼.他们

经常去处理刚好在你能力极限上的问题

 最近,我大量阅读了Steve Yegge的文章.其中有一篇叫"Practicing Programming"(练习编程),写成于2005年,读后令我惊讶不已: 与你所相信的恰恰相反,单纯地每天埋头于工作并不能算是真正意义上的锻炼--参加会议并不能锻炼你的人际交往能力:回复邮件并不能提高你的打字水平.你必须定期留出时间,集中锻炼,这样才能把事情做得更好. 我认识很多杰出的程序员--这是在亚马逊工作最好的额外"福利"之一.如果仔细观察他们,你会发现他们时时都在锻炼.他

把base64编码的后三位+/=换成_-~ 可以吗 求牛人庇护?????????????

问题描述 把base64编码的后三位+/=换成_-~ 可以吗 求牛人庇护????????????? 把base64编码的后三位+/=换成_-~ 可以吗 ?????????????????????????????????? 解决方案 不过你可以编解码之前先自己做转换 解决方案二: 不可以,base64只认识+/+,不认识_-~

FDD和TDD都弱爆了,看看最牛的NDD!

  话说FDD和TDD两兄弟为了争宠吵得不可开交时,突然从石头里蹦出个NDD,宣称自己才是世上最牛的"DD",FDD和TDD两兄弟顿时惊慌失措.黯然失色,私下里打探了一下NDD的底细.今天我们就来揭揭NDD的底,看看他到底牛在哪里? 首先要从双工方式说起. FDD(频分双工):采用两个对称的频率信道来分别发射和接收信号. TDD(时分双工):发射和接收信号是在同一频率信道的不同时隙中进行的. 有人说,FDD是全双工,TDD是半双工.从一定意义上,这两个都不是全双工,因为都不能实现在同一

千牛卖家版手机版宝贝管理设置教程

  第一步.打开千牛卖家版手机版客户端,点击"商品管理"--"发布". 第二步.填写详细参数(宝贝类目,运费模版,发布类型,新旧程度,宝贝标题.价格,加价幅度,商家编码,条形码,宝贝数量,宝贝图片). 信息填写完毕之后就可以完成"千牛发布商品"了.

.NET牛人应该知道些什么,我的回答

What Great .NET Developers Ought To Know (More .NET Interview Questions) A while back, I posted a list of ASP.NET Interview Questions. Conventional wisdom was split, with about half the folks saying I was nuts and that it was a list of trivia. The ot

在你编码之前(转)

很多开发者,将自己限定为程序员,觉得自己就是一个专业写代码的,和代码稍微远一点东西,就不感兴趣. 在前一篇文章 <软件开发之未来> 中, 我已经阐述了技术的时效性以及快速更新. 如果我们紧紧把目光局限在代码,而不是分析.解决问题的综合能力,我们将迟早陷入中年危机, 被奔腾的技术潮流淘汰. 这篇文章我想讲讲分析问题.解决问题的基本套路,这是我多年总结下来的习惯,希望对大家有帮助. 绝对不是立刻写代码 有些同学钟情代码,收到一个任务,马上就想到代码实现. 问题都还没弄清楚,工作原理还没分析透,就开

谈谈编码风格与编码规范

作者:玉伯   引子 上一篇文章提到 「习惯与变化」,收到了比较有意思的一些反馈: 我很好奇,如果你的团队中有人以"习惯"的名义打破编码规范会怎样?于我而言,不写四直接写五就是这种感觉,这并不是习惯,而是规范. 还有一封很长的邮件,截取一二: 玉伯哥,我经常会为一些事情纠结,比如创建文件夹的时候会想是首字母大写好看呢还是全小写来保持统一呢(Movie,movie,mytest,MyTest),当写程序注释的时候我会想是写 // this function proves that- 好呢

关于高效开发的一些套路与实践

在开发中,编码我们有分层架构.设计模式做为套路来高效开发,但你也知道编码不是开发的全部,一个完全的开发流程用面向对象思想来概括,它分为OOA(面向对象分析).OOD(面向对象设计).OOP(面向对象编程).一个好的代码结构是需要需求分析,架构设计做为辅助的,Stay尝试向你描述一个理想高效的工作流程,有了这个套路,不仅能让你缩短编码时间,还能得到团队的认可. 关于高效开发,大多数人的第一反应就是成熟的分层架构.设计模式以及第三方lib.这些给了我们设计准则还有便利的工具更快的去做需求实现. 高效