程序员的共鸣 - 读《卓有成效的程序员》

简介:
最近读了《卓有成效的程序员》,感觉收获颇大。这是一本写给程序员的难得的好书。书中大都是一些浅显的道理,但作者将这些东西加以收集、归纳、总结,并最终成书。作者为了收集各种提高效率的工具和方法,东奔西走,可谓费了一番苦心。

我觉得此书第一部分总结的一些法则非常好,我提取了一下:

法则:

1.加速法则

    关注本质,而非形式

    一个应用程序列表的有用程度与它的长度成反比

    程序员的很多时间都浪费在找东西上

    华而不实的东西中看不中用

    键盘输入总比导航快

    首选键盘而非鼠标

    地址栏是Windows资源管理器界面中最高效的部分

    花点时间来学习你手边的所有隐藏的快捷键

    环境切换会消耗时间

    成批复制粘贴要比反复多次复制粘贴快

    忘记历史就意味着你得再输入一遍

    嵌入图形化工具的命令提示符让你鱼与熊掌兼得

    在上下文中学习IDE快捷键,而不要去背长长的列表

    当你第二次输入一个复杂结构时,将它做成模板

    如果要对多行文本做同样的操作,就应该找出其中的模式,并把它记录为一个宏

    不要总是重复输入相同的命令

    每天花一点点时间来使每一天都更高效

2.专注法则

    精力越集中,思维越缜密

    排除干扰:隔离策略,关掉不需要的提示,创造安静时间 

    草堆越大,从中找到一根针就越难

    不要问文件树,要搜索

    使用多显示器

    虚拟桌面可以让原本杂乱无章的一大堆窗口变得整洁

3.自动化法则

    不要重新发明轮子

    用Selenium浏览网页

    不要浪费时间动手去做可以被自动化的事情

    用Windows Power Shell替代批处理文件

    驯服Subversion命令行

    以创造性的方式解决问题,有助于在将来解决类似的问题

    是否应该自动化的关键在于投资回报率和缓解风险

    研究性的工作应该放在时间盒里做

    别给牦牛剪毛

4.规范性法则

    对于任何你不自己去构建的东西,只在版本控制中保存一份副本

    使用标准的构建服务器

    通过复制粘贴来复用是邪恶的,不论你复制粘贴的是什么

    利用虚拟平台使项目依赖标准化

    不要让对象 - 关系映射工具(O/R映射器)违反规范原则

    通过扩展。开放类(open class),或者部分类(partial class) 来为生成的代码增加行为

    始终保持代码和数据结构的同步

    过时的文档比没有文档更糟,因为它会主动误导你

    任何需要费劲创造的东西,都让它的创造者欲罢不能

    白板 + 数码相机强过任何CASE工具

    尽量生成所有技术文档

    重复是软件开发中最大的阻力

工具:

书中,还提到了大量的提高效率的工具,都是非常不错的。相信很多人都有自己的一个列表,下面是我电脑中必不可少的几款软件:

    1. FireFox 及其各类插件

    2. Launchy启动加速器

    3. Total Commander

    4. ClipX多重剪切板

    5. EmEditor文本编辑器

    6. Vistual Studio的VA插件

    7. Search And Replace

    8. Everything

    9. Miranda IM

    10. ....

感触:

1. 愤怒的猴子

在书中的第二部分,提到了很多实践相关的内容。让我感触最深的是“愤怒的猴子”的故事:

早在20世纪60年代(那时候科学家们可以做任何疯狂的事情),行为科学家们进行了一项实验。他们把五只猴子和一架活梯放在一间屋子里,并在天花板上挂了一串香蕉。这些猴子很快就想到它们可以爬上梯子去吃香蕉,但每当它们靠近活梯的时候,科学家们就用冰水浸满整个屋子。我想你能猜到会发生什么:一群愤怒的猴子。很快,再没有一只猴子会去靠近那个梯子了。

之后,科学家们将其中一只猴子替换成另一只没有忍受过冰水折磨的新猴子。这只新猴子所做的第一件事就是直奔那架梯子,但当它这么做时其他所有猴子都痛打它。它不明白为什么,但很快就学乖了:不要去靠近那架梯子。科学家们逐渐将最初的那些猴子都替换成新猴子,直到这群猴子中谁都没有被水浸泡过,然而它们还是会去攻击任何靠近梯子的猴子。

这说明了什么?软件项目中许多惯例之所以存在,就因为”我们一直是那样做的“。换句话说,是因为愤怒的猴子。

