以程式設計師的視角，就軟體開發談自己的看法
我常關注的有兩點：程式的質量和開發的效率。
1從程式設計師本身來看，程式設計師得不斷修煉內功：（1
）從語言層次考慮，要掌握語言的特點。例如，
c++，值變數、引用變數、指標的各自定義與區別等等。特別是指標，怎麼避免野指標？為什麼帶虛函式的基類的釋構函式必須是虛函式？建構函式的引數初始化列表裡，執行時，各個引數初始化的順序是從左到右還是從右到左的？為什麼要注意這個？如果用的是
c#，相對
c++來說好一些。但還是有很多需要注意的。例如，觸發乙個事件前，是否檢查了事件物件是否為空？以及類似情況，以避免執行時異常。使用資源一類的物件是否記得遲建立，早釋放？這些都要盡可能地搞清楚，以致一用某個語言的時候，腦袋已經警惕起各種陷阱了，從而達到保證程式質量的效果。對語言特點的理解很明顯提高開發效率。否則，〔＋舉反例說明，怎麼會引發錯誤，增大測試、等位、修復問題的成本〕
熟悉語言配套的類庫或函式庫。例如用
c++，基本的需要熟悉
stl，熟悉
mfc。否則，
〔＋怎樣降低了開發效率和程式質量，例如重複寫**〕（2
）從寫**層次考慮，需要良好的**風格。這一點，是非常淺顯而重要的，有現成的參考。我就不多談。對於剛畢業的程式設計師來說，更需要注意，因為課本的示例**、實驗課寫的**是不規範的。我想提的乙個有趣的東西是，對於微軟的那套東西，我發現
msdn
上有命名規範。《
code complete
》裡面「自說明**」這個主題中也有很好的講解。另外，我曾見過有本外國的很詳細的指導如何寫規範**書，讓我感觸的是，人家怎麼就那麼有精力、心思總結出這麼簡潔而全面的指導來？
2從團隊的層次考慮。需要注意團隊的協調、合作。說到這點我有點心虛了，因為我從未擔任過組長。（＋加謙虛一下，例如「我僅僅是從自身的體會和觀察來看。張曉等同事可以對這點多多批評。」）我細說一兩點。乙個團隊，需要有擔任任務分配、時間安排、跟蹤進度、落實編碼標準、**審查、內部測試的角色存在。這個角色通常是有組長來擔任。在任務分配方面，我覺得要注意的是，需要掌握團隊各個成員的能力水平、專注點。否則，（＋出現的各種不良情況）。如何合理定預計時間，我想這個比較困難的。我覺得這個時間預計時間是有個不斷調整的過程，以逐步逼近準確值。另外，初步的預計時間定製準確程度依賴於組長對專案的熟悉程式、依賴於和成員的溝通、依賴於對過往任務完成時間的參考。如果組長沒有先熟悉專案而定時間，那麼可以馬上忽略這個時間值，根本不具參考價值，即使是預計對了，也是等於在文明大都市踩中了狗屎一樣——只能說運氣實在太好了。當然，這是極端情況了。和程式設計師溝通這一方法我想很多情況都做到。拿過往任務完成時間來參考，這個我覺得有必要說說。如果，分配到成員的任務描述、完成時間都有所記錄的話，那麼，這些資料對預計時間很有參考價值。組長可以從巨集觀的角度檢視，可以大概知道哪些型別的任務，哪個人完成的大概時間是多少，算起來有所依據。當然，前提是——有記錄，並且在有測試的情況下，這個完成時間才有意義。草率給出預定時間，很容易引起矛盾。如果到期未能完成，要兩面地看，可能是成員效率低；可能是預計時間定製者計算有誤——對任務艱鉅程度預計不足，對人手安排不足，或者是任務分配不合理（＋簡要舉例怎麼分配任務是不合理的）。所以，如果簡單地一定預計時間就必須要求程式設計師按時完成，完成不了就一定加班。這是不對的，是不科學並傷感情的。預計時間和成員的開發效率都是需要不斷調整的。**審查方面，張曉那塊已經實施，他們是每週一進行的。我以前所在的團隊，**審查的週期是間隔１到４天。一般是組長在下班前開始。大家將要簽入**的時候，組長逐一審閱，並提出修改意見。有時是大家交換審閱。總之，可以保證每天簽入的**是不會有低階錯誤的，很多結構不良、筆誤的**常在這一環節剔除掉了。**審閱後，緊接的就是獲取新版本，編譯，進行粗略的內部測試。通常是大家交換測試——我測試你做的功能是否做好了，是否有錯誤。這樣就達到保證每一次簽入了**，都有乙個可交付的程式出來。而且，預計完成時間的到來變得不是那麼可怕了，哪怕我功能未全部完成、問題未完全修改完，至少每一天都有個可用的程式，保住了這個底線，大家就有底氣了。這樣，達到小步子控制程式質量，是精耕細作的。順便說的就是，**審查的時候，往往會有反覆，在審查的時候就發現問題，提出意見並修改好後才能簽入。而這個過程往往能提高大家寫**的水平的。可以說，在這個環節，程式質量、開發效率和程式設計師的學習進步是最統一的。由此可見，在控制程式質量和開發效率方面，組長這個角色的任務是繁重的，又是那麼需要全體成員配合的。上述的措施對於控制程式質量、提高開發效率是必要的。當然這個不是我想出來的，是我看到的，親身經歷過的，並經過實踐檢驗的。
再者，乙個團隊的開發，注意短板效應——經驗不足、能力水平不夠的程式設計師往往會對程式質量、開發效率有一定程度的制約。（＋舉例說明）。那怎麼辦？需要老程式設計師（不一定是組長）帶。這樣，既保證程式質量、開發效率，又能促進這些程式設計師的進步。
順便提一下，我以前的團隊，開始的時候，常出現組長忙得冒煙，而有些成員卻在一旁涼快的現象。造成這樣的情況通常是組長沒有認識到自己全域性調動大家的生產力才是最主要的。後來我向組長提出這個問題後，形式很快改觀。當然也有個別情況，就是某項任務只有組長有水平解決，其餘人只能看著乾著急。這是另當別論了。
4從程式設計師綜合素質看。（１）需要提高自己的嗅覺——敏感地嗅出程式中的某些部位的臭氣。《
code complete
》裡面有些段落非常有趣，例如說某某形式的**，運用某某定律，可以判斷如何不脫。簡單地看，乙個函式、類**量過大（有人統計這個邊界值）就很值得懷疑有錯誤，（＋感性的分析）。這個是需要避免的，對於已存在的情況，可以適當重構。（
2）修改ｂｕｇ的時候能舉一反三。
5從開發流水線上，編碼的下乙個環節——測試來看。必須保證足夠的測試。我的觀點是，這關是避不了的。即使省略了說著力度不夠，那麼到了客戶那裡，該是要該的ｂｕｇ還是要改。測試也是制約程式設計師的好方法。題外話，那測試誰制約——客戶。否則，程式設計師很容易蒙需求。
軟體開發 程式設計師是不是青春飯
任何技術含量低下的工作其實都是青春飯，很容易被取代。對於軟體行業來說，只有低端的程式設計師才會面臨青春飯的問題，該層次人數最多，技術含量低，競爭最激烈，隨著技術的進步，老舊思想和技術的程式設計師最容易被取代。中高階的程式設計師作為行業的中堅力量，人數相對較少，處於賣方市場，競爭並不不激烈，所以相對來...
程式設計師應該了解的常見軟體開發定律
程式設計師應該了解的常見軟體開發定律 軟體開發領域最著名和最常見的定律 墨菲定律 murphy s law 可能是最著名的定律之一，主要是因為它不僅適用於軟體開發。如果事情可能出錯，它就會出錯。第乙個推論 那些有效的 你可能反而沒有寫出來。第二個推論 詛咒是唯一一門所有程式設計師都能流利說出來的語言...
資深軟體開發師對「年輕」程式設計師的忠告
1 好好規劃自己的路，不要跟著感覺走 根據個人的理想來安排自己的生活，絕大部分人並不指望成為什麼院士或教授，而是希望活得滋潤一些，痛快一些，那麼就需要慎重安排自己的的軌跡，從乙個行業入手逐漸對該行業深入了解，不要頻繁跳槽，特別是不要為了一點工資而轉移陣地，從長遠看，這點錢根本不算什麼，當你對乙個行業...