淺析非軟件行業(yè)人員自主開發(fā)的不良習慣及改進建議

吳浪

摘要：介紹非軟件行業(yè)人員自主開發(fā)本行業(yè)內(nèi)軟件的優(yōu)勢和在軟件開發(fā)的需求采集、系統(tǒng)設(shè)計、編碼、測試等方面容易出現(xiàn)的一些不良習慣，以及如何揚長避短的幾點改進意見。

關(guān)鍵詞：業(yè)余程序員；軟件開發(fā)；不良習慣；行業(yè)標準；改進建議

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2016）04-0102-02

Simple Analysis of Bad Hadit and Improvement Measure when a Junior Software Developer Developing Software

WU Lang

（501 Station of the GAPPRFT，Kunming 650302，China）

Abstract： Analysis of some bad hadit and improvement measure of equirements Analysis， system design，software coding and software testing when a Junior software developer developing software.

Key words： junior software developer； software development； bad hadit； industrial standards； improvement measure

近年來隨著計算機技術(shù)的普及，各行各業(yè)內(nèi)都有自行開發(fā)的各種軟件，廣電系統(tǒng)由自己的職工進行了不少的優(yōu)秀的自主開發(fā)。各種類型的自動化控制系統(tǒng)、節(jié)目播出監(jiān)測系統(tǒng)、辦公自動化系統(tǒng)等。這些系統(tǒng)的投入使用和穩(wěn)定運行，提高了各機關(guān)、臺站干部職工的工作效率，提升了設(shè)備運行的穩(wěn)定度，在一定程度上把廣大干部職工從手動操作的繁瑣工作中解放了出來。

由各單位的職工自主開發(fā)系統(tǒng)有很多優(yōu)點：首先是節(jié)省成本，更重要的是我們更了解自己的設(shè)備和工作細節(jié)，更容易清楚地知道我們想要的東西是什么樣的。在開發(fā)中可以輕松達到無障礙溝通和協(xié)作，能更好地做好開發(fā)的需求分析、系統(tǒng)設(shè)計，后期維護也更為方便。

缺點在于我們是業(yè)余開發(fā)人員，開發(fā)過程中容易有很多不良習慣：這些不良開發(fā)習慣可能造成資源浪費，加大軟件維護的成本，有些甚至制約整個系統(tǒng)的生命力。在軟件開發(fā)過程中，大多數(shù)的問題都是由這些需求分析、軟件設(shè)計和編碼的不良習慣造成的，改變這些習慣，你會獲得更高的效率。

1 業(yè)余程序員容易出現(xiàn)的不良習慣及改進建議

軟件開發(fā)流程一般包括以下幾個步驟：需求分析、系統(tǒng)設(shè)計、編碼、測試、投入使用、后期維護。下面我們從一步步來探討業(yè)余程序員容易出現(xiàn)的不良習慣及改進建議。

1.1 業(yè)余開發(fā)人員容易不夠重視需求分析和總體設(shè)計

我們雖然更了解我們的設(shè)備和工作細節(jié)，更容易進行需求分析和軟件設(shè)計。但是業(yè)余開發(fā)人員也容易不太重視需求分析和總體設(shè)計，比如需求分析和總體設(shè)計花的時間和精力不足，很多內(nèi)容停留在大概、差不多的層面，沒有具體化、細化、完整化、文檔化，隨后就開始匆匆編碼。認為我們可以一步一步來，先編寫一些程序出來，有什么沒想到的地方再慢慢改。編碼過程中突然想起來還有什么需求或者使用者提出之前沒想到的需要，又來改編碼。就這樣不斷進行很多次的修改。這樣最終也可能能把系統(tǒng)開發(fā)出來，但是這樣的系統(tǒng)執(zhí)行效率低下。開發(fā)軟件的最忌諱不停的因改需求而改代碼，尤其是在軟件開發(fā)后期該需求極容易導致程序修改遺漏內(nèi)容、變量錯誤等等問題，導致系統(tǒng)執(zhí)行過程中出現(xiàn)異常報錯、軟件跑死等現(xiàn)象。如果急于動手編碼，而忽略需求分析，很可能南轅北轍，使開發(fā)變得毫無意義。需求分析才是整個開發(fā)過程中的核心部分，正所謂“磨刀不誤砍柴工”。只有真正理解了需求，才能順利開發(fā)出我們真正需要的軟件。

