文章吧-经典好文章在线阅读:The Productive Programmer的读后感10篇

当前的位置:文章吧 > 经典文章 > 读后感 >

The Productive Programmer的读后感10篇

2018-03-13 21:06:02 来源:文章吧 阅读:载入中…

The Productive Programmer的读后感10篇

  《The Productive Programmer》是一本由Neal Ford著作,O'Reilly Media, Inc.出版的Paperback图书,本书定价:USD 39.99,页数:208,文章吧小编精心整理的一些读者的读后感,希望对大家能有帮助。

  《The Productive Programmer》读后感(一):The Productive Programmer

  Anyone who develops software for a living needs a proven way to produce it better, faster, and cheaper. The Productive Programmer offers critical timesaving and productivity tools that you can adopt right away, no matter what platform you use. Master developer Neal Ford not only offers advice on the mechanics of productivity-how to work smarter, spurn interruptions, get the most out your computer, and avoid repetition-he also details valuable practices that will help you elude common traps, improve your code, and become more valuable to your team. You'll learn to:

  * Write the test before you write the code

  * Manage the lifecycle of your objects fastidiously

  * Build only what you need now, not what you might need later

  * Apply ancient philosophies to software development

  * Question authority, rather than blindly adhere to standards

  * Make hard things easier and impossible things possible through meta-programming

  * Be sure all code within a method is at the same level of abstraction

  * Pick the right editor and assemble the best tools for the job

  This isn't theory, but the fruits of Ford's real-world experience as an Application Architect at the global IT consultancy ThoughtWorks. Whether you're a beginner or a pro with years of experience, you'll improve your work and your career with the simple and straightforward principles in The Productive Programmer.

  《The Productive Programmer》读后感(二):Management, something that's more important than tools

  This is book about how to boost the programmer's productivity. In the first paragraph of the foreword of this book, the author says it lies in the methodology of using tools and philosophy. But after reading this book, I can't totally agree.

  The book covers a lot topics related to productivity in different levels:

  *the computer interaction: using searching instead of navigation, launching pad, editor choosing

  *programming tools: code analyzer,

  *programming methodology: Test driven design, Meta-programming, composed method, polyglot programming,

  *programming philosophy: automation, Don't repeat yourself

  *Programmer self-management: Focus, YAGIN, Don't sheave yak, accidental complexity and essential complexity.

  The first two topics is purely about tools, the third is about how to using the programming language, and the last two is actually about programmer management. Anyway, if you treat the programming language and yourself as one kind of programming tools, the author's answer to productivity would match all the chapters of this book well.

  efore I read this book, I have summarized some similar tips in the computer interaction aspect by myself. But now, honestly speaking, I'm not a productive programmer at all. Why? The answer lies in the last two parts, the programmer's self management.

  Writing a script by using an unsuitable language will only waste me several hours, but doing something unnecessary things would cost me several days. We can run fast, but this should be based on the premise of the right direction. When I add this book to my read list, I also add another, Rapid Development, which states a general strategy for rapid development:

  *Avoid classic mistakes

  *Apply development fundamentals

  *Manage risks to avoid catastrophic setbacks

  *Apply schedule-oriented practices

  From the view of this book, the Productive Programmer mainly solves the problem in the development fundamentals. As a research based programmer, management is much more important than the programming tricks.

  《The Productive Programmer》读后感(三):高效开发的敲门砖

  回想一下:

  * 怎样启动一个程序?

  * 怎样切换到一个文件上去?

  曾经的我这样做:

  * 点开“开始”菜单,在“程序”中,一项项寻找过去……

  * 在IDE中,找到目录的根,然后一层层目录展开……

  现在的我这么做的:

  * 用快捷键调出一个启动程序,比如Launchy,敲入我要启动程序的名字,比如firefox,然后回车。

  * 用快捷键调出文件搜索框,然后,敲入我要找的类的名字,然后回车。

  我是一个程序员。

  程序员是一个典型的“知之为知之,不知为不知”的职业。上面的那些做法不足为奇,但是,没有见识过,有时自己就是想不到。进入ThoughtWorks之前,我写程序非常按部就班,大多数代码都属于“纯手工”打造。进入ThoughtWorks之后,我见识到有人把快捷键运用得出神入化,运指如飞的同时,大片的代码也随之产生。那时,我才知道,快捷键的“快捷”并非浪得虚名。从那以后,我也开始刻意的运用快捷键提高自己的开发效率。快捷键,只是高效开发的一个侧面,还有哪些方法可以提高开发效率呢?

  这里,我要说的是一本书,一本关于如何提高开发效率的书:Neal Ford的《Productive Programmer》。

  软件开发的书有很多,讲方法、谈设计、探寻终极解决之道。《Productive Programmer》显得很与众不同,它并不打算语不惊人死不休,所以,在这本书里面,我们看到的更多是一些具体的做法:加速自己的操作、消除干扰、尽可能的自动化、用好工具等等。如果你已经是一个高效的程序员,也许会觉得这本书的内容对你来说,过于平淡无奇,因为这不是一本讲原则的书,不能指望记住几个名字就可以到处敲山震虎了。但是,正是那一条条具体的技巧时不时会让人有“哦,原来可以这么做”的感叹。所谓经验,不就是这样一点一点积累出来的嘛!

  好吧!Neal Ford是一个ThoughtWorker,我承认,书中的技巧有不少是我见识过的,比如提交代码之前通过命令加入新增文件。正是因为这样,所以,这本书中的很多做法,给我留下了非常实用的感觉。知道这些技巧之后,就可以立即应用到项目之中,立竿见影。

  虽然这不是明码标价的Unix书籍,但从这本书中,我读到了非常浓重的Unix味道,许多精彩的命令行操作都是源自Unix。随着自己开发经验的增多,我越发喜欢Unix的命令行,除了让人觉得很酷的操作感,命令行可以尽情发挥你的想象力高效的完成一些图形界面的操作。有人说,程序设计语言的发展,是 Lisp的回归。在我看来,程序员的进步,是向Unix风格的靠拢。Unix最初就是程序员为程序员打造的系统。当然,这本书还继承了一些Unix书籍的优良传统,短小精悍。二百多页的身材让它有机会成为不错的随身读物。

  一本书可以打开一扇门,读《Productive Programmer》给人带来的思考,怎样提高自己的工作效率。这本书已经为我们展示了很多方面,但,这只是一个开始,聪明的程序员总会不断找到各种各样的方式让自己生活更舒适一些。

  读过这本书,我突然想,如果我初学编程时遇到这样一本书该多好,至少让我可以少走不少弯路。

  《The Productive Programmer》读后感(四):重点摘记了Part I的一些tips,顺带推荐一些blog

  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.

  refer 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.

  rogramming(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.

  end 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

  elenium

  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.

  o 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.

  ever keep two copies of the same thing(like code and diagram describing it).

  chemaSpy

  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:

  我自己也在写,不过写的有点慢,最近正在学习APUE等大部头,学习下底层原理后再来完善:

  《The Productive Programmer》读后感(五):半部九阴真经 & 半部九阴真经

  分两天看完的,所以有上下两卷。

  以下是读书笔记。

  和

  半部九阴真经

  而且还是上卷。

  The Productive Programmer, Part I 笔记。

  ====================

  Context switching eats time.

  用于作为证据,说明 multiple clipboard 的重要性。

  ----

  历史

  [guyang@digi02 ~]$ history

  1 17:37 ls

  2 17:37 pwd

  3 17:37 history

  4 17:37 history

  5 17:37 pwd

  6 17:37 ls

  7 17:37 ls -l

  8 17:37 ls -l

  9 17:38 history

  10 17:38 history | grep ls

  11 17:38 ls

  12 17:38 history

  [guyang@digi02 ~]$ !1

  ls

  100 a bin cat2.JPG Download input.txt map to sea.png Pictures text.aux text.tex 中华utf8

  100.c aa blackduck.txt cat2 smile.JPG dwhelper learning mean sandbox text.dvi tour.png

  30 aa.txt bookmark danmark.orgE eng.txt lib mean.c svn text.log tt.orgF

  30.c a.txt canals Desktop fetion Mail News tc.txt text.pdf youngworkshop

  [guyang@digi02 ~]$ !2

  wd

  /export/home/aton4/guyang

  [guyang@digi02 ~]$!h | grep p

  history | grep p

  2 17:37 pwd

  5 17:37 pwd

  10 17:38 history | grep ls

  15 17:39 pwd

  16 17:39 history | grep p

  [guyang@digi02 ~]$ !2

  wd

  /export/home/aton4/guyang

  [guyang@digi02 ~]$

  ----

  ushd & popd

  ----

  快挺键的学习,需要在适用此键的上下文环境中。

  One of my colleagues has a great way of teaching keyboard

  hortcuts. Whenever you pairprogram with him, if you use a mouse to

  elect a menu or tool button, he makes you undo your operation, then

  do it three times using the keyboard. Yes, it slows you down at first,

  ut the reinforcement (plus his evil eye when you forget them) is a

  ressure cooker to learn shortcuts.

  -----

  grep显示文件名和行号

  find . -name "*.java" -exec grep -n -H "new .*Db.*" {} ;

  {} Placeholder for the filename found by find.

  ; Terminate the command after -exec. Because this is a Unix command,

  you might want to pipe the results of this into another command, and

  the find command has to know when the "exec" is done.

  [guyang@digi02 ~]$ grep -nH "main" *c

  100.c:3:int main()

  30.c:3:int main(int argc, char *argv[])

  mean.c:3:int main(int argc, char *argv[])

  -------------------

  explorer /e,/root,c:workcit

  -------------------

  web开发自动化测试

  You can also interact with pages that require an HTML POST instead of GET using the "-d"

  command-line option:

  curl -d "birthyear=1905&press=%20OK%20" www.hotmail.com/when/junk.cgiG

  ubvert Selenium to Walk Web Pages

  elenium‡ is an open source user acceptance testing tool for web applications. It allows you to

  imulate user actions by automating the browser via Javascript. Selenium is written entirely

  in browser technology, so it runs in all mainstream browsers. It is an incredibly useful tool for

  testing web applications, regardless of the technology used to create the web application.w

  -------------------

  uniq

  #!/bin/bash

  for X in $(egrep -o "[A-Z]w*Exception" log_week.txt | sort | uniq) ;

  do

  echo -n -e "processing $Xt"

  grep -c "$X" log_week.txt

  done

  ----------------------

  Monad

  Windows Power Shell

  ----------------------

  vn st | grep '^?' | tr '^?' ' ' |

  ed 's/[ ]*//' | sed 's/[ ]/\ /g' | xargs svn add

  vn st

  Get Subversion status on all files in this directory and all

  its subdirectories. The new ones come back with a ? at the beginning

  and a tab before the filename.

  grep '^?'

  Find all the lines that start with the ?.

  tr '^?' ' '

  Replace the ? with a space (the tr command translates one

  character for another).

  ed 's/[ ]*//'

  Using sed, the stream-based editor, substitute spaces

  to nothing for the leading part of the line.

  ed 's/[ ]/\ /g'

  The filenames may have embedded spaces, so use sed

  again to substitute any remaining spaces with the escaped space

  character (a space with a in front).

  xargs svn add

  Take the resulting lines and pump them into the svn add

  command.

  --------------------------

  自动化的理由之一

  Does this task destroy my focus? (Almost any task takes you away from

  your locus of attention, making it harder to get back to your focused

  tate.)

  -----------------------------

  Don't Shave Yaksv

  译为"别给牦牛剪毛"

  Yak shaving is dangerous because it eats up a lot of time. It also

  explains why estimating tasks is so often wrong: just how long does it

  take to fully shave a yak? Always keep in mind what you are trying to

  achieve, and pull the plug if it starts to spiral out of control.

  -----------------------

  canonicality

  简而言之,所有开发人员的机器配置都一样。

  同步或使用hard link。

  开发工具允许不同(避免代码对工具的依赖),但是库及framework的版本必须一致。

  ----------------------

  o matter what you are copying and pasting, resuse by copy and paste

  is evil.

  而indirection是推荐行为。

  ------------------

  vmware虚拟机镜像,避免授权问题。

  -------------------

  不应直接修改从ORM中得到的class code,应该先继承,然后在子类中添加或修改方法...这也是间接。

  Of course, this is just a DAO (data access object) with no behavior:

  it is merely a collection of get/set methods. If you need to add

  ehavior to this entity, you can subclass the DAO to add

  methods. Never hand-edit a generated file because it will be

  regenerated the next time you perform a build. NOTE Add behavior to

  generated code via extension, open classes, or partial classes.

  杨注:这样,在DSM生成的C代码中,也应该预留回调函数,而不应该允许直接修改生成的代码。

  -----------------------

  Always keep "living" documentation.

  过时的文档 比没有文档更糟糕。

  提到自研发工具svn2wiki

  ------------------

  ...continuous integration

  -------------------

  告诫是一遍又一遍啊。

  Repetition is the single most diminishing force in software development.

  Duplication is evil. Evil, I say!

  DRY = Don't Repeat Yourself.

  -----------------

  -----------------

  半部九阴真经 下卷D

  半部九阴真经

  下卷。

  ----

  JAVA的复杂度检查工具 和 code coverage工具。

  甚至能检查疑似的copy&paste代码。

  对比C++。群众基础是多么重要啊。

  -----

  YAGNI STANDS FOR "YOU AIN'T GONNA NEED IT." ItT

  不要为将来而担心.

  过度工程.

  -----

  owerful languages + domain-specific meta-layers offer the best

  approach currently available. The productivity comes from working

  close to the problem domain in the DSL; the power comes from the

  abstraction layer simmering just below the surface. Expressive DSLs on

  top of powerful languages will become the new standard. Frameworks

  will be written using DSLs, not on top of statically typed languages

  with restrictive syntax and unnecessary ceremony.

  ------

  The Law of Demeter

  不要跟陌生人说话.

  ever use more than one dot for any method call.

  Job job = new Job("Safety Engineer", 50000.00);

  erson homer = new Person("Homer", job);

  homer.getJob().setPosition("Janitor");

  按 Law of Demeter,改为

  ublic PersonDemo() {

  Job job = new Job("Safety Engineer", 50000.00);

  erson homer = new Person("Homer", job);

  homer.changeJobPositionTo("Janitor");

  }

  ublic void changeJobPositionTo(String newPosition) {

  job.changePositionTo(newPosition);

  }

  erson屏蔽了job的细节.

  杨常使用上面的那个不符合law of Demeter的方法,并困惑client怎么能不对job产生信赖.

  ---------------------

  以下是引用的。

  For projects on which I'm the tech lead, our rule of thumb is to

  allow no method to exceed 15 lines of code in Java or C#. For dynamic

  languages such as Groovy or Ruby, the rule is five lines of code.f

  ------------------

  LAP,没注意过这个。

  这样,写public函数就有有点类似于写大纲了。

  LAP STANDS FOR THE SINGLE LEVEL OF ABSTRACTION PRINCIPLE.

  LAP insists that all your code within a

  method live at the same level of abstraction.

  Encapsulate all implementation details away from public methods.

  ----------------------

  完美编辑器需要的功能之一

  Additive cut and copy commands

  Don't make round trips when you can batch.

  ------------------------

  对于XML持否定态度

  可以使用XML,但是只生成,不书写。

  Keep behavior in (testable) code.

  举例,用Groovy生成XML。

  --------------------------

评价:

[匿名评论]登录注册

评论加载中……