欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久

1982年，我家定購了IBM的PC機(IBM生產(chǎn)的最早的個(gè)人計算機，是現代流行的標準化的個(gè)人計算機的祖宗）。我們家可能是以色列最早擁有這種PC機的幾個(gè)家庭之一。當時(shí)我們跑到了倉庫等著(zhù)電腦從港口運過(guò)來(lái)。事實(shí)上，我說(shuō)服我爸購買(mǎi)的是帶有全套附屬設備的個(gè)人計算機（譯者按：有些現在很便宜的附屬設備，那時(shí)候都是非常昂貴的），這些附屬設備包括兩個(gè)軟盤(pán)驅動(dòng)器，128K內存，一個(gè)針式點(diǎn)陣打印機（用來(lái)快速打印草稿）和一個(gè)運轉起來(lái)發(fā)出機關(guān)槍掃射聲音的兄弟牌的雛菊輪式打印機（譯者按：原文為Daisy Wheel printer，是一種已經(jīng)淘汰的打印機，原理類(lèi)似于老式的機械打字機，可以產(chǎn)生清晰的英文字符）。

因為當時(shí)“每個(gè)人”都知道BASIC是給小孩玩的語(yǔ)言，用這種語(yǔ)言只能使你寫(xiě)出非結構化的垃圾代碼，然后你的的腦子也會(huì )被這種語(yǔ)言變成Camembert產(chǎn)的奶酪（Camembert cheese，法國的一種奶酪，實(shí)心，圓餅狀，灰色，有一個(gè)拳頭大?。?。所以我們又花了600美元買(mǎi)了一個(gè)IBM公司PASCAL語(yǔ)言開(kāi)發(fā)包，需要3張軟盤(pán)才裝的下。PASCAL編譯器運行分別需要第一號軟盤(pán)，和第二號軟盤(pán)，PASCAL鏈接器需要第三號軟盤(pán)。我寫(xiě)了一個(gè)簡(jiǎn)單的輸出文字“你好，世界”程序然后編譯鏈接這個(gè)程序，總共花了8分鐘。

嗯，8分鐘好像太長(cháng)了。我寫(xiě)了一個(gè)腳本程序來(lái)自動(dòng)化整個(gè)過(guò)程，把時(shí)間縮減為7.5分鐘。這樣好一點(diǎn)了。但是我想設計一個(gè)可以玩奧賽羅的程序。（譯者按：奧賽羅原文為Othello，一種棋類(lèi)游戲，規則見(jiàn)http://www.ugateways.com/bof4.html）這個(gè)游戲總是能打動(dòng)我。我不得不花很多時(shí)間等待編譯器編譯我的程序。“就是這樣的，”一個(gè)專(zhuān)業(yè)程序員告訴我，“我們通常在辦公室里房放上sit-up board（譯者按：一種健身器材，可以在上面做仰臥起坐或者有氧操什么的） ，當PASCAL編譯器開(kāi)始運行時(shí)，我們就開(kāi)始鍛煉。我這樣編程了幾個(gè)月后，我的身材不要太棒喔！”

后來(lái)有一天，丹麥程序員寫(xiě)了一個(gè)很靈的叫做Compas Pascal的程序。Philippe Kahn（Borland公司的創(chuàng )始人）買(mǎi)下了它，更名為Borland Turbo Pascal。Turbo Pascal好得簡(jiǎn)直難以想象，因為它能做IBM Pascal能做的所有事情，但是只要33K內存。而且還額外提供一個(gè)編輯器。 這還不是最棒的。最棒的是編譯一個(gè)小程序只需要不到一秒。這就好比一個(gè)你從來(lái)沒(méi)有聽(tīng)說(shuō)過(guò)的公司生產(chǎn)了通用公司別克轎車(chē)的克隆版，這種克隆車(chē)可以每小時(shí)行駛一百萬(wàn)英里，但是只消耗了一滴汽油。一只小小的螞蟻喝下這點(diǎn)汽油也不會(huì )撐死。

突然，我的編程效率變得高的多了

那時(shí)我開(kāi)始明白了“REP循環(huán)”（Rep loop）這個(gè)概念. REP是“讀入，求值，打?。≧ead, Eval, Print）”的縮寫(xiě)。這個(gè)概念解釋了Lisp（一種編程語(yǔ)言，用于人工智能）解釋器的基本原理：它“讀入”你的輸入，計算你的輸入得到結果，打印結果。下面給一個(gè)例子：我輸入一些東西，Lisp解釋器計算，然后輸出結果。

在一個(gè)稍微大點(diǎn)的規模上，當你寫(xiě)代碼時(shí)，你也處于一個(gè)REP循環(huán)的宏版本中，這個(gè)循環(huán)就是“編碼－編譯－測試”。你編寫(xiě)代碼，把代碼編譯成可執行的文件，然后測試它，看一下運行起來(lái)怎么樣。

關(guān)鍵一點(diǎn)是當你寫(xiě)一個(gè)程序時(shí)，你的工作過(guò)程是循環(huán)的。一個(gè)循環(huán)所花時(shí)間越短，你的生產(chǎn)力就越高，當然最短時(shí)間不會(huì )小于編譯器運行的時(shí)間。 這就是一個(gè)程序員為什么總是要一個(gè)真正夠快的硬件而編譯器開(kāi)發(fā)者們總是不斷使他們的編譯器運行更快的正式的純計算機科學(xué)角度的原因。Visual Basic的辦法是當你輸入代碼時(shí)，它就開(kāi)始進(jìn)行代碼的語(yǔ)法解析，這樣程序解釋運行時(shí)速度很快。Visual C++的辦法是增量編譯（incremental compiles），預編譯頭文件（precompiled headers）和增量鏈接（incremental linking）。

但是一個(gè)大型的團隊有多個(gè)開(kāi)發(fā)人員和測試人員，你碰到了同樣的循環(huán)，可能不同點(diǎn)就是有更多的文檔要寫(xiě)(可是這還只是草稿，天哪！)。一個(gè)測試人員發(fā)現了bug并報告，然后開(kāi)發(fā)人員修復了這個(gè)bug。那么測試人員得到修正后的代碼需要多少時(shí)間？在一些軟件開(kāi)發(fā)機構，這樣的報告－修正－再測試循環(huán)（Report-Fix-Retest loop）可能需要幾個(gè)禮拜。如果一個(gè)循環(huán)需要這么長(cháng)的時(shí)間，通常意味著(zhù)該機構生產(chǎn)力很低。想讓整個(gè)開(kāi)發(fā)過(guò)程運轉得更平滑一點(diǎn)，你必須想方設法使得報告－修正－再測試循環(huán)（Report-Fix-Retest loop）花的時(shí)間更少。

一個(gè)好的辦法是每日構建（daily builds）。 每日構建意味著(zhù)自動(dòng)地，每天，完整地構建整個(gè)代碼樹(shù)、（譯者按：“代碼樹(shù)”，原文為source tree，意思是將整個(gè)項目源代碼的目錄，子目錄，文件的位置盡可能事先固定下來(lái)，這樣在開(kāi)發(fā)過(guò)程中各個(gè)模塊間，各個(gè)文件間的相對位置都不會(huì )混亂。源代碼樹(shù)指的就是一個(gè)項目所有的已經(jīng)組織好的代碼文件。通常代碼樹(shù)應該用版本控制軟件管理起來(lái)。雖然這個(gè)概念很基本，但是據我的觀(guān)察，國內還是有軟件公司在這方面做的不夠好的，所以有必要解釋一下。）

自動(dòng)地 － 因為你設定代碼每天在固定的時(shí)間構建。在Unix環(huán)境下使用cron，在windows下使用“任務(wù)計劃”。

每天 － 或者更頻繁. 當然每天構建的次數越多越好啦。但是有時(shí)候構建次數還是有上限的，原因和版本控制有關(guān)系，等會(huì )兒我會(huì )談到的。

完整地 －很可能你的代碼有多個(gè)版本。多語(yǔ)言版本，多操作系統版本，或者高端低端版本。每日構建（daily build）需要構建所有這些版本。并且每個(gè)文件都需要從頭編譯，而不是使用編譯器的不完美的增量編譯功能。

以下是每日構建（daily build）能帶來(lái)的好處：

1. 當一個(gè)bug被修正了，測試者可以很快得到最新的修正后的版本開(kāi)始重新測試，以驗證bug是否真正地被修復了。
2. 開(kāi)發(fā)人員可以更加確定他們對代碼做的修改不會(huì )破壞1024個(gè)操作系統上的任何一個(gè)版本。驗證這一點(diǎn)不需要在他們的機器上安裝OS/2（IBM公司生產(chǎn)的PC機操作系統）。
3. 那些每天將修改過(guò)的代碼導入（check in）版本控制服務(wù)器的開(kāi)發(fā)人員知道，他們對一個(gè)模塊導入的修改不會(huì )拖別的開(kāi)發(fā)人員的后腿。拖后腿的意思是，那些開(kāi)發(fā)別的模塊的程序員使用這個(gè)修改過(guò)的模塊，出了問(wèn)題，于是他們自己的模塊也沒(méi)有辦法開(kāi)發(fā)下去了。每日構建則不會(huì )有人拖后腿。如果把一個(gè)開(kāi)發(fā)團隊比作一臺PC機，那么團隊中的一個(gè)程序員對某個(gè)模塊的修改導致其他人無(wú)法開(kāi)發(fā)別的模塊，相當于PC機發(fā)生了藍屏。當一個(gè)程序員忘記把他（她）新建立的文件導入到repository（指版本控制服務(wù)器上的代碼樹(shù)）時(shí)，這種開(kāi)發(fā)過(guò)程中的“藍屏”會(huì )經(jīng)常發(fā)生。因為在這個(gè)程序員自己的計算機上有這個(gè)文件，所以他（她）構建 這個(gè)程序沒(méi)有問(wèn)題。但是其他程序員是從版本控制服務(wù)器上導出（check out）代碼的，由于服務(wù)器上沒(méi)有這個(gè)文件，他們遇到了鏈接錯誤（link error），無(wú)法繼續工作了。
4. 外部團隊（例如市場(chǎng)銷(xiāo)售部門(mén)，進(jìn)行beta測試的一些客戶(hù)）可以獲得一個(gè)比較穩定的版本，這樣對他們開(kāi)展自己的工作比較有利。
5. 假如你將每日構建出的二進(jìn)制文件（例如一個(gè)可執行程序，一個(gè)dll等等）存檔管理，那么當你發(fā)現一個(gè)非常奇怪的，無(wú)法解決的bug時(shí)，你可以通過(guò)對這些文件進(jìn)行二進(jìn)制搜索（binary search）來(lái)確定什么時(shí)候這個(gè)bug第一次出現。如果有對代碼進(jìn)行了完善的版本控制，你也可以找出是誰(shuí)在何時(shí)對代碼進(jìn)行的導入（check in）導致了這個(gè)bug。
6. 當開(kāi)發(fā)者修正了測試者報告的一個(gè)錯誤時(shí)，如果測試者同時(shí)報告了發(fā)現錯誤時(shí)的構建的版本，開(kāi)發(fā)人員可以直接在那個(gè)版本中測試是否bug真正被修復了。（譯者按：測試者報告出現了一個(gè)bug，只是報告了一個(gè)錯誤癥狀，而錯誤的原因可能有多個(gè)，每個(gè)原因可能在不同的模塊中。前文中的方法是為了避免只修正了一個(gè)模塊中一個(gè)原因，別的模塊由于在變動(dòng)，于是掩蓋了而不是修復了bug）

以下是如何進(jìn)行每日構建（daily build）的具體步驟。你需要用最快的電腦建立一個(gè)每日構建服務(wù)器。寫(xiě)一個(gè)腳本，可以自動(dòng)從版本控制服務(wù)器中導出（check out）完整的代碼，（你當然使用版本控制，不是嗎？），然后對代碼從頭開(kāi)始進(jìn)行構建（build），要構建所有的版本。如果你有一個(gè)安裝打包程序，也要在腳本中自動(dòng)運行。所有會(huì )賣(mài)給最終用戶(hù)的東西都要包括在構建過(guò)程中。把構建出來(lái)的版本放在各自的的目錄里，不同時(shí)間構建的相同版本也應該按日期整理好，不要相互覆蓋。每天固定的時(shí)間運行這樣的腳本。

• 最關(guān)鍵的是所有這些步驟都應該由腳本自動(dòng)化完成，從導出（check out）代碼到將最終產(chǎn)品放在網(wǎng)上供用戶(hù)下載（當然在開(kāi)發(fā)階段，產(chǎn)品是放在一臺測試服務(wù)器上的）。要保證開(kāi)發(fā)過(guò)程中的任何東西的任何記錄是由文檔記錄的而不是由某個(gè)人的腦子來(lái)記錄的，這是唯一的辦法。否則你會(huì )碰到這樣的情況，產(chǎn)品需要發(fā)布了，可是只有Shaniqua知道如何將產(chǎn)品打包的，可是他剛剛被巴士撞了。在Juno公司（本文作者工作過(guò)的公司之一），要進(jìn)行每日構建，你唯一需要學(xué)會(huì )的東西就是雙擊每日構建服務(wù)器桌面上的一個(gè)快捷方式。
• 如果你在發(fā)行程序的當天發(fā)現了一個(gè)小bug，沒(méi)有問(wèn)題。修正它，然后重新運行每日構建腳本，現在你可以安安心心的發(fā)行程序了。當然，黃金定律是每日構建腳本應該是把所有的事情從頭做一遍，遵循這個(gè)定律就不會(huì )有什么問(wèn)題。
• 將你的編譯器的警告參數設到最大（在微軟的VC中是-W4 ; 在GCC中是-Wall），當遇到任何一個(gè)最微小的警告時(shí)就應該停下來(lái)。
• 如果每日構建失敗了，可能整個(gè)開(kāi)發(fā)團隊的工作會(huì )因此進(jìn)行不下去。當務(wù)之急是立刻找出原因，使得每日構建能成功進(jìn)行下去。某天也許你會(huì )一天運行好幾次每日構建腳本的。
• 每日構建一旦失敗，應該自動(dòng)地將失敗用email通知整個(gè)團隊。提取錯誤日志中的恰當部分并包括在email正文中也不是很難。每日構建腳本也可以將當前的狀態(tài)報告整理成一個(gè)html文件，自動(dòng)發(fā)布到一個(gè)所有人都可以訪(fǎng)問(wèn)的web服務(wù)器上，這樣測試者可以很快知道那個(gè)版本的構建是成功的。
• 當我在微軟的excel團隊中工作時(shí)，我們的一個(gè)有效辦法是，誰(shuí)導致每日構建（daily build）失敗，他（她）就得負責照看當日的每日構建（譯者按：微軟通常每日構建都在半夜），直到有另一個(gè)人導致構建失敗而接替他（她）。這樣做當然可以使每個(gè)開(kāi)發(fā)者都小心不要因為自己代碼的錯誤破壞了構建，更重要的是團隊中的每個(gè)人都可以學(xué)會(huì )每日構建（daily build）的原理。
• 如果你的團隊在同一個(gè)時(shí)區工作，在午飯時(shí)間進(jìn)行每日構建（daily build）是個(gè)不錯的主意。午飯前每個(gè)程序員導入（check in）代碼，這樣當程序員在吃飯時(shí)，構建系統在工作。當程序員吃完飯回來(lái)時(shí)，如果每日構建失敗了，所有的人也都在，可以盡快找出失敗的原因。當構建系統運作起來(lái)時(shí)，沒(méi)有人再會(huì )擔心別人導入（check in）代碼會(huì )妨礙自己的工作了。.
• 如果你的團隊同時(shí)在兩個(gè)時(shí)區工作，計劃好每日構建（daily build）的時(shí)間使得一個(gè)時(shí)區的工作不會(huì )影響另一個(gè)時(shí)區的工作。在Juno公司，紐約程序員在晚上7：00導入（check in）到版本控制服務(wù)器。如果他們的導入導致構建失敗，印度Hyderabad市（譯者按：印度科技重鎮）的程序員在紐約時(shí)間晚上8：00以后的工作幾乎無(wú)法進(jìn)行下去。我們每天進(jìn)行兩次每日構建（daily build），每次構建的時(shí)間都在兩地的程序員回家之前，這下就沒(méi)有問(wèn)題了。