采集需求時，有必要時可以對客戶進行一定的培訓，讓他們知道怎么提需求，怎么把需求提的更加具體、準確、完整，在這個階段多和客戶溝通，盡量避免或減少開始編碼后改需求，以及因此導致軟件編碼錯誤和運行效率低下等問題。

需求分析中的需求不只是使用者的需求，還要按照行業(yè)內(nèi)的軟件開發(fā)規(guī)范來進行，同時也要考慮軟件長遠運行的硬件、軟件環(huán)境等因素。例如，目前Windows XP已經(jīng)停止升級了，你還在XP平臺下開發(fā)軟件，當你千辛萬苦地開發(fā)完成提交系統(tǒng)時發(fā)現(xiàn)大家都在用WIN7甚至是WIN10。你的軟件可能無法運行。

軟件設(shè)計正如你要造一幢房子，在開始砌第一塊磚之前，你必須事先畫好建筑圖與藍圖，在你開始澆鑄水泥之前，你必須讓人評審的藍圖并獲得通過，你要先做好比較完整詳細的設(shè)計再進行后面的工作。另外要學習行業(yè)內(nèi)制定的相關(guān)規(guī)范和標準，并嚴格按標準檢查你設(shè)計的系統(tǒng)，只有這樣你最后開發(fā)出來的系統(tǒng)才能與業(yè)內(nèi)其他軟件系統(tǒng)完美整合為一個整體，流暢交互數(shù)據(jù)，同時還保證了系統(tǒng)的通用性。

1.2沒有良好的文檔習慣

我們在談編碼前不得不提的是要養(yǎng)成良好的文檔習慣。良好的文檔是正規(guī)開發(fā)流程中非常重要的環(huán)節(jié)，一個好的程序是先寫好設(shè)計文檔再進行編程的。如果你不寫文檔，一開始就寫程序，這樣你就不會按已設(shè)計好的路線走，而是想到哪寫到哪。尤其是部分剛開始編程的人容易有如下的代碼習慣，如：學會一招，就用一招，不管方法是不是適合系統(tǒng)，硬塞進去。小功能還好說，要是大功能，就容易混亂甚至失控。寫文檔時只要能將你的設(shè)計思想及實現(xiàn)算法或步驟描述清楚就好，另外要善于利用圖表來說明你的思想。

1.3編寫代碼時容易有不進行格式化、規(guī)范化、加備注、模塊化等習慣

對代碼進行縮進或統(tǒng)一格式，可以讓人更容易閱讀，也容易對錯誤進行定位，不易出現(xiàn)混亂與bug，另外也方便代碼審查等等。代碼備注也很重要，很多業(yè)余程序員不喜歡在代碼里加備注，覺得麻煩，覺得自己完成了自己的模塊就行。事實是躺在代碼行里的備注永遠躺在代碼行里，而躺在腦海中的備注卻會在日復(fù)一日的工作中去留無蹤。無備注，無規(guī)范無疑是害人害己的代碼習慣。對代碼格式化，可以考慮使用代碼美化器，它能根據(jù)你的設(shè)置對代碼進行格式化。

面對沒有模塊化的代碼就像是一個亂搭起來棚子，沒有一處敢輕易地修改，系統(tǒng)脆弱，而且隨著時間的推移，其維護越來越困難，埋下大的隱患。讓每個函數(shù)實現(xiàn)且只實現(xiàn)一個功能，這樣會讓函數(shù)更短，相應(yīng)的就好理解和維護。比較長的函數(shù)里面通常有很多路徑，這對測試來說也比較難。

1.4代碼沒有清晰地表達意圖

編寫代碼時，應(yīng)該更注重可讀性，而不是只圖自己方便。代碼被閱讀的次數(shù)要遠遠超過被編寫的次數(shù)，所以在編寫的時候值得花點功夫讓它讀起來更加簡單。

1.5不把警告當錯誤看

