老外的12條測試讓你更好地編程
你聽說過SEMA么?它是一個用來測試一個軟件團隊有多好的相當(dāng)深奧的系統(tǒng)，
老外的12條測試讓你更好地編程
。不，等等!不要手賤點開這個鏈接!它會花費你大概六年的時間來了解這個東西。所以我提出了我自己的、跟它相比極不負(fù)責(zé)任的、草率的評價一個軟件團隊的質(zhì)量的測試。這個測試最棒的方面是它只會花費你3分鐘的時間。你節(jié)省下來的所有時間，還可以去上個醫(yī)學(xué)院。Joel測試
TheJoelTest
Doyouusesourcecontrol?
Canyoumakeabuildinonestep?
Doyoumakedailybuilds?
Doyouhaveabugdatabase?
Doyoufixbugsbeforewritingnewcode?
Doyouhaveanup-to-dateschedule?
Doyouhaveaspec?
Doprogrammershavequietworkingconditions?
Doyouusethebesttoolsmoneycanbuy?
Doyouhavetesters?
Donewcan didateswritecodeduringtheirinterview?
Doyoudohallwayusabilitytesting?
Joel測試的好處是很容易快速得出針對每一個問題的“是”或“不是”。你不必去翻出那些每日編程行數(shù)和每個拐點的平均bug數(shù)。如果你的團隊有一個“是”就得一分。關(guān)于Joel測試令人失望的是，你真的不應(yīng)該用它來確保你的核電站軟件的安全。
獲得12分是完美的，11分也還可以容忍，但10分或更低的分?jǐn)?shù)表明你有嚴(yán)重的問題。事實上，大多數(shù)軟件企業(yè)都以2分或3分的分?jǐn)?shù)在運轉(zhuǎn)著，他們真的很需要幫助，因為像微軟這樣的公司一直以來都以12分的完美表現(xiàn)在運轉(zhuǎn)。
當(dāng)然，這些都不是決定成敗的唯一因素：特別是當(dāng)你有一個正在開發(fā)沒人要的產(chǎn)品的`偉大的軟件團隊的時候，那么，人們是真的不會接受這個產(chǎn)品的。同時一個沒有這么做的“神槍手”仍然能產(chǎn)生出令人難以置信的改變世界的軟件也是可能存在的。但是，在其他條件相同的情況下，如果你把這12件事情都做好了，你就會擁有一個能始終如一完成任務(wù)的團隊。
你使用源代碼管理么?
我用過商業(yè)源代碼管理包，也用過CVS，它是免費的，讓我來告訴你，CVS很好用。但如果你沒有對源代碼進行管理，你就要應(yīng)激嘗試把程序員都弄到一塊來工作。程序員根本不會知道別人都做了什么。犯過的錯誤不能輕易改過來。關(guān)于源代碼管理系統(tǒng)的另一個好處就是源代碼本身可以在每個程序員的硬盤上進行驗證---我還從沒聽說過哪個使用源代碼管理的項目丟失了很多代碼。
你能在一步之內(nèi)編譯程序么?
通過這條測試我想明白：從最新的源代碼的快速復(fù)制到進行能輸出的編譯需要多少步驟?再優(yōu)秀的團隊里，有一個單獨的腳本，它能從零開始對代碼做一個全面的檢查，重新編譯每一行代碼，生成EXE文件，在他們各種各樣的版本、編程語言和#ifdef宏定義組合，創(chuàng)建安裝包和最終媒體--CDROM 布局、下載網(wǎng)站等等。
如果這個過程需要一個以上的步驟，就很容易出現(xiàn)誤差。當(dāng)你接近完工的時候，你很想有很快的修復(fù)“最后一個”bug的周期，生成最后的EXE文件等。如果編譯代碼要用20步才能完成，運行安裝編譯器，……，等等，你會抓狂的，并且會導(dǎo)致你犯下愚蠢的錯誤，
資料共享平臺
《老外的12條測試讓你更好地編程》(http://www.lotusphilosophies.com)。正式由于這個原因，我曾工作過的上個公司就從“聰敏”模式切換到了“軟件安裝打包”模式：我們要求安裝過程中可以運行，使用NT調(diào)度從腳本整晚自動地運行，“聰明”模式做不到這些，所以我們就拋棄了這個模式。
你每天都編譯代碼么?
當(dāng)你使用源代碼管理的時候，有時候程序員偶然會檢查出會停止編譯的東西。比如，他們添加了一個源文件，一切在他們的機器上編譯起來都很好，但他們忘記把源文件添加到代碼庫里了。所以他們鎖定了機器就回家去了，比較健忘也比較高興。但其他人都不能繼續(xù)工作了，所以他們也不得不很不愉快地卷鋪蓋回家了。
打斷編譯是很糟糕的(也很常見的)，但它能幫助程序員每天都編譯代碼，以確保不會出現(xiàn)沒有預(yù)兆的編譯中斷。在大型團隊里面，一個很好的確保中斷能迅速修復(fù)的方法是每天下午都對代碼進行編譯，比如可以在午飯時間做這個。每個人都盡可能多地在午飯前做代碼檢查。這樣當(dāng)他們吃完午飯回來的時候，這個編譯就已經(jīng)完成了。如果它能用，就太好了!每個人都對最新的源代碼進行檢查，然后才繼續(xù)工作。如果編譯失敗了，你就修復(fù)它，但每個人還能在預(yù)編譯、沒有中斷版本的源代碼上繼續(xù)工作。
在Excel項目組，我們有一條規(guī)則：誰中斷了編譯，作為對他的“懲罰”，他就要在其他人中斷編譯之前臨時照顧代碼編譯的工作。這是一個很好的不中斷編譯的激勵方式，也是一個讓每個人輪流參與編譯工作從而都能知道編譯原理的好方法。
你有bug數(shù)據(jù)庫么?
我不在乎你怎么說。如果你在開發(fā)代碼，即使是在一個人的團隊，沒有一個組織的列出代碼里所有已知bug的數(shù)據(jù)庫，你將會產(chǎn)生出低質(zhì)量代碼。許多程序員都認(rèn)為他們能把眾多的bud存在腦子里。真是胡說八道。我根本就不能再同一時間記住兩個或三個bug，第二天早上，或者在寫代碼的高峰時期，就記不起它們了。你絕對要正式地跟蹤bug。
但數(shù)據(jù)庫可以是復(fù)雜或簡單的。一個最小限度的bug數(shù)據(jù)庫必須包含以下對每個bug的數(shù)據(jù)：
再次出現(xiàn)這個bug的完整步驟
預(yù)期的行為
觀察到的行為
它是被設(shè)計來干嘛的
它是否已被修復(fù)
如果bug跟蹤軟件的復(fù)雜性是讓你不想跟蹤你的bug的唯一理由，只用上面包含簡單的5個元素的表格用在這些至關(guān)重要的領(lǐng)域，開始使用它吧。
你在寫新代碼前會修復(fù)bug么?
第一個版本的Windows系統(tǒng)上的微軟Word被認(rèn)為是一個“死亡行軍”項目。不知道這項目要什么時候才能完成，它不斷的延期。整個項目組在荒謬的時間里工作著，項目再次、再次、再次延期，這時候的壓力的令人難以置信的。當(dāng)討厭的事情最終出貨，幾年以后，微軟把這整個團隊都送到坎昆去度假了，他們可以靜下來做些嚴(yán)重的自我反省了。
他們意識到，項目經(jīng)理一直在堅持按照“日程安排”部署工作，而程序員們只是頭腦簡單的趕緊完成敲代碼的過程，又因為修復(fù)bug階段并沒有成為正式日程安排的一部分，這導(dǎo)致他們寫出了及其惡劣的代碼。沒有能試圖保持住bug不發(fā)作的倒計時。恰恰相反，據(jù)說一個程序員寫了計算文本行高的代碼，僅僅寫了“renturn12;”然后就開始等待關(guān)于他的功能總是正確的bug報道。日程安排僅僅是即將變?yōu)閎ug的功能的檢查清單。事后，這個被稱為“無窮大缺陷的方法”。
為了解決這個問題，微軟普遍地采取了一種叫做“零缺陷方法”的東西。公司的許多程序員都咯咯地笑，因為它聽起來是一種好像通過行政法令就能夠減少bug數(shù)量的管理思想。其實，“零缺陷”意味著在任意給定的時間內(nèi)，優(yōu)先級最高的是消除bug，然后才是編寫新代碼。讓我來講講為什么。
【老外的12條測試讓你更好地編程】相關(guān)文章：