編碼階段，要成功，必須牢記一條：能做到少修改，不重做，力爭一次成功！！
在編碼階段，只要不是原則性的錯誤，盡量不要推倒前面所做的一切，重新做，畢竟以前做的時候也是考慮了方方面面的因素的，現(xiàn)在出現(xiàn)的問題只是在某方面考慮不周而已，一切都作廢，太浪費了。還有，要是數(shù)據(jù)庫字段已存在，除非萬不得已，千萬不要修改數(shù)據(jù)庫字段，能可添加字段。因為已經(jīng)存在的字段，很有可能已被軟件開發(fā)小組的其他成員在使用，不要因為你的修改而令其他人也要跟你做相應(yīng)的修改。后，軟件界面的修改要慎重，界面的修改很容易使你忽略修改相應(yīng)的內(nèi)容，造成軟件大問題沒有，小問題一大堆。
要想做到不修改，不重做，很不容易，要考慮的因素很多。
首先從軟件的角度來說吧:
對于專用軟件，很多時候，一般用戶對于軟件要完成哪些功能已經(jīng)有了一個比較清楚的輪廓，而且往往在開發(fā)合同中已經(jīng)大致地規(guī)定了。但是，開發(fā)合同上規(guī)定的只是一個大概的框架，用戶心目中的產(chǎn)品究竟是什么樣子，有時不要說開發(fā)人員不知道，連用戶本人也不知道。所以很多時候，都是到了開發(fā)工作的后期才發(fā)現(xiàn)開發(fā)人員的理解和用戶的要求有一些誤解，那么必然造成時間上的浪費。
對于通用軟件，很多時候是到了開發(fā)工作的后期才發(fā)現(xiàn)某方面的功能不足，或要添加新功能等等。
在小型軟件公司中，由于開發(fā)人員少，這樣意味著不同人員的程序之間交互、接口相對少一些。開發(fā)周期短意味著往往是同樣的幾個人從頭到尾負(fù)責(zé)一個項目。這兩者都讓人容易犯些錯誤。往往是幾個人碰一下頭，討論一下基本的數(shù)據(jù)結(jié)構(gòu)、函數(shù)接口便分頭去做自己的工作了，沒有一份較正式的文檔。當(dāng)有的人會對討論出的接口、結(jié)構(gòu)理解有偏差(應(yīng)該承認(rèn)人是會犯錯誤的)，一個誤解可能造成以后的返工。
其次從管理的角度來說吧:
1、 有效的團隊組織。
提高團隊組織的工作績效，提高組員的團隊精神。這非常有利團隊有效，有序的工作。有效的團隊建設(shè)，這是管理的重要內(nèi)容。
2、 小組成員的溝通、協(xié)調(diào)。
溝通，也許在各行各業(yè)都已提到了一個相當(dāng)重要的位置。在一、二十年前，也許您會經(jīng)常聽到某位大俠單獨完成了某種創(chuàng)舉，成了人們崇拜的對象�？桑@種大俠，已經(jīng)很難有生存空間了。取而代之的是，某軍團，又攻克了一座什么樣的寶壘。這樣，溝通，可以說已經(jīng)變得無比的重要。在軟件業(yè)，溝通可以說是快速學(xué)習(xí)和掌握新知識，達到技術(shù)上的更高層次的佳途徑。 小組員的溝通，可以很好的加強團隊組織的凝聚力�？赡芨玫淖岉椖苛夹缘倪M行。而培養(yǎng)這種氣氛，形成有效的溝通，這也是項目管理的基本內(nèi)容。協(xié)調(diào)幾個人的工作比自己完成一段編碼更重要。如果小組成員在協(xié)調(diào)上出了漏洞，可能導(dǎo)致很大的問題，所以項目負(fù)責(zé)人必須隨時監(jiān)控各開發(fā)人員的工作，包括內(nèi)容是否與要求發(fā)生偏差，進度是否滯后等等。
后從測試的角度來說吧。
傳統(tǒng)觀點認(rèn)為，測試是在編碼后的工作。其實，測試和編碼是兩個密不可分的階段，交叉進行的，測試在編碼后期進行的較多！！主要有兩方面:
1、 不經(jīng)過單元測試而直接進入系統(tǒng)測試;
造成這一現(xiàn)象的原因是每個模塊相對比較簡單，但是為了測試一個模塊需要建立一些測試環(huán)境。例如，為了測試一個函數(shù)是否正確，應(yīng)該用一些測試數(shù)據(jù)去調(diào)用該函數(shù)，需要編寫一些測試數(shù)據(jù)。但很多開發(fā)人員嫌麻煩，覺得反正其他模塊也很快出來了，直接用真正的數(shù)據(jù)來運行幾次行了。殊不知，一旦直接進入系統(tǒng)測試，發(fā)現(xiàn)運行結(jié)果不正確后需要一步步查找。不但耗費了大量的查找時間，而且后面的模塊已完成了，修改前面的模塊又會影響后面的模塊，使的修改的難度增加，修改后導(dǎo)致新的錯誤產(chǎn)生的概率增大，另外，每個人的潛意識都不想否定自己，這種情況下很難真正去修改。還有由于這種測試不完全，真正運行系統(tǒng)，當(dāng)調(diào)用某模塊時，可能大部分時候都是正常數(shù)據(jù)，極少出現(xiàn)邊界情況，可能某些邊界情況容易被忽視，很久之后才被發(fā)現(xiàn)。但是如果對每個模塊進行單元測試時都進行一下邊界測試，會很容易消除一些隱患。真可謂欲速則不達也！
2、 如果在項目人員配置中設(shè)置了專門的測試人員，編碼人員會認(rèn)為軟件所有的內(nèi)部測試工作全部應(yīng)該由測試人員完成。
眾所周知：軟件程序測試可以分為“白盒法”和“黑盒法”兩種方式。由于使用“白盒法”對測試人員各方面素質(zhì)的種種要求，在進行程序測試時測試人員總是優(yōu)先使用“黑盒法”。他們的工作方式往往是先對程序進行“黑盒法”測試；如果測試沒有通過，不得已這才考慮對程序代碼進行“白盒法”測試。顯然，這種對“白盒法”有意無意的“逃避”，對軟件的可靠性和穩(wěn)定性構(gòu)成了威脅，造成在編碼后期，甚至是在試運行或運行階段需要進行大量的修改。如何解決這個問題？一方面需要提高對測試人員的要求，另一方面也需要程序員完成部分的“白盒法”測試（實際上，程序員往往也是進行“白盒法”測試的佳人選）。
在代碼階段，除了要想做到不修改，不重做外，還需要對軟件的質(zhì)量進度等進行控制，必須做到以下幾點：
1、 定期召開項目工作會議，向項目開發(fā)人員及時了解項目進展情況及存在的主要問題。一旦發(fā)現(xiàn)問題，管 理人員應(yīng)迅速查明原因，盡快采取措施，爭取在盡可能小的范圍內(nèi)解決問題。
2、 在軟件開發(fā)過程中，請專家和用戶按照里程碑評審階段性的成果，判定開發(fā)進度 是否與軟件項目定義的里程碑保持一致，開始時間是否與計劃時間一致。
第四章 編碼后的管理
編碼完成后，是軟件實行試運行、運行階段，并生成相應(yīng)的版本，并進行相應(yīng)的備份。這個工作很重要，特別是版本生成備份，很容易出錯。筆者在曾經(jīng)犯過這樣的錯：給了老版本給用戶；把為甲做的版本給了用戶乙；備份時把以前有用的版本覆蓋了等等，不一而足。要避免犯這些錯誤，必須要在每次生成不同的版本或者備份時，都要建立相應(yīng)的文章。在文檔中，盡可能詳實地記錄本版本或備份的時間、目的，特別是和其他版本的不同之處。寫的越詳實，出錯的概率越小��！
