通常我們進入公司以後，不會是重頭開始壹個項目，而是在已有代碼的基礎上進行維護或新功能的開發，所以必須“讀代碼”。
讀有“泛讀”，了解系統架構、功能模塊，對系統有壹個大致的認識，各個功能能找到相應代碼實現的位置。
還有“精讀”，通常就是調試了，在fix bug的時候使用。此外還包括審核：壹些規範壹點的公司，都會有code review，也是精讀，但不用debug。
對於壹個成熟的項目來說，讀代碼——而不是寫代碼——可能是最耗時間的工作了。
寫註釋文檔
為了減少“讀代碼”的時間，我們不得不花時間“寫註釋”“寫文檔”——這個程序員最深惡痛絕的工作。所以現在“爛代碼才需要註釋”的聲音變得越來越強，但無論如何，文檔還是要寫的。（註意：要能區分註釋和文檔）
了解需求
好了，終於到了“寫代碼”的時間了。
然而，在動手開始寫代碼之前，妳必須花時間“了解需求”。和自己寫個小程序玩玩不同，在公司，妳是為別人寫代碼，所以妳壹定要了解別人究竟想實現什麽功能。通常，這並沒有妳想像的那麽簡單，需要反復的溝通。
當然，也有壹些團隊和個人，不願意在這上面“浪費時間”，通常他們的下場就是不斷的寫代碼，然後不斷的改代碼，加班加點的做大量的無用功，整個公司怨氣沖天壹地雞毛。