代碼編譯時產(chǎn)生了警告，我們還是可以運行程序。那么如果我們忽略警告信息繼續(xù)開發(fā)代碼，會怎么樣呢？這樣做等于是坐在了一個嗒嗒作響的定時炸彈上，而且它很有可能在最糟糕的時刻爆炸。代碼的行為會變得無法預(yù)測，其質(zhì)量會直線下降。

解決方法是設(shè)法讓編譯器將警告作為錯誤提示出來。如果編譯器允許調(diào)整警告的報告級別，那就把級別調(diào)到最高，讓任何警告不能被忽略。這個小小的設(shè)置，可以大大提升團隊簽入到源碼，控制系統(tǒng)中的代碼質(zhì)量。

1.6提供有用的錯誤信息

當應(yīng)用發(fā)布并且得到使用之后，仍然會發(fā)生各種問題。比如計算模塊出錯，與數(shù)據(jù)庫服務(wù)器之間的連接丟失。這些情況要盡量以優(yōu)雅的方式進行提示或處理。如果你注意的話，在開發(fā)階段就能發(fā)現(xiàn)這個問題的早期警告。當出現(xiàn)錯誤時一方面要提供給用戶清晰、易于理解的問題描述和解釋，使他們有可能尋求變通之法，而不是讓系統(tǒng)自己報一些讓使用者完全看不懂的錯誤信息。

1.7不夠注重軟件測試

部分業(yè)余程序要容易忽略軟件測試的重要性，軟件編碼完成后簡單試運行，基本功能正常就上機了。這樣可能導致的問題不言而喻。軟件測試方面應(yīng)該投入的足夠的精力和工作量，通過測試和修改把軟件的一些錯誤提前排除掉，力爭正式使用后穩(wěn)定、可靠、準確的運行。系統(tǒng)測試的對象不僅僅包括需要測試的系統(tǒng)的軟件，還要包含它所依賴的硬件、外設(shè)甚至包括某些數(shù)據(jù)、某些支持軟件及其接口等。因此，必須將系統(tǒng)中的軟件與各種依賴的資源結(jié)合起來，在系統(tǒng)實際運行環(huán)境下來進行測試。有很多錯誤要在真實運行環(huán)境下才能得到比較全面的暴露。必要時要邀請軟件使用者參與測試。

有些行業(yè)內(nèi)的大部分軟件規(guī)模都不大，但是同樣需要嚴格的軟件測試，以保證它的可靠性。對于一些要求比較嚴謹?shù)墓ぷ鳝h(huán)境，稍有失誤可能不但不能提升我們的工作效率和質(zhì)量，反而導致設(shè)備運行事故也是有可能的。

1.8不注重系統(tǒng)內(nèi)統(tǒng)一制定的標準和規(guī)范的學習和執(zhí)行

不嚴格遵循系統(tǒng)內(nèi)的規(guī)范進行開發(fā)，所開發(fā)的軟件沒有標準化，導致和系統(tǒng)內(nèi)其他軟件整合后經(jīng)常出一些異常錯誤，甚至無法與系統(tǒng)內(nèi)的其他軟件整合，成為孤島。

2 結(jié)束語

我們業(yè)余開發(fā)人員應(yīng)當充分發(fā)揮我們作為自己人開發(fā)的各種優(yōu)勢，充分做好需求采集和系統(tǒng)設(shè)計，避免常見的業(yè)余程序員容易出現(xiàn)的編碼問題。這樣我們就能開發(fā)出比專業(yè)軟件公司開發(fā)的更適合我們工作的軟件，為我們行業(yè)的工作添磚加瓦、做出自己的貢獻。

參考文獻：

[1] Jim McCarthy.軟件研發(fā)之道[M]. 北京： 人民郵電出版社， 2011.

[2] Brechner E. 代碼之殤[M]. 林鋒， 譯.北京： 機械工業(yè)出版社， 2013.

[3] 史亮. 軟件測試實戰(zhàn)[M]. 北京： 人民郵電出版社， 2014.

[4] Claes Wohlin，佩爾. 經(jīng)驗軟件工程[M]. 北京： 機械工業(yè)出版社， 2015.

[5] Venkat Subramaniam， Andy Hunt. 高效程序員的45個習慣[M]. 北京： 人民郵電出版社， 2014.