程式員之一 態度

你，剛畢業，什麼都不會，但是你卻很幸運的進入了一家軟體公司，獲得一個工程師的職位。上司一般都有它的考慮和矜持，為了保住工作，你得在規定的時間裡實現一些功能模組。幸運的是，系統已經有一些部分能夠給你作為參考，像抓住救命稻草一般，拚命的模仿與拷貝。最後東拼西湊的出現一個功能，還夠用。

這時候問題來了，大部分公司都沒有專門做代碼審查的人。專案經理一般都是要求技術負責人關注這塊。而負責人整合、部署、測試、發布、備份、文檔、工作計劃、總結、需求、會議一大摞的事情壓得喘不過氣，可能根本沒看cvs上的代碼，功能ok一般就發布了。事後又沒有程式碼檢閱會。就這樣，你很幸運的留在了公司，這種不嚴謹的開發方式，讓你覺的程式員也就這麼回事。閒置時間裡，你聊qq、看微博、瀏覽新聞，灌論壇。很悠閑的一天。

某個早上，需求變了，負責人告訴了你，你覺得這很簡單，其實本就很簡單。將原來的班級管理員統計班上各科平均分的功能擴充一下，讓學校也可以統計全校的各科平均分。一個if/else就搞定了。在mvc結構的掩護下，還算很清晰。你又繼續開始了你悠閑的生活。

使用者總不是那麼好打發的，需求繼續變化，鎮區可以統計、縣區可以統計、市管理員也要統計。Omg,有人居然能寫出6個if/else。可恨的是這也發布並運行到了真實環境下。

不知你是否會愧疚，你的主管是否內疚。我相信在競爭這麼激勵的環境下，任何一個系統不會今年開發，明年就捨棄。為了盈利，老闆總想著做成產品推廣出去。試問，這樣的代碼怎麼應付得了客戶的需求。比如，被推廣的地市，班級和學校要統計更多的標的。你難到加更多的if/else?說了這麼多，其實我是在鄙視自己。很多時候我就是這麼做的，並且還要為自己辯解，是工作太忙沒有時間才這麼弄的。

5年了，記不清自己寫了多少行代碼，或許哪一天你在維護時，看到了。晦澀難懂，請不要罵我，畢竟我在改變。是的，要寫出好代碼，態度真的很重要。

   一個程式員，應該要時刻謹記物件導向的思想，抽象、封裝、繼承、多態。物件導向設計的6大原則，單一職責、裡氏代換、依賴倒置、介面隔離、迪米特法則、開閉。對待代碼要像對待自己的銀行賬戶那樣認真。

當你要提交一個功能時，應該要做最起碼的幾項檢查，

1， 
類的程式碼數是否適中

2， 
方法，是否一電腦屏能顯示，方法名是否恰當

3， 
類的職責是否明確，提供的public方法是否嚴謹

4， 
是否有遵守物件導向的準則。

做到這些，我覺得就可以勝任一個初級程式員了。