我们小组在制定C++相关的代码规范时就遇到过无数类似的问题。比如,在制定变量的命名规范时,我们针对是否采用匈牙利命名法争论了很久。有的人认为, 几乎以前看到的所有C++代码都采用了匈牙利命名法,甚至,微软定义的所有API都使用了此类命名法。刚开始,我也是有同样的疑惑。

后来,我们经过仔细分析C++匈牙利命名法由来,渐渐感觉我们就是那些愤怒的猴子,盲目跟从前人的方式,缺乏打破传统的勇气。C++有着其特殊的历史原因,很多标准一直沉淀下来并很少改变。我们再看看后来新生的那些编程语言,C#, Python…… 都抛弃了匈牙利命名法,同时再看看现在C++前沿的C++ 0x以及现在出版的一些书中,也渐渐放弃了对匈牙利命名法的使用。因为类型的意义在对象模型中越来越弱化。因此,最后我们放弃了匈牙利命名法这个老古董。

2. 敏捷开发

这本书带有强烈的ThoughtWorks色彩,敏捷的思想贯穿全书,包括测试驱动设计,白板,结对编程。这也让我对敏捷产生了更加强烈的兴趣。 其中有一段测试驱动开发TDD的一段故事:

记得第一次和一些已经习惯于单元测试的开发人员一起动手开始修改代码时,我也是非常紧张,因为大量的修改往往会破坏很多东西,但他们看起来丝毫没有犹豫。逐渐地,我也放下心来,因为我慢慢地认识到:有了测试的保证,完全可以放心大胆地去修改代码。

3. 有趣的故事

书中还有一些有趣的故事,比如作者的一个朋友在和别人结对编程时,为了养成同伴使用快捷键的习惯,每当同伴未使用快捷键时,他都会要求将操作撤销,然后要求使用快捷键再重复操作3次。然后,在其凶狠的眼神中,同伴很快掌握了快捷键。

总结:

这本书很薄,蕴藏的道理却不少,相信每个读过它的人都会从中收获。读过之后,我们不应该局限于书中提到的某些小技巧, 或是书中某一个细节,毕竟,提供效率的方法有很多很多,法则也有很多很多,一本书很难将其穷举完。我们应该从书中吸取其思想,并在实际工作和学习中不断总结,做一个真正的“卓有成效的程序员”!

 

 

本文转自CoderZh博客园博客,原文链接:http://www.cnblogs.com/coderzh/archive/2009/07/18/1526082.html,如需转载请自行联系原作者

相关文章
|
架构师 程序员 Android开发
35岁以上程序员都去哪里了?
人这一辈子没法做太多的事情,所以每一件都要做得精彩绝伦。 你的时间有限,所以不要为别人而活。不要被教条所限,不要活在别人的观念里。不要让别人的意见左右自己内心的声音。 最重要的是,勇敢的去追随自己的心灵和直觉,只有自己的心灵和直觉才知道你自己的真实想法,其他一切都是次要。 身边好几个年轻的同事都在说房价,很多人抱怨房价太高了买不起怎么办好迷茫…
35岁以上程序员都去哪里了?
|
前端开发 程序员 C#
水瓶座的回顾-高贵的程序员
水瓶座的回顾-高贵的程序员
90 0
|
程序员
厉害了,天刚一冷程序员就都换上了衬衫。。
这才农历九月初,大秋天的,深圳的天气就已经降温了。更搞笑的是,朋友圈、群里都在转发下面这张图片,相信大部分人已经看过了吧
厉害了,天刚一冷程序员就都换上了衬衫。。
|
程序员 Ruby Java
不要再叫自己“程序员”了
程序员不要将自己限定在写代码这一单一职能上,需要认清自身商业价值的本质,需要锻炼自己的沟通能力,擅于表现自己。职业只是一种生活方式,并不能完全支配我们的幸福。我们应该为了生活而工作,而不要为了工作而生活。
2516 0
|
架构师 程序员
如果我告诉你,程序员这条路很难走,你还要坚持走下去吗
可能很多人都觉得程序员是个高薪行业,动不动就听见谁月薪几万几万,心里羡慕不已。回头看自己每个月手里可怜的工资条,心里更是烦躁不已,于是乎下定决心一定要像人家一样,月薪几万。
1734 0
|
程序员 PHP
来自一个程序员的内心世界
一入编程深似海,从此再无双休日.在我们行当一直有这么一个民间歌谣。程序猿很辛苦,这是必然的.路漫漫其修远兮,吾将上下而求索。天将降大任于斯人也,必先苦其心志,劳其筋骨,饿其体肤,空乏其身。
1514 0
|
JavaScript Java 程序员

热门文章

最新文章