中文英文：
英文原文：
普通程式設計與專業程式設計之間有很多差別，而最為顯著的就是截止日期。當你給自己寫程式的時候，只要你願意，就可以用很多（或者很少）的時間來完成，但是當你給別人寫程式的時候，你就只有一點有限的時間和資源來完成任務。而根據我的經驗，一般會導致以下兩種情況之一：
1. 你必須延長時間以妥善完成任務。
2. 你必須寫些不嚴謹的**來應付過關。
如果你做過專業程式設計，你會明白我的意思。只有極少數夠靈活的專案能夠給予足夠的時間和資源來完成任務。這就使得程式設計師必須做出艱難的抉擇。
任何乙個有自尊的程式設計師都不願意提交不合格的**；但是當交易中伴隨有超時違約金時，想要始終提交高質量的**是很困難的，尤其是在專業環境下，與那些不需要理解技術違約概念的非技術員交易。
幸好，這裡有幾條準則供你參考，可以在臨近截止日期時，幫你把不嚴謹的**總數最小化。它們不一定能夠快速修復問題，但毫無疑問將有助於那些需要日復一日，始終寫出一流**的人。
準則一：編碼之前設定連續部署
這是我從《the pragmatic programmer / 程式設計師修煉之道》一書（絕對是程式設計師的必讀之書）中找出的小竅門。總是，我是說總是，在編碼之前設定你的連續部署系統。
我所說的連續部署是什麼意思？好的，在你開始編寫你的專案之前，你應該有乙個能部署你的專案**為產品的系統（最好對於分期和開發環境也是如此）。這樣，當你編碼時，你就會有乙個平和的心態，因為你知道你可以隨時部署你的專案。
在很多的程式設計流程中，這一點能節約相當多的開發時間。一些測試環境（或者更糟，直接在伺服器上編碼），你可以直接把**放到你首選的源**控制系統 中，然後讓你的連續部署系統負責接下來的事情。這也許看起來不想個節約時間的方法，但是如果你考慮一下每天都要把你的**複製過去並手動測試所浪費的時 間，你就知道這樣做能快速完成並在每月中節約數小時。
準則二：先寫測試
如果你從沒聽說過測試驅動開發（tdd），請立刻看看維基百科的解釋。如果有人付錢讓你編寫軟體，並且規定了截止日期，你就要隨時練習tdd。
測試驅動開發的基本概念是，在寫專案**之前，你寫一段簡單的**來測試你假設的專案**，以獲得預期的反應。例如：你的專案需要你寫乙個函式，把 兩個數相加，並返回和。在寫這段**之前，你應該寫乙個測試函式，test_add_two_numbers，它呼叫你的add_two_numbers 函式來驗證不同的輸入值所返回的結果都是正確的。
這看起來很麻煩，但是它有許多好處：
準則三：透明
透明很難實現（取決於你的工作環境），但卻非常有益處。
為了達到透明，你需要確保與接收**的客戶之間保持一條清晰的通訊線路。你需要保持定期更新，這樣才能看出來工作正在進行，並且進展的**。再好一點就是，你能一直部署**到分期系統，從而讓客戶夠看到未完成的專案和它一天天的改變。
如果你能跟你的老闆（們）保持透明化，他們就很有可能了解是否需要推遲截止日期。非技術人員通常不懂軟體開發，視它為黑盒技術。通過與客戶保持清晰的通訊和透明化，並讓他們參與到開發程序中，客戶可以更了解你的工作，使得對將要開發出來的產品更青睞。
規則四：維持日常計畫表（todo list）
時間管理問題肯定是超出本文談論的範圍，但是我仍要指出，為確保事情一直向前進展，作為一名程式設計師你所能做的最好的事情之一就是維持乙份日常計畫表。另外，乙個得力的時間追蹤工具也能幫上大忙。伯樂**的這篇文章中有老外推薦的10個時間追蹤工具。
軟體開發是極為複雜的事情。成為一名優秀的程式設計師要求有多年的實踐，耐心和鍛鍊，並且學無止境。當需要在截止日期內開發軟體時，往往你正在編寫乙個複雜的系統。為保持思路清晰，並且確保發揮你程式設計的最大能力，你應該維持乙份由每日需要完成（編碼方向）的單獨的任務組成的日常計畫表。
不要寫過於空泛的計畫表，像「除錯聲音問題」這樣的，而是要真正地想一遍，並且寫出事情的幾個步驟。例如：
有乙個明確的可操作的事件列表可以使你集中力量在一段時間內解決乙個單獨的任務。這樣就不用時刻平衡分配和在腦子裡想著接下來的步驟。編寫軟體已經夠複雜的了，不要讓你的生活更困難。
準則五：做應該做的事
毫無疑問，會有令你緊張和不舒服的情況出現。你拖延時間並忽略了新特性的單元測試嗎？當這些情況發生時，不要任意妄為。相反的，做應該做的事。
不管是否需要你回顧還是重新檢視一些舊**，都要多寫一些測試用例，甚至推遲截止日期也要這麼做。作為一位專業的技術人員，持續地開發能夠執行的**是你的工作，即使這意味著你必須做出艱難的抉擇。
結語
對乙個軟體開發人員來說沒有輕鬆的任務。我們的世界一直充滿挑戰和困難，只有磨練和時刻準備著才能幫助我們渡過難關，並在好時光裡成功。一直利用我們最精確的判斷，通過運用毫不動搖的工程實踐去打破時間的桎梏並且不向困難低頭。
你能夠做到。
中文英文： 英文原文：
《最後期限 》書中摘要
最後期限 重點摘要 優質管理的四大要素 l 選擇正確的人 l 為他們分配正確的工作 l 保持他們的積極性 l 幫助團隊凝聚起來並保持團隊的凝聚力 其他一切都只是文案 安全和變化 l 除非感到安全，否則人們就不能去迎接變化 l 在所有成功的工程中 以及在絕大多數其他有價值的工作中 變化都是基本的要素之...
解開最後期限的鐐銬
最後期限 deadline 是軟體從業人員必須面臨的最大困難與挑戰，準確地說，它是所有程式設計師包括專案管理者的可怕夢魘。當堂吉珂德看到郊野之上的數 十架風車，風車的翅翼如巨人的胳膊，正耀武揚威地奚落著這位中世紀後期沒落的騎士時，堂吉珂德如勇敢的鬥士一般，躍馬而上，用長槍狠狠地刺向風車，換來的 卻是...
真的是最後期限嗎？
在專案制軟體開發中，工程師和專案主管的主要壓力來自於最後期限 deadline 有人或許說主要壓力是來自於技術難點，但是事實上沒有解決不了的問題，要麼將技術難點攻克，要麼繞過技術難點用其他的解決方案。問題在於解決技術難點需要時間，而這會讓本不太多的專案時間更進一步逼近最後期限，而 按時交付 是評價乙...