做一個“有資格”程式猿

標籤：

其實這篇文章是很早就想寫一，一直忙到沒時間，今天終於是空的，繼本職業工作方案談猿我個人的一些想法：

要想做一個我覺得是“親密格”程式猿。該要做到下面幾點：

• 代碼規範，凝視清楚

要做一個好的程式猿，代碼的品質是最重要的，代碼是項目過程中最為重要的資源。有非常多程式猿認為寫凝視太麻煩，還會花太多時間，尤其是非常多規模比較小的公司，更不會注重這一點，可是往往到了項目後期。乃至項目由他人接手後，維護的成本會變得非常高，代碼閱讀困難，凝視不具體甚至沒有。維護人員須要靠自己去推測某個方法的具體功能。

在這我要說的是，當你習慣了寫凝視。並且習慣了標準的命名規範後，你會發現後期的維護成本會大大降級。並且在寫某個方法時會順手就將凝視寫清楚。這根本佔用不了多少時間。非常多大公司或者說是比較注重效率的公司都會看某個程式猿的代碼品質，所以養成一個好的編程習慣是非常重要的。

• 不要怕麻煩。偷懶是大忌

在我接觸的非常多程式猿裡，我發現偷懶的比較多，有人可能不太明確我說的偷懶是什麼意思，舉個最簡單的範例，當做一個要返回上一頁的功能的時候，有些程式猿為了偷懶直接用了go(-1)，可是殊不知這種使用方法常常會導致跳轉錯誤，看上去一個不起眼的小問題。可是往往會影響整個系統的品質。

為了以完畢任務為目標，而不去注重實現的嚴謹性和實現的合理性，偷工減料，這種程式猿我相信沒有一個專案經理會喜歡。

• 代碼邏輯要嚴謹。不能僅僅靠主觀推斷

在這裡我想先舉個範例，非常多人都會用ajax做get或者post請求。設定返回的類型為json類型。那麼在去處理這個json資料的時候大家想到的第一步應該是什麼呢，依照我的編碼習慣，我會首先去推斷該json對象是否為空白，然後依次推斷須要讀取的鍵值是否存在。僅僅有在存在的情況下才會去調用，同理在後台java代碼中，每一個對象在被調用之前我都會加上對象是否為空白的推斷，我想有了這個習慣之後。出現null 指標異常的情況會寥寥無幾了。有些人會說我知道那個對象肯定不會為空白，這裡我想說的是軟體這個東西有非常多是無法預測的，既然可以做到嚴謹。可以將可能出現的情況都避免掉，那豈不是更好麼。

• 做一個有“思想”的程式猿

上面說了那麼多都是跟編碼相關的，那麼最後我最想說的，或者說感覺最重要的一點就是我們不能做一個僅僅會寫代碼的”機器人“。有非常多程式猿都是僅僅管依照專案經理給定的設計方案去做編碼。哪怕這個設計方案是有缺陷的，或者說壓根就是不合理的，當專案經理反應過來有缺陷須要修改時。那麼你之前開發好的又得去返工，程式猿最害怕的是什麼。我想大家都清楚，那就是不斷的變更需求，變更設計方案，而導致做無用功，寫無用代碼。

在我前幾年做開發的過程中，我每做一個功能時都會去想，這種設計究竟合不合理，這種邏輯究竟對不正確。假設不正確，那麼換成我應該怎麼去設計，然後將我的想法反饋給專案經理或者項目總監。大家經過討論後確定了合理的方案後再進入開發。這樣能夠大大降低返工的機率。

這個時候有人會說了，我們的專案經理或者項目總監、產品總監從來不聽我們程式猿的想法，那麼我僅僅能說抱歉，你跟錯人了。

我一直跟我們的程式猿灌輸著一個理念。專案經理也是人，有時候我們想的不一定是最全面的，在他們開發的過程中能夠隨時提出自己的想法，我們能夠針對每一個提議進行會議討論，進行頭腦風暴。來確定最優的方案，這個對程式猿能力的提高，對項目的品質都是有極大優點的。

好了，今天就先寫到這吧。以上僅僅是個人從事開發以及專案管理七年多的一些個人經驗。拿出來給大家分享下，歡迎大家指正！



著作權聲明：本文博主原創文章，部落格，未經同意不得轉載。

做一個“有資格”程式猿