原文：how should deadlines be used in software engineering?
日常談話中有多少次你在談到deadline（期限）時，曾至少有乙個人對這個概念嗤之以鼻？我已經聽過太多次了，甚至連我自己也這麼幹過，不過現在我想改正這一習慣。
軟體領域較之於傳統的印刷**（print media）有很大的不同，而deadline的概念就是從傳統的印刷**中得來。然而，不能僅因為目前在軟體領域尚無通用的deadline概念，就以為該摒棄這個概念，或以為它沒有價值。
以下是根據我的經驗總結出來的，在工程公司中與deadline最為相關的問題，以及最有可能解決問題的辦法。
1）對deadline的理解因人而異
a：「下週才是deadline，我還有大把的閒餘時間！」
b：「為什麼要擔心這個？沒關係的，deadline什麼的當不得真。」
a：「但我不想被炒魷魚啊！」
這組對話就很形象地展示了對同乙個deadline，a和b兩人在理解上有著巨大的差異，這也會導致整個團隊在努力實現deadline時出現困惑與挫敗感。
事實上，deadline必須要有號召力，每個人都得知道deadline重要的原因，他們必須明白錯過deadline會對整個圈子有什麼樣的影響，包括對其他團隊的、對客戶的或者對公司整體的影響。
更重要的是，那些達成的deadline需要熱烈的慶祝，而這一點常被忽視掉。比起責備那些錯過deadline的員工，建立起為達成deadline慶祝的企業文化才是上上之策。
2）在專案的生命週期中過早設定deadline
a：「嘿，我們得完成這項工作【插入乙個真的非常難的未知專案】，什麼時候能幹完？」
b：【快速搜了一下到底是什麼工作】「額，我不確定。」
a：「我需要乙個確切的deadline。」
b：「三，呃四個……月嗯周……月吧，四個月！」
a：「好極了，到時候見。」
向乙個各方面都屬於未知狀態的專案要求乙個deadline簡直後患無窮，也讓專案涉及到的員工壓力很大，為專案立起了失敗flag。所以，先深呼吸，耐心等兩天，讓大家完成探索工作。雖然蒐集資訊花費了時間，但之後我們卻能給出有意義的評估，這些資訊會幫助我們設定更加準確的deadline。
3）deadline更新頻度不夠
a：「這個專案要在5天內完成，目前進度ok嗎？」
b：「有一點落後，不過不要緊，我們會按期完工的。」
a：「好極了！」
【4天23小時後】
a：「再檢查一下專案，準備好發布了嗎？」
b：「額，還沒，出了點問題，目測還得乙個禮拜。」
a：「$%@!*」
在這個案例中，在新問題出現時，開發人員並未調整或重新評估deadline，b沒能立即提出問題，而是等到deadline才告知他人，於是a也受此牽連，而整個團隊也會因為要趕工另乙個deadline而倍感壓力。
設定deadline不應當是為了強迫員工超額負荷，把人當牲口用，而應用以設定外部對專案的預期，讓計畫呈現可預期性。deadline必須盡可能準確地反映現實情況，否則一旦出現信任危機，這個概念也就失去了傳遞可預期性的功能。當然，我不提倡每小時或每天更新deadline的行為，但也許每週更新，或至少按標準計畫的節奏來更新是個不錯的主意。
更新deadline並不拘於延長時間，也可以縮短週期。至於具體怎麼做，又或者兼而有之，都得工程師和產品團隊商榷後確定。
4）未將所有「已知工作」都納入考慮範圍，僅考慮到了有趣的那些
a：「這個功能多久能交付？」
b：「兩周。」
【兩周後】
a：「怎麼沒完工？」
b：「額，技術上來說已經完工，我們現在在測試，要給它新建乙個部署機制，會先發布乙個beta版。另外上週我休假了。」
在設定這個deadline時，相關人員對要完成的工作以及要投入的時間缺乏完整的理解，更別提該案例中b也出現了上面第三條的問題。
在設定deadline時，我們應當確保將所有已知的挑戰都涵蓋在內，是否會因某個已知原因而浪費一些時間，比如說度假、公司斷網、因為生日派對宿醉而遲到？
另外我們是否可能遺忘了某些不起眼的任務？這個專案打算寫多少測試？如何將這玩意兒發布到生產環境中？跟著這些問題放慢腳步，仔細思考下整個過程以及可用的資源。這樣做會讓設定deadline簡單得多，同時這樣設定出的deadline也更經得起考驗。
工程師所設定的deadline很大程度上是通過評估形成的，也就是說團隊中的每個人都要習慣犯錯，犯很多錯——將自己知道不對或是沒資訊的地方說出來，可能會很困難。
我們必須達成共識，盡可能準確地作出評估，並隨著時間評估地越來越準確。評估是一項技能，反覆使用會熟能生巧。初期可能會讓人不適，但這是我們需要做到的。
在定下大型專案的交付時間前，我們應當將整個專案拆分成小的任務，每個任務應當能在約五個工作日內完成。
以下問題對評估任務十分有用：
工程專案通常被視為乙個較大的任務，可以讓多人並行完成。
下面這些問題有助於評估專案：
即便要知道某項工作是否完工都是很困難的，團隊中不同角色可能會有不同的「完工」標準，因此我們需要指定某個專案的具體完工標準。
下面是典型完工標準的一些樣例：
隨著公司的壯大與管理能力日趨成熟，交付能力成為必須，而deadline是其中主要的工具之一，合理善用將有無與倫比的功效。不過，想要利用deadline，還需時日在實踐中慢慢磨合。因此我建議：工程類公司應當將其視為乙個活生生、有生命力的東西，不間斷地去學習了解，並通過文件在全公司內部，乃至與整個行業分享經驗。
軟體開發中的併發
併發作用 1.在互動式應用中，快速響應使用者的請求，提高感知響應的時間 2.充分利用硬體資源，計算資源 3.簡化應用設計 併發壞處 1.難於測試 2.併發應用執行在複雜的環境下，軟體不確定性增多 3.處理同步，通訊的問題，增加程式設計複雜性 4.併發開銷對效能的影響，包括上下文環境切換，同步等 併發...
軟體開發中的「格調」
在三年之前，我從學校畢業，進入公司，正式開始了軟體開發工作。我從完成第乙個開發任務的過程中學到了很多東西，包括 1 編寫程式只是軟體開發中的乙個流程，並非全部 2 程式編寫需要遵循一定的規範，遠遠不只是實現功能那麼簡單 3 程式編寫者是程式的第一負責人，要對自己的程式進行充分的自測，而非只要程式編寫...
自上而下的軟體開發和自下而上的軟體開發
自上而下 top down 開發模式是指從乙個應用的最高點開始開發。從最高點逐步往下層編碼，直到開發完所有的任務。一旦寫完了最下層的 開發任務就完成了。使用這種方式，你需要設計 編寫出所有你需要的但還沒有實現模擬介面 服務 偽 自下而上 bottom up 開發模式是指從乙個應用的最底層開始開發。這...