书摘

<<<<     问题驱动和技术驱动相协调

<<<<      信心会用错地方，但不会用错时候。

>>>>      Pareto Principle（巴雷托定律） 20/80

设法解决某一特定领域中的所有问题会比只解决大多数实际应用中的各类要紧问题困难的多（而且性价比低得多）。

 

 

 

非常精通JDBC，运用Batch语句，调整PreapredStatement的Batch Size和Fetch Size等参数，以及在必要的情况下采用结果集cache等等

 

 

In my life as an architect, I find that the single thing which inhibits young pro-

fessionals, new students most severely, is their acceptance of standards that are too

low. If I ask a student whether her design is as good as Chartres, she often smiles

tolerantly at me as if to say, “Of course not, that isn’t what I am trying to do. . . . I

could never do that.”

Then, I express my disagreement, and tell her: “That standard must be our

standard. If you are going to be a builder, no other standard is worthwhile. That is

what I expect of myself in my own buildings, and it is what I expect of my stu-

dents.” Gradually, I show the students that they have a right to ask this of them-

selves, and must ask this of themselves. Once that level of standard is in their

minds, they will be able to figure out, for themselves, how to do better, how to

make something that is as profound as that.

 

 

 

For a programmer, what is a comparable goal? What is the Chartres of program-

ming? What task is at a high enough level to inspire people writing programs, to

reach for the stars? Can you write a computer program on the same level as Fer-

mat’s last theorem? Can you write a program which has the enabling power of Dr.

Johnson’s dictionary? Can you write a program which has the productive power

of Watt’s steam engine? Can you write a program which overcomes the gulf

between the technical culture of our civilization, and which inserts itself into our

human life as deeply as Eliot’s poems of the wasteland or Virginia Woolf’s The

Waves?

 

 

Data Crunching

 

 

 

 

In his book Simple and Direct, Jacques Barzun explains that all good writing

is based upon revision [Barzun, 227]. Revision, he points out, means to re-see.

John Thompson’s sign was gradually revised by his friends, who helped him

remove duplicate words, simplify his language, and clarify his intent. Jefferson’s

words were revised by Franklin, who saw a simpler, better way to express Jefferson’s

intent. In both cases, having many eyes revise one individual’s work

helped produce dramatic improvements.

The same is true of code. To get the best refactoring results, you’ll want the

help of many eyes. This is one reason why extreme programming suggests the

practices of pair-programming and collective code ownership [Beck, XP].