軟體開發中的注意事項)

1、項目設計

項目設計的主導思想，我覺得可以理解為兩種，一種是完全設計，一個是簡單設計。

完全設計是指在具體編寫代碼之前對軟體的各種方面都調查好，做好詳細的需求分析、編寫好全部的開發文檔，設計出程式全部流程後再開始寫代碼。 換句話說，就是全部的計劃好了，能看到最終的樣子，再開戰。這好像也是很多“軟體工程”書裡要求的那樣。開始的時候，我覺得這種方法不錯也。什麼都計劃好了，照著做就是了。不過這裡有個明顯的問題，就是誰來做這個完美的計劃？估計只有及其BT的人了，但是大部分人的想要完全設計，並且沒有錯誤，或者已經有幾種後備的容錯方案，並能準確無誤的推行。以達到最終目標。這樣的境界，沒有很多年的工作經曆是不可能的。我也沒有這樣的本事，所以我也就放棄了這種想法。

簡單設計：簡單設計一種概念，一種可以接受的簡單的設計，最起碼資料庫已經定下來，基本流程已經確定的方案，來作為程式設計的開始，並隨時根據實際情況的進展來修正具體的功能設計，但這種功能修改不能是修改資料庫結構。也就是說資料庫結構是在編程之前經過反覆論證的。這種方法減少了前期設計的時間，把代碼編寫工作和部分設計工作放在了一起，實際縮短了項目開發的時間。如果說完全設計方法要求有很厲害的前期設計人員，那麼簡單設計要求有很有設計頭腦的編程人員。編程人員不僅僅是K代碼的人而且要負責程式架構的設計。所以對程式員的要求就很高了。 簡單設計的成功的一個基點是編程人員設計的邏輯結構簡單並能根據需要來調整其邏輯結構，就是代碼結構靈活，簡單設計帶來的另外一個變化就是會議會比較多，編程人員之間的交流就變的很重要。現在一般的中小型軟體公司基本上都是採用簡單設計的，除非那些很大型的軟體公司。

總結，簡單設計考驗的是開發人員的能力。完全設計考驗的是前期設計人員和整個項目組完整能力。(各種文檔的編寫，開發人員一定會要寫一部分的。)

2、設計變化和需求變化

開發人員最怕的是什麼呢？設計變化，還是需求變化？我覺得需求變化是最最致命的。當你的一個項目資料庫都定下來後，而且已經開發了若干個工作日，突然接到甲方公司提出，某個功能要改變，原先的需求分析要重新改，如果這個修改是涉及的資料庫的表結構更改的話，那真是最致命的。這就意味著項目的某些部分得重新推倒重來，如果這個部分跟已完成的多個部分有牽連的話，那就後果更可怕了。所以當碰到這種情況發生，作為專案經理的你就應該考慮先查責任人，究竟是自己的需求分析做的不夠好，還是客戶在認同了需求分析後做出的修改，如果是後者的話，你完全可以要求客戶對他的這個修改負責任！那麼，呵呵，客戶先生，對不起了，本次新增加的需求將歸入另外一個版本。如果是改變前面某個需求的定義，那麼說不定就要推倒重來了，不過這個時候到不用太在意，畢竟錯的是客戶。(項目正式開始前沒有沒有說清楚其需求)。所以，各位看客，在需求分析做好後，在開工之前一定要叫客戶認可簽字，並且在合約上要註明，當由客戶原因引起的需求改變而造成開發成本的增加，客戶要為此買單地。

如果在需求不變的情況之下，設計發生了變化，這個僅僅是我們內部之間的矛盾，商量一下就能解決。在簡單設計中，因為前期的設計是不完整的，那麼當進入任何一個新的模組進行開發時，都有可能引起設計的變化。開發人員的水平的高低就基本上決定了軟體的好壞。

3、代碼編寫

當需求定下來資料庫也定下來後， 其實我們就可以進行實質性的編碼了，按照我的看法，一個人單獨編程最好，能隨時偷懶。(上網，和MM聊聊)，但是現在的軟體項目越來越大，工期也越來越緊，事實上我們一個小組裡面，一般有3-5程式員，所以我們要強調團隊合作性。那麼你寫的代碼使得別人要能夠看懂，我們必須在實際的編寫代碼過程中要有詳細的編碼規範，編碼規範在很多書籍裡面都提到過。但最起碼以下的一些規範是我們必須要遵守的：

