李開復 google 的震撼

天才工程師會做幾倍的事情

管理天才最大的秘訣就是要放權，可以說是無為而治
天才型（員工）最大的滿足，是在他工作上的成就和對工作的熱情

希望你只推薦你覺得比你厲害的人，不要推薦跟你關係好的人，或是你欠他一個favor（人情）的人。

做管理就是要以身作則。假設一個人推薦了另外一個人，我覺得他不太好，我就會找這個人明白告訴他，我覺得這個人不太好
他推薦了一個確實比他優秀的人，我也會告訴他我很感謝他。

管人是非常世俗、一元化錯誤的觀點，因為他是永無止境的。你永遠不可能萬人之上
第二，如果你把領導當作你未來的目標，你還是要按部就班把基礎打好，你如果不知道什麼是做人道理、與人相處的方式，還有基礎知識、團隊精神，然後你就說要管人，那也是很本末倒置的想法。

如果我希望每個人用誠信方法做事，或是Google要求不做邪惡的事情，

價值文化：顧客第一　
股東利益排在用戶之後

如果你問一個成功的公司，誰比較重要，用戶？股東？還是員工？他們都很難回答，答案是「一樣重要」。但是在Google，非常清晰，用戶最重要。

雇主沒有權力要求員工永遠為他服務

問：去年七月五日，你離開微軟前，走進比爾．蓋茲辦公室說的第一句話：「I need to follow my heart」。這句話背後是不是有些涵義，是不是因為微軟對你的承諾沒有達到？

答：不是這樣，我的心告訴我，我這一生有幾件事情很重要。第一，我要為中國人做一些事情；第二，把更多的創新，讓世界上使用，其中有一個環節科研、發明轉移、創新怎麼做，Google有一套新的做法；第三，我喜歡跟最優秀的人很快樂的工作。Google中國這個環境是一個很好的歸宿。

====
今天已經不是三國時代了，沒有一個雇主有權力要求員工永遠為他服務，這是一個中國無法理解社會現狀的誤解。
還有一個部分就是我與微軟簽的合約，這邊所謂的「競業條款」，認為說你不能加入另外一個競爭對手；這不是美國的法律，華盛頓的法律跟我簽的合約是我不能在另外一個公司從事同樣的工作。

我兩邊的工作其實是徹底不一樣的，這就是最後（法院）判定的，不能從事一樣的工作。就是跟我當初簽的合約是一樣的，有很多妥協內容我是不能講的。

成為程式設計高手的八大奧秘, 作者：白星海(大陸知名程式設計師)

不知不覺做軟體已經做了十年，有成功的喜悅，也有失敗的痛苦，但總不敢稱自己是高手，因為和我心目中真正的高手們比起來，還差得太遠。世界上並沒有成為高手的捷徑，但一些基本原則是可以遵循的。

1、扎實的基礎

資料結構、離散數學、編譯原理，這些是所有電腦科學的基礎，如果不掌握它們，很難寫出高水準的程式。程式人人都會寫，但當你發現寫到一定程度很難再提高的時候，就應該想想是不是要回過頭來學學這些最基本的理論。不要一開始就去學OOP，即使你再精通OOP，遇到一些基本演算法的時候可能也會束手無策。因此多讀一些電腦基礎理論方面的書籍是非常有必要的。

2、豐富的想像力

不要拘泥于固定的思維方式，遇到問題的時候要多想幾種解決問題的方案，試試別人從沒想過的方法。豐富的想像力是建立在豐富的知識的基礎上，除電腦以外，多涉獵其他的學科，比如天文、物理、數學等等。開闊的思維對程式師來說很重要。

3、最簡單的是最好的

這也許是所有科學都遵循的一條準則，複雜的質能轉換原理在愛因斯坦眼裏不過是一個簡單得不能再簡單的公式：E=mc2。簡單的方法更容易被人理解，更容易實現，也更容易維護。遇到問題時要優先考慮最簡單的方案，只有簡單方案不能滿足要求時再考慮複雜的方案。

4、不鑽牛角尖

