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