Rob Pike, 是AT&T Bell Lab前Member of Technical Staff ，現(xiàn)在google研究操作系統(tǒng)，Unix先驅(qū)，UTF-8的設(shè)計(jì)人，The Unix Programming Environment 和 The Practice of Programming 的作者之一。 在《 Notes on C Programming 》中從另一個(gè)稍微不同的角度表述了 Unix 的哲學(xué)（或者說(shuō)是程序局部?jī)?yōu)化6原則）:
1. 你無(wú)法斷定程序會(huì)在什么地方耗費(fèi)運(yùn)行時(shí)間。瓶頸經(jīng)常出現(xiàn)在想不到的地方，所以別急于胡亂找個(gè)地方改代碼，除非你已經(jīng)證實(shí)那兒就是瓶頸所在。
2. 估量。在你沒(méi)對(duì)代碼進(jìn)行估量，特別是沒(méi)找到最耗時(shí)的那部分之前，別去優(yōu)化速度。
3. 花哨的算法在 n 很小時(shí)通常很慢，而 n 通常很小。花哨算法的常數(shù)復(fù)雜度很大。除非你確定 n 總是很大，否則不要用花哨算法（即使 n 很大，也優(yōu)先考慮原則 2 ）。比如，解決常見(jiàn)問(wèn)題時(shí)，最簡(jiǎn)單的樹(shù)——二叉樹(shù)（binary tree）,總是比那些復(fù)雜的樹(shù)（AVL樹(shù)，伸展樹(shù)（splay tree）和紅黑樹(shù)、B-樹(shù)（B-tree）,多叉樹(shù)（trie））來(lái)的高校。
4. 花哨的算法比簡(jiǎn)單算法更容易出 bug 、更難實(shí)現(xiàn)。盡量使用簡(jiǎn)單的算法配合簡(jiǎn)單的數(shù)據(jù)結(jié)構(gòu)。
只要掌握了數(shù)據(jù)結(jié)構(gòu)中的四大法寶，就可以包打天下，他們是：array 、linked list 、hash table、binary tree 。這四大法寶可不是各自為戰(zhàn)的，靈活結(jié)合才能游刃有余。比如，一個(gè)用hash table組織的symbol table，其中是一個(gè)個(gè)由字符型array構(gòu)成的linked list。
5. 以數(shù)據(jù)為中心。如果已經(jīng)選擇了正確的數(shù)據(jù)結(jié)構(gòu)并且把一切都組織得井井有條，正確的算法也就不言自明。編程的核心是數(shù)據(jù)結(jié)構(gòu)，而不是算法。
6. 沒(méi)有原則 6 。
Ken Thompson —— Unix 最初版本的設(shè)計(jì)者和實(shí)現(xiàn)者，禪宗偈語(yǔ)般地對(duì) Pike 的原則4 作了強(qiáng)調(diào)：
拿不準(zhǔn)就窮舉
附：E文原文（節(jié)選自《Notes on C Programming 》Rob Pike， February 21, 1989 ）
E文全文地址：http://www.lysator.liu.se/c/pikestyle.html
Most programs are too complicated - that is, more complex than they need to be to solve their problems efficiently. Why? Mostly it's because of bad design, but I will skip that issue here because it's a big one. But programs are often complicated at the microscopic level, and that is something I can address here.
Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.
Rule 2. Measure. Don't tune for speed until you've measured, and even then don't, unless one part of the code overwhelms the rest.
Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.) For example, binary trees are always faster than splay trees for workaday problems.
Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
The following data structures are a complete list for almost all practical programs:
array
linked list
hash table
binary tree
Of course, you must also be prepared to collect these into compound data structures. For instance, a symbol table might be implemented as a hash table containing linked lists of arrays of characters.
Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be selfevident. Data structures, not algorithms, are central to programming. (See Brooks p. 102.)
Rule 6. There is no Rule 6.