說一下個人的經歷吧，還有一些道途聽說的東西。

先說中小公司吧，畢竟混跡的時間比較長一點。對程式碼，真心沒啥大的要求， 讓你看看阿里開發規範的都偏少。 這個東西沒要求的話，儘量自己也要看一下，注意一下常規的格式之類的。 中小公司講求的，敏捷開發。喜歡招聘剛培訓出來的，大學生，實習生等。經濟實惠嘛，能做的出來就完事大吉。有著是屬於賣產品，外包專案。時間快，成本低。其中入職的一家公司，維護程式碼，新開發的程式碼，彈出層還在用alert。據說是外包做的，對於外包形式不做評價。各種詬病就會成為餐後話題。對於程式碼註釋更是沒啥要求，遇到過公司領導明言，不準寫註釋的。反正就是規則多種多樣。

對於大一些的公司，做自己的專案，要注意的東西就多了一些，畢竟人多了嘛，工作就那些，怎麼也得細化一下不是。就要開始注意開發規範，變數命名，魔法值等等問題。要求程式碼註釋率的問題。也有可能會遇到，以程式碼量作為業績等。稍微來講會規範許多，有著基本的curd.都是由腳手架自動生成了，其他的業務在進行增加。

綜合來講，沒有一刀切的說，誰好誰壞。都是看公司規範，以及個人是否注意。對於程式猿的通病來說就是，自己不願意寫註釋，還罵別人程式碼沒註釋。

多看一些開源的程式碼，入職就會發現不一樣的世界。

有時候兩名開發者的內心恰似當下流行的表情包

程式設計師A：呼呼呼~我就喜歡這樣寫，咋滴

程式設計師A的同事程式設計師B：內心↑

程式設計師B：終於把那個沙雕的程式碼重構好了

程式設計師A妄圖寫出規範似上圖的程式碼

程式設計師A的實際實現↑

程式設計師B：你就天天嘴強王者

程式設計師A：聽說最近有人說我寫的bug多了，那我就……（再接再厲）

程式設計師B：這個我搞定了（程式設計師A內心os：這個簡單的放著我來）

有一說一，有一次我花了一星期寫了個web前端，留下介面就交給後端的同事了。一段時間後我問起來，那位同事跟我說：“我花了兩個星期重構了你的程式碼”

我：。。。

因為專案需要也接觸過幾個技術水平較低的外包程式設計師，emmm，實際上……我感覺他們基本上都不按照規範來。。。然後，如果是我的同事的話，專案中的程式碼我覺得看著很舒服。每個企業的真實程式碼風格都會不一樣（如果凌亂也是一種風格的話），我個人感覺是水平越高的程式設計師寫的程式碼越規範。

這個肯定有區別，企業程式設計的時候你可能負責的是一個小部分，公司的可能整個核心程式碼你都能接觸到，任務也多提升空間也大。

不知道你具體想知道的是什麼答案。

一般來說，就和你在書上，在開源專案看的一樣。

有的時候，內部會有很多平臺和工具，會提供一些更簡單化的“程式設計介面”/“程式設計模式”，甚至程式語言，比如你只需要配置一些XML，你要的簡單功能就能實現。這種情況，你也不需要知道的。注意，實現這些平臺和工具也就用的你知道的程式語言。

現在這個時代，程式語言沒有什麼秘密可言。

在公司中開發的程式碼其實都是差不多的，無非就是增刪改查實現自己需要的功能，只要掌握了那幾個框架，仔細研究了原理實現，其實你會發現，寫程式碼其實很簡單（我指的是簡單的增刪改查的那些程式碼，但是一個系統最多的不就是這些功能嗎？你自己想想），複雜的程式碼其實也是由簡單的程式碼【拼湊而成】，只不過我們有的時候所處在的階段不同，比如說剛畢業的大學生或者工作一年的程式設計師就會覺得那些三年工作經驗的大佬寫的程式碼很牛逼，自己怎麼都看不懂，但是如果你們到了三年工作經驗的這個階段，你會發現，這都什麼啊，這麼簡單的程式碼。

不要覺得在公司中開發的程式碼很難，我覺得反而很簡單，有的時候實現一個小小的功能程式碼寫起來真的很簡單，但是你要想著如何證明把自己的程式碼寫到最佳（用最少的程式碼，實現其功能，不存在程式碼冗餘或者過多的耗費效能的操作）。

總體來看，實現功能就行。

細分來講，不同級別的人實現層級不一樣。

新手：立馬上手，貼上複製，改bug。

中級：思考設計佔三成，開發四成，改bug三成。

高階：思考設計佔六成，開發三成，改bug一成。

組長：開會六成，催進度合併週報四成。