## 1. 區(qū)分需求的輕重緩急

新手程序員最大的問題就是，在面對一堆需求的時候，不知道哪一個才是重要的，學(xué)會分辨重要的需求是需要一定的經(jīng)驗的，這需要在實踐的過程中積累。于此同時，需求也有是否緊急的區(qū)分，合理安排順序有利于提高工作效率，減少自身壓力。

通常來說，關(guān)于需求輕重緩急的問題也可以和需求方溝通，但是主要注意的是，需求方不一定真正理解自己所提出的需求，也不一定能夠給出正確的安排。

## 2. 學(xué)會發(fā)現(xiàn)偽需求

并不是所有的需求都是有現(xiàn)實意義上的必要性的，這種無意義的需求被稱為偽需求，但又總會有一些這樣的需求提上來。

例如，需求方要求你給一個列表做搜索功能，然而你發(fā)現(xiàn)這個列表的元素個數(shù)絕對不可能達到兩位數(shù)，那么這用十個手指頭就能數(shù)過來的列表，真的有必要做搜索功能？

對于偽需求，我們要做的就給出理由，并拒絕掉。

## 3. 深入理解需求意圖

很多需求方在提需求的時候，是不會明確的表達真實需求的，而是把自己當成了設(shè)計師，自作主張的告訴開發(fā)者要做什么，甚至怎么做。

? 這種需求都不是真實的需求，只是需求方從真實需求的基礎(chǔ)上，提出的自己對于這個問題的理解，以及解決方案。因此在接受需求的時候，開發(fā)者必須主動弄清原始的需求是怎樣的。

? 這樣做至少我認為有兩個好處，一個是不會被需求方帶到坑里去，另外我們自身可以從原始需求上得到更多的信息，在設(shè)計層面留下足夠的擴展性。

## 4. 提高項目決策效率

對于一些項目會議，容易出現(xiàn)冗長的膠著的討論，大家對一些問題看法不一，然后會議就沒有一個終結(jié)的時間。因此，對于一個團隊，必須有一個決策人，在必要的時候終止討論，并給出結(jié)論。

民主還是專制？在項目開發(fā)上來看，讓一個優(yōu)秀的首領(lǐng)決斷，比爭論不休更有意義。

## 5.? 不要重復(fù)造輪子

這是一個聊得挺多的話題，這里就一筆帶過。

? 其實個人也不是說不喜歡造輪子，平時練習(xí)造輪子挺好，項目開發(fā)上來造輪子，百害而無一利（除非你能超越其他輪子）。

## 6. 使用配置代替編碼

用配置代替編碼，有另外一個意思——用代碼來寫代碼。

其實這種思想非常常見，例如很早之前的百度空間（現(xiàn)在已經(jīng)涼了），就給出了自定義模板的功能，我們只需要拖動一些界面元素，就能配置出自己風(fēng)格的空間來。這里面就是用到了用配置代替編碼的思想，開發(fā)者并不需要為每一個博客樣式寫一遍代碼，只需要提供配置的信息，即可生成對應(yīng)的博客樣式。

具體在實際項目開發(fā)中，這種方式能大大減少代碼量，并且降低出bug的概率。

## 7. 不要浪費時間在修bug上

這句話的意思不是說有bug不修，而是說盡量不要讓代碼出bug，如果出現(xiàn)bug也能快速定位問題。

? 《UNIX編程藝術(shù)》里面有強調(diào)一個KISS原則——Keep It Simple, Stupid，意思就是事情能夠簡單辦好，就不要把它弄復(fù)雜。

? 對于一份代碼，它可以是簡單到明顯看不出問題，也可以是復(fù)雜到看不出明顯的問題。

? 日志系統(tǒng)有必須要對系統(tǒng)的運行狀況進行記錄，如果能直接從日志中就能定位問題的話，減少了很多調(diào)試上的麻煩。

? 在代碼bug這個話題上，有一個比較特別的類別，就是系統(tǒng)限制問題引起的bug。也就是說，你的代碼本身邏輯沒有問題，只是數(shù)據(jù)一直增長，導(dǎo)致達到了系統(tǒng)的限制，而導(dǎo)致代碼不能正常工作。

? 例如，騰訊QQ之前的用戶QQ號碼是用32位int類型存儲的，因此它會有一個上限，在之后的一段時間內(nèi)，騰訊不得不對數(shù)據(jù)庫進行升級，使用64位int來存儲。

? 為了減少系統(tǒng)限制類的bug，開發(fā)者有必要做出一些努力，例如良好的內(nèi)存管理，以及對系統(tǒng)規(guī)模的恰當估算等

? 不過現(xiàn)在計算機基本上都是64位了，在大部分情況下，各位完全不用糾結(jié)是用int32還是int64的問題，用int64就好了。

## 8. 擴展性問題

由于需求總是容易變化的，因此面對變化的需求，程序員也需要做一些預(yù)案。

? 例如，參數(shù)能做成可配置的，就不要寫死。如果一個變量可能存在多個，但是需求暫時只描述了單個，那么還是用數(shù)組，說不定哪天就需要支持多個了，現(xiàn)在就支持多個并不會增加太多成本。

? 擴展性問題需要緊緊跟隨真實需求，程序員也需要有一些產(chǎn)品思維，在設(shè)計上預(yù)留出可能的方向，不要在變化來臨時手忙腳亂。

## 9. 性能問題

性能問題是程序員都喜歡討論的一個問題，也是一個學(xué)術(shù)意義上非常重要的問題，但是，在項目開發(fā)中，卻通常是一個不用太在意的問題。

項目的開發(fā)，是成本導(dǎo)向的，我們需要用低成本來滿足項目需求。

項目上線之后，首先要看效果，效果不行的話，自然沒什么用戶，因此也沒性能優(yōu)化什么事。

性能優(yōu)化的時機，不是在項目開發(fā)，而是在項目維護。等哪天用戶量上來了，系統(tǒng)負載越來越高，先加機器，再花點時間研究下性能問題，豈不美哉——至少又做成了一個項目。

性能優(yōu)化有時候會帶來一些負面效果，最常見的就是破壞代碼結(jié)構(gòu)，所以如果不是必須，就別去做性能優(yōu)化。

另外有一種情況，就是代碼寫得太渣拖慢了速度，修改這類代碼不叫性能優(yōu)化，而是叫修bug。