1 Chapter 2
The less you interact with your computer, the faster you can go.
luanching applications more quickly
finding files faster
using the mouse less.
Concentrate on essence, not ceremony.
The usefulness of an application list is inversely proportional to its length.
Eye candy looks good but isn't nutritious.
Typing is faster than navigation.
Prefer typing over mousing.
The address bar is the most efficient Windows Explorer interface.
Clipboarding in batches is faster than clipboarding serially.
Those who remember their history aren't doomed to type it again.
Embedded command prompts give you access to the best of both worlds.
Embed the command prompt with Explorer to make it easier to switch contexts.
Programming(except for user interface design) is a text-based activity, so you should strive to keep your hands on the keyboard as much as ppossible.
When coding, always prefer the keyboard to the mouse.
Learn IDE keyboard shortcuts in context, not by reading long lists.
When you type a complicated construct for the second time, templatize it.
The more times you perform a particular operation on a chunck of text, the greater the likelihood you'll do it again.
Don't type the same commands over and over again.
Spend a little time each day to make every day more productive.
2 Chapter 3
Kill Distractions: you are a knowledge worker, meaning you are paid for the creative and innovative ideas you produce. Dealing with constant distractions, both at your desk and on your desktop, can threaten your best contributions to your projects. Developers crave a state known as flow, discussed in lots of places(it even has an entire book devoted to it, written by Csikszentmihalyi). All developers know this state: it's when you are so focused that time disappears, you develop an almost symbiotic relationship with the machine and the problem you are attacking. This is the state you've been in when you say, "Wow, have four hours passed? I didn't even notice." The problem with flow is that it is fragile. One distraction pulls you out, and it takes effort to get back in. It also suffers from inertia. Late in the day, you have to fight harder to get back to that state, and the more times you are abruptly pulled out, the harder it becomes. Distractions kill your focus on the problem at hand, making you less productive. Fortunately, you can effectively block distractions in a few simple ways.
The higher the level of concentration, the denser the ideas.
How many of the emails you receive in the course of a day really require an immediate response?
The bigger the haystack, the harder it is to find the needle.
Replace file hierarchies with search.
Try simple searching before resorting to "hard target" searching.
Use links to create virtual project management folders.
3 Chapter 4
wget –mirror –html-extension –convert-links -P dir
curl -d "birthday=1905&press=%200K%20 www.hotmail.com/when/junk.cgi
ant and gant
rake
selenium
I have encountered some system administrators who write bash scripts for every task they perform. They do this for two reasons. First, if you do it once, you're almost certainly going to do it again. Bash commands are very terse by desigin, and it sometimes takes a few minutes even for an experienced developer to get it right. But if you ever have to do that task again, the saved commands save your time. Second, keeping all nontrivial command-line stuff around in scripts creates living documentation of what you did, and perhaps why you performed some task. Saving everything you do is extreme, but storage if very cheap–much cheaper than the time it takes to recreate something.
Justifying automation is about return on investment and risk mitigation.
Timebox speculative development.
4 Chapter 5
Always keep the entire universe required to build your software in version control(minus the operating system, and even that is possible with virtualization)
Keep a single copy of everything you don't build in version control.
Use a Canonical Build Machine
The other process required in every development shop is continuous integration. Continuous integration is a process where you build the entire project, run tests, generate documentation, and do all the other activities that make software on a regular basis(the more often the better, generally you should build everytime you check in code to version control). Continuous integration is supported by software of the same name. Ideally, the coninuous integration server runs on a separate machine, monitoring your check-ins to version control. Every time you perform a code check-in, the continuous integration server springs to life, running a build performing a full build, setting up the database for testing, running the entire suite of unit tests, running code analysis, and deploying the application to perform a "smoke test.". The continuous integration server redirects build responsibilities from individual machines and creates a canonical build location.
The canonical build machine should not include the development tool you use to create the project, only the libraries and other frameworks needed to build the application. This prevents subtle dependencies on tools from creeping into your build process.
No matter what you are copying and pasting, reuse by copy and paste is evil
Always keep code and schemas in sync.
Use migrations to create repeatable snapshots of schema changes.
Out-of -date documentation is worse than none because it is actively misleading.
For managers, documentation is about risk mitigation.
Always keep "living" documentation.
Anything that takes real effort to create makes its creator irrationally attached to it.
Generate all the technical documents you can.
Never keep two copies of the same thing(like code and diagram describing it).
SchemaSpy
Repetition is the single most diminishing force in software development.
5 Chapter 14
If Java had included a foreach keyword from the outset, no one would have cared about the index number of arrays. Of course, Java finally did get a foreach operator(called, confusingly enough, for, just like the other one), and it took only eight years.
Java includes a depressingly large number of strange quirks and idioms, some anew from the Java creators, some existing as baggage from a previous life. All languages are like that, to varying degrees. Is there a way to escape this madness?
6 Chapter 15
Find your perfect editor and learn it inside and out.
Don't make round trips when you can batch.
一些有用的blog:
pluskid: http://lifegoo.pluskid.org/wiki/index.html
4G space: http://blog.youxu.info/2011/01/24/keyboard-only-thoughts-one-year-later/
我自己也在写,不过写的有点慢,最近正在学习APUE等大部头,学习下底层原理后再来完善:
http://cnlox.is-programmer.com/posts/31971.html
重点摘记了Part I的一些tips,顺带推荐一些blog
《卓有成效的程序员》热门书评
-
上帝的归上帝,程序的归程序
37有用 1无用 Yurii 2009-03-29
http://www.luanxiang.org/blog/archives/593.html程序员,就是整天与机器打交道的那群人。在计算机并不普及的年代,这样的描述毫无疑问;然而,这些年来,得益于计算机成本的不断下降,软件使用门槛的不断降低,如今,昔日昂贵而又神秘不可莫测电脑,已经成了随处可见、人...
-
卓有成效的程序员──咱码农如何实现自我加速
25有用 0无用 masque 2010-07-04
写在BLOG上,原文粘过来。额,有几张图片粘不了,链接在这里:http://www.oeddyo.com/%E3%80%8A%E5%8D%93%E6%9C%89%E6%88%90%E6%95%88%E7%9A%84%E7%A8%8B%E5%BA%8F%E5%91%98%E3%80%8B%E2%94%...
-
人有多大懒,才有多大闲
14有用 1无用 张凯峰 2009-08-15
《卓有成效的程序员》给我的震撼很大,程序员作为特殊的群体,有的人可以这么懒,懒到事情都交给机器去做,而有的人又可以那么勤奋,每天都孜孜不倦得做着重复单调的工作。在看这本书之前,我属于勤奋的人,而看完这本书以后,我要努力变成懒惰的人。不要在去庞大的开始菜单里面一项一项搜索自己的应用程序,也不要在自己的...
-
卓有成效的电脑使用者
8有用 0无用 Urumchi 2009-05-30
说实话,我只重点看了第一部分<机制>,第二部分<实践>倒只是走马观花的扫了一遍.不得不说,前5章很对我的口味.一些有些人可能认为难登大雅之堂,或者说零零碎碎的小技巧第一次(至少对我来说)写在书里.而这些之前大多只是在网上以新工具推荐方式出现,这本书却改变了这点,这些工具/技巧...
-
高效开发的敲门砖
6有用 0无用 dreamhead 2008-10-06
回想一下:* 怎样启动一个程序?* 怎样切换到一个文件上去?曾经的我这样做:* 点开“开始”菜单,在“程序”中,一项项寻找过去……* 在IDE中,找到目录的根,然后一层层目录展开……现在的我这么做的:* 用快捷键调出一个启动程序,比如Launchy,敲入我要启动程序的名字,比如firefox,然后回...
书名: 卓有成效的程序员
作者: [美] Neal Ford
出版社: 机械工业出版社
原作名: The Productive Programmer
副标题: 一本揭示高效程序员的思考模式,一本告诉你如何缩短你与优秀程序员的差距
译者: ThoughtWorks公司
出版年: 2009-3
页数: 216
定价: 45.00元
ISBN: 9787111264064