當你遇到障礙的時候，不妨暫時遠離電腦，看看窗外的風景，聽聽輕音樂，和朋友聊聊天。當我遇到難題的時候會去玩遊戲，當負責遊戲的那部分大腦細胞極度亢奮的時候，負責編程的那部分大腦細胞就得到了充分的休息。當重新開始工作的時候，我會發現那些難題現在竟然可以迎刃而解。

5、對答案的渴求

人類自然科學的發展史就是一個渴求得到答案的過程，即使只能知道答案的一小部分也值得我們去付出。只要你堅定信念，一定要找到問題的答案，你才會付出精力去探索，即使最後沒有得到答案，在過程中你也會學到很多東西。

6、多與別人交流

三人行必有我師，也許在一次和別人不經意的談話中，就可以迸出靈感的火花。多上上網，看看別人對同一問題的看法，會給你很大的啟發。

7、良好的編程風格

注意養成良好的習慣，代碼的縮進編排，變數的命名規則要始終保持一致。大家都知道如何排除代碼中錯誤，卻往往忽視了對注釋的排錯。注釋是程式的一個重要組成部分，它可以使你的代碼更容易理解，而如果代碼已經清楚地表達了你的思想，就不必再加注釋了，如果注釋和代碼不一致，那就更加糟糕。

8、韌性和毅力

這也許是“高手”和一般程式師最大的區別。高手們並不是天才，他們是在無數個日日夜夜中磨煉出來的。成功能給我們帶來無比的喜悅，但過程卻是無比的枯燥乏味。你不妨做個測試，找個10000以內的素數表，把它們全都抄下來，然後再檢查三遍，如果能夠不間斷地完成這一工作，你就可以滿足這一條。

探索產生物件的技巧

探索產生物件的技巧(1)當心隨手New一下引發的衝擊效應 
文/iThome (記者) 2007-08-23 

在程式設計裡，資訊不流通是一件好事。因為一個類別知道的資訊越少，就越不會因為資訊的改變而受到影響。 


在物件導向程式設計中，倚靠的是封裝資料及行為的物件，透過物件所提供的機制以及彼此之間的相互合作，達成系統的需求。因此，產生類別物件就成了物件導向程式中最基礎的動作。在常見的物件導向程式語言中，若要產生某類別的物件，最直接的方式莫過於透過像new之類的關鍵字，例如： 
Object obj = new Object(); 

New的範圍越廣，影響的層面越大 
然而，在實際的設計工作中，好的設計者及程式員，往往會運用更複雜的間接機制，產生所需類別的物件供系統之用。直接使用new語法產生物件，並直接運用會有什麼缺點？為什麼需要引入更複雜的間接機制？ 

先讓我們定義出在物件產生、運用的過程中會需要涉及到的角色：1.被產生者（The Created Class）2.產生者（Creator）3.用戶端（Client）。所謂的被產生者，就是會被產生的物件、產生者便是產生的物件，而用戶端，則是使用物件的另一個物件。 

最常見到的情況，便是用戶兼任產生者的情況。也就是說，因為需要動用到某類別的物件，所以便自己產生一個或若干個該物件，以便運用。例如（以Java寫成）： 
LDAPAuthenticator authLDAP =
new LDAPAuthenticator ();
authLDAP.authenticate(id, passowrd);


如果單單只考慮這樣的應用情境，上述的程式碼是沒有什麼重大的缺陷。不過問題總在改變之後來臨。原始系統也許只需要以LDAP認證，但是也許突然有一天，開發團隊被要求變更系統，讓系統可以允許多種認證的方式，包括讀取資料庫中的使用者帳號資料，或是以客製化方式認證。至於採用那一種認證方式，是設定系統的組態決定。 

設計者也許會考慮選擇提供多種不同認證方式的類別，然後在呼叫時，依據系統的組態設定值，決定究竟要運用那種認證方式，好比如下的寫法： 
boolean fAuthResult = false;
if( authType == LDAP_AUTH )
{
    LDAPAuthenticator authLDAP =
    new LDAPAuthenticator ();
    fAuthResult = authLDAP.authenticate
    (id, passowrd);
}
else if(authType == DB_AUTH )
{
    DBAuthenticator authDB =
    new DBAuthenticator ();
    fAuthResult = authDB.authenticate
    (id, passowrd);
}


