如果有一天剑辫，有人告訴你干旧，你將來(lái)需要和一幫只會(huì)說(shuō)英語(yǔ)和泰語(yǔ)的家伙工作在一起，而你的工作是要告訴他們?nèi)绾螌?xiě)整潔的代碼妹蔽，如何做重構(gòu)椎眯，什么是TDD，什么是面向?qū)ο蟾炱瘢阍撛趺崔k编整？
你問(wèn)我，我只能告訴你乳丰，我需要重新讀一次《整潔代碼》掌测，《重構(gòu)》以及《
敏捷軟件開(kāi)發(fā):原則、實(shí)踐和模式》的英文版成艘，然后整理出里面可以為我使用的術(shù)語(yǔ)和表達(dá)赏半。
第二章：Functions（函數(shù)方法）
Different levels of abstraction（不同層次的抽象）
Do you understand the function after three minutes of study? Probably not. There’s too much going on in there at too many different levels of abstraction. There are strange strings and odd function calls mixed in with doubly nested if statements controlled by flags.
Intuit（Understand or work out by instinct贺归，意會(huì)）
How can we make a function communicate its intent? What attributes can we give our functions that will allow a casual reader to intuit the kind of program they live inside?
Small（小而美的函數(shù)）
The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. This is not an assertion that I can justify. I can’t provide any references to research that shows that very small functions are better. What I can tell you is that for nearly four decades I have written functions of all different sizes. I’ve written several nasty 3,000-line abominations. I’ve written scads of functions in the 100 to 300 line range. And I’ve written functions that were 20 to 30 lines long. What this experience has taught me, through long trial and error, is that functions should be very small.
Do one thing（只做一件事情）
Functions should do one thing. They should do it well. They should do it only. The problem with this statement is that it is hard to know what “one thing” is.
One level of abstraction below（低一級(jí)的抽象）
Is the function doing one thing or three things? Notice that the three steps of the function are one level of abstraction below the stated name of the function.
If a function does only those steps that are one level below the stated name of the function, then the function is doing one thing. After all, the reason we write functions is to decompose a larger concept (in other words, the name of the function) into a set of steps at the next level of abstraction.
One level of abstraction per function（每個(gè)函數(shù)具有相同的抽象層次）
In order to make sure our functions are doing “one thing,” we need to make sure that the statements within our function are all at the same level of abstraction.
Mixing levels of abstraction within a function is always confusing. Readers may not be able to tell whether a particular expression is an essential concept or a detail.
Don’t be afraid to make a name long（不要擔(dān)心名字太長(zhǎng)）
Don’t be afraid to make a name long. A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment. Use a naming convention that allows multiple words to be easily read in the function names, and then make use of those multiple words to give the function a name that says what it does.
Refine that code, splitting out functions, changing names, eliminating duplication（打磨代碼淆两，拆分函數(shù)，修改命名拂酣，消除重復(fù)）
Writing software is like any other kind of writing. When you write a paper or an article, you get your thoughts down first, then you massage it until it reads well. The first draft might be clumsy and disorganized, so you wordsmith it and restructure it and refine it until it reads the way you want it to read.
When I write functions, they come out long and complicated. They have lots of indenting and nested loops. They have long argument lists. The names are arbitrary, and there is duplicated code. But I also have a suite of unit tests that cover every one of those clumsy lines of code.
So then I massage and refine that code, splitting out functions, changing names, eliminating duplication. I shrink the methods and reorder them. Sometimes I break out whole classes, all the while keeping the tests passing.
To be continued（未完待續(xù)）