一）來源程式檔案結構：

每個程式檔案應由標題、內容和附加說明三部分組成。

（1）標題：檔案最前面的注釋說明，其內容主要包括：程式名，作者，著作權資訊，簡要說明 等，必要時應有更詳盡的說明（將以此部分以空行隔開單獨注釋）。

（2）內容控制項註冊等函數應放在內容部分的最後，類 的定義按 private 、 protected 、 pubilic 、 __pubished 的順序，並盡量保持每一部分只有一個，各部分中按資料、函數、屬性、事件的順序。

（3）附加說明：檔案末尾的補充說明，如參考資料等，若內容不多也可放在標題部分的最後。

二）介面設計風格的一致性：

由於採用可視化編程，所有的介面均與Win32方式類似，相應採用的控制項等也大都為Windows作業系統下的標準控制項，而且參考了其他一些市面上相關的企業內部管理的應用軟體。

基於簡單易操作的原則，貼近使用者考慮，使用者介面採用Windows風格的標準介面，操作方式亦同Windows風格，這樣在實施過程，可以降低對客戶的培訓，也可以使使用者容易上手，簡單易學。

三）編輯風格：

（1）縮排：縮排以 Tab 為單位，一個 Tab 為四個空格大小。全域資料、函數 原型、標題、附加說明、函數說明、標號等均頂格書寫。

（2）空格：資料和函數在其類型，修飾（如 __fastcall 等）名稱之間適當空格並據情況對 齊。關鍵字原則上空一格，不論是否有括弧，對語句行後加的注釋應用適當空格與語句隔開並儘可能對齊。

（3）對齊：原則上關係密切的行應對齊，對齊包括類型、修飾、名稱、參數等各部分對齊。
另每一行的長度不應超過螢幕太多，必要時適當換行。

（4）空行：程式檔案結構各部分之間空兩行，若不必要也可只空一行，各函數實現之間一般空兩行。

（5）注釋：對注釋有以下三點要求：

A、必須是有意義；

B、必須正確的描述了程式；

C、必須是最新的。

注釋必不可少，但也不應過多，以下是四種必要的注釋：

標題、附加說明；
函數說明：對幾乎每個函數都應有適當的說明，通常加在函數實現之前，在沒有函數實現部分的情況下則加在函數原型前，其內容主要是函數的功能、目的、演算法等說明，參數說明、返回 值說明等，必要時還要有一些如特別的軟硬體要求等說明；
在代碼不明晰或不可移植處應有少量說明；
及少量的其它注釋。
四）命名規範：
堅持採用匈牙利變數命名慣例，所有標識符一律用英文或英文縮寫，杜絕採用拼音，標識符中每個單字首大寫，縮寫詞彙一般全部大寫，只在必要時加“_”間隔詞彙。

4、BUG修補

程式出現了BUG誰來修補呢，嘿嘿嘿……

最好的辦法是誰編寫誰修補，誰改壞誰修補。一個人改壞的代碼一人去修。兩個人一起改壞的代碼兩人一起修。

5、開發人員的測試

開發人員的測試是保證代碼能正常運行，在開發時候發現的錯誤往往比較容易修正。(另外一個好處就是沒有人來罵你。因為只有你自己知道)。但是一旦軟體到了測試小組那裡出了問題，那麼就多了很多時間來修正BUG，如果到了客戶哪裡才發現的BUG，那麼時間就更長了，開發人員本身受到的壓力也是到了最大話了。客戶->公司->測試小組->開發人員。 這個完全是倒金字塔型的，承受能力差的一環很容易出事情的。

另外開發人員的測試除了保證代碼能正常運行以外，還有一個很重要的方面就是要保證上次能正常啟動並執行代碼，這次還是能正常運行。如果做不到這點，那麼BUG就不斷的會出現，很多BUG也會反覆出現。於是軟體看上去就有修補不完的BUG了。如果出現這種情況，那麼開發人員有必要再教育。一般公司教育的方式有四種。第一種，扣工資，第二種，加班，反覆加班+精神攻擊。 第三種，開除。第四種，調動人員來協助那個出了麻煩的傢伙。 但願看這個文章的人不要受到前面三種教育。