這個問題比較粗糙，大概說一下

1、量

公司項目有目的性，所以你所能接觸的，一般是需要修改的部分代碼片段，譬如做后臺開發或者算法開發，在單元測試內跑通之后就可以提交了。不會看到特別多的代碼的，就像需要修路，那么哪有問題你就修哪里，給你的工程圖就是龐大的路中的這一段。這樣有利于對接。

2、規范

公司為了后期維護，會將代碼編寫做好規范，譬如之前阿里推出的java編寫規范。會把特定的接口寫好，新添加功能也要按規定編寫，修改的或使用接口的也要按照規范填寫log做好記錄。每次修改刪除和添加都會有特定的人員進行監督，防止對整個系統造成破壞。

3、紀念

代碼會經過多次迭代，不停修改打補丁做拓展。為了有追溯性，每一代代碼都會有所保留，同樣，編寫代碼的人也會將名字留在代碼注釋中。我在公司就經常會修改主管領導當年的代碼……慘，期望自己寫的不會再被人改……

4、less is more

簡單永遠不為過，但太簡單又成為負擔。有人說我能用一句話運行出結果，就不會用大段代碼。但這樣會影響復用性，導致每次遇到問題都要造車子。所以，恰當的簡單往往比較受公司青睞。當然這個“大局意識”就交給team leader管就好了，咱們PG就耐心做編程聽話就可以了。

就想到這些，先說這些，在理論上應該明白了吧~至于真正的代碼嗎……web代碼用F12就能看，后臺的話還是算了吧

我也想知道！