但是，這樣的寫法存在一些問題。當你需要增加新的認證方式時，免不了必須修改程式碼。除了要新增類別之外，用戶端的程式也必須同步修改，才能夠將組態設定值，對映到新增的認證用類別，因而使得需求變更的影響層面更大。 

知道的越少，就越不會被影響 
倘若我們改用另一種寫法，針對認證功能制定出一個介面： 
public interface Authenticator
{
   boolean authenticate
   (String id, String password);
}


並為各種認證功能實作其類別，使各類別實作此一介面： 
class LDAPAuthenticator implements Authenticator { }
class DBAuthenticator implements Authenticator { }
class Cusomter1Authenticator implements Authenticator { }


利用另一個類別負責產生提供認證功能的類別： 
public class AuthenticatorCreator
{
   public static Authenticator createAuthenticator() { }
}


那麼需要使用認證功能的程式碼，就能夠寫成： 
Authenticator auth = 
AuthenticatorCreator.createAuthenticator();
auth.authenticate(id, passowrd);


在這個新版的程式碼中，我們看到了一個重大的變化：用戶端並不知道自己究竟產生的物件其確切型別為何，只知道它實作了某一個介面。在這段程式碼中，絲毫看不到new的語法，因為我們拆散了原先合併在一塊的產生者與用戶端兩角色。 

在這個版本中，我們將產生認證類別物件的工作，委派由另一個叫做AuthenticatorCreator的類別執行。所以對用戶端程式碼來說，只需要知道（1）所有實作Authenticator的類別都提供了認證的功能（2）AuthenticatorCreator能夠回傳實作目前系統組態所設定的認證方式類別。因此，用戶端的程式碼妥善地受到阻隔，因為它不需要知道系統組態目前的設定為何，也不需要知道如何對應各種認證功能設定與相對應實作的類別，再者，它不需要知道系統究竟提供多少種認證的方式，而後續新增加認證的方式，也不會影響到用戶端程式碼。 

上述的寫法，善用設計模式（Design Patterns）裡的「針對介面寫程式，而不要針對實作（Program to an interface, not an implementation）」。我們讓用戶端的程式碼存取的是認證的介面（Authenticator），而非存取各式認證的實作（LDAPAuthenticator、DB Authenticator、Customer1 Authenticator…）。這使得用戶端的程式碼，對真正的實作為何，一無所悉。 

在程式設計裡，資訊不流通是一件好事。一個類別知道的資訊越少，就越不會因為資訊的改變而被影響。 

此外，用戶端除了它不知道自己所使用的究竟是什麼之外，它甚至不知道本身所使用的物件，究竟是如何產生出來的！這就是將產生者的角色，自用戶端程式碼中拆開之後得到的好處。 

封裝與隱藏產生物件的邏輯，才能消除物件之間的相依性 
不在用戶端程式碼中直接使用new，為的是封裝並隱藏產生物件的邏輯。而封裝與隱藏，為得是希望能夠消除用戶端程式和它所欲使用的物件之間的相依性，避免當用戶端所使用的物件改變時，會被影響。 

許多人觀察到在各種不同的應用情境下，倘若將產生物件的動作，自用戶端程式碼中抽離，並以特定的方式產生，便能夠從中得到設計的好處。而這類的特定方式，就被整理設計模式裡所謂的「生成模式（Creational Patterns）」。 

各種不同的生成模式，其實都在告訴我們，各種間接產生物件的方式、在不同的應用情境下加以運用，可以得到什麼好處。在後續的介紹中，我將不拘泥於特定的生成模式，而將主題放在產生物件的方式，探討相關的諸般技巧。 

《作者簡介》王建興 
清華大學資訊工程系的博士研究生，研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人，專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同，從ERP、PC Game到P2P網路電話都在他的涉獵範圍之內。