謹慎行動
act with prudence
（seb rose）
無論你承諾了什麼，都得小心處置，顧及後果
——無名氏
在一次迭代開始時，各項任務看上去安排得張弛有度，但仍無法避免在某段時間會承受到巨大進度壓力。當你發現必須在
「幹得好」和
「幹得快
」之間作出抉擇時，一般都會選擇
「幹得快
」，並提醒自己將來再來返工。你對自己、團隊和客戶許下這個承諾的時候，確實是想這樣做的。但經常會出現的情況是，下一輪迭代自有其新問題，你只好把工作重點轉移到新問題上。這類久拖不決的工作任務就是所謂的技術債務（
technical debt
），它可不是你的好朋友。
martin fowler
在他的技術債務分類法裡把它叫做蓄意技術債務（
deliberate technical debt）（
1，有別於無意技術債務（
inadvertent technical debt
）。技術債務就像一筆貸款。在短期內，你能從中得到好處，但是，在清償之前，你要付出利息。**裡的捷徑使得新功能更難於加入，也會影響到**重構。它們是軟體缺陷和失敗測試用例的滋生地，放任它們的時間越長，情況就會越糟糕。當你有一天終於想兌現之前的承諾，對它們進行修改時，會發現**已經難以重構和更正。事實上，往往是情況變得不可收拾時，你才不得不對它們進行修正，而那時你已沒有足夠的時間，也承擔不起由此帶來的風險。
難免有幾次為了趕上最後期限，或要為一項特性做個簡化版本，不得不背上技術債務。請盡量不要陷入這樣的境地，如果實在是形勢逼人，那就勇敢地去承擔。但是（注意，這是加重語氣的但是），必須時刻追蹤這筆技術債務，盡快地或者當情況急劇惡化的時候，立即將其償還。每當你迫不得已欠下了技術債務，就要立刻記錄到任務卡上或者登記到問題跟蹤系統裡，以保證其不會被遺忘。
如果在下一輪迭代裡償還了這筆債務，其代價就會減少到最小，如果總是不還，利息就會日益累加。每筆利息都應該被跟蹤到，使其代價顯而易見。這一措施彰顯出技術債務對專案的商業價值的負面影響，從而給「還貸
」乙個適當的優先順序。利息的計算和跟蹤方法因專案不同而互有差異，但是，這類跟蹤是必須做的。
盡快償還你的技術債務吧，否則你會為你的輕率而後悔。
函式式程式設計原則的應用
（edward garso）
函式式程式設計最近又在主流程式設計社群裡火熱起來了，其部分原因是計算機晶元工業正在向「多核
」發展，函式式范型（
functional paradigm
）的特性恰好能應對多核時代的挑戰。函式式程式設計在這方面的應用固然重要，但這並非本文把它推介給你的原因。
掌握函式式程式設計范型（
functional programming paradigm
）能極大地提高你的**質量，不管是在哪類應用環境下。如果你能深入領會並熟練運用函式式范型，那麼你的設計就會顯示出更高的引用透明性（
referential transparency
）。引用透明性是乙個非常重要的屬性：它意味著函式不管在何時何地被呼叫，都保持一致的行為，同樣的輸入得到同樣的輸出結果。也就是說函式的輸出值很少
——理想的情況下根本不會
——受制於由多變的狀態值帶來的***。
過程式**（
imperative code
）最突出的缺點就是狀態變數眾多。每乙個讀到這段話的人都曾經有過這樣的經歷：一些值在某個特殊的位置會變得跟預想的不一樣。可見性語義（
visibility semantics
）有助於去除一些隱蔽的錯誤，或者能極大地縮小發生問題的根源範圍，但是，罪魁禍首可能還是因為在設計思想裡使用了太多變化莫測的狀態值。
在原來的思路上，我們當然無法再獲得多少幫助。因此，需要引入物件導向程式設計來提公升此類設計，因為在經常展示的物件導向例子裡，關聯的長壽命物件（
long-lived objects
）之間可以方便地呼叫狀態因子方法（
mutator method）——
這可能也會有危險。然而，在靈活的測試驅動設計裡，特別是當確信要
「模仿角色，不用物件」（
mock roles, not objects）（
1時，不必要的易變性就能被排除在外了。
最終解決辦法是實現一種設計，其典型特徵是負責分配數量更多、粒度更細的函式，這些函式依據傳入的引數做相應的處理，而不是依賴於易變的成員變數。這樣不僅能減少差錯，並且在將來也容易除錯，因為在這些設計中定位奇怪變數要比在特定場景推斷出錯誤的賦值要容易得多。這樣在引用透明性上就
提高了乙個層次
，沒有什麼能比學習一門函式式程式語言更能使這種感受深入人心了，在函式式程式設計裡，這種計算模型就是標準。
當然，這種方法不是在所有情景下都是最好的選擇。舉例來說，在物件導向系統裡，針對此類問題，領域模型開發（
domain model development
）（比如用一系列協作來分解複雜的業務規則）好過基於使用者介面的開發。
掌握了函式式程式設計范型之後，你可以把從中學到的知識應用到其他領域。物件系統（舉個例子）將會從引用透明性的優點中獲益良多，比你所相信的更加符合它們的功能屬性。事實上，甚至有些人斷言說函式式程式設計和物件導向的
頂點相互映照
，如同計算形態裡的陰陽兩面。
1 1
程式設計師應該知道的97件事
上星期拿了三本書來看，其中一本就是 程式設計師應該知道的97件事 大概通讀了一遍裡面有73位著名的人物，分別寫了97件事。每個人都有自己總結的一句話，對於程式設計師們確實很實用。這裡面的人物在程式設計師這一職業中有工作20年以上的經歷，有自己開公司的也有是博士 教授的。若能認真遵守這97件建議，我想...
讀《程式設計師應該知道的97件事》筆記
技術債務 當你發現必須在 幹得好 和 幹得快 之間做出抉擇的時候，一般都會選擇 幹得快 並提醒自己將來再來返工。下一輪迭代自有其新的問題，工作重點轉移到新問題上，老問題還存在。martin fowler把它分成 蓄意和無意 把技術 債務立即記錄到任務卡上，在惡化前償還。無論你承諾了什麼，都得小心處置...
《程式設計師應該知道的97件事》 不斷學習
你需要不斷學習，才能保持自己的 市場號召力 否則，你會變成恐龍，在乙個職位上日復一日，直到有一天，你不再被需要，或者你的工作被外包給了某個更便宜的機構。為了保險起見，你需要為你自己的教育負起責任。以下列出了一些學習途徑，它們中的大多數可以在網際網路上免費獲得。如果你真的想沉浸在一項技術中，那就親自動...