通常程式設計情況下，會導致軟體專案變壞的一些列反應原文：the five shouts of good programmers
在任何一天，在這個世界上都有軟體專案正在失敗，這很常見。常見到當軟體產品按照預期發布時人們都會感到吃驚。這不是什麼新鮮事，基於被廣泛引用的standish group的chaso報告，這種事情已經已經發生了幾十年了。但是現在，在很多情況下，人們試圖盡最大努力去避免這種悲劇，但是經常公司的政治總是會比實用主義更具優先順序。只要不要太晚，這都是可以通過簡單的延遲來避免。
在這種情況下，程式設計師作為戰場的一線戰鬥人員，會比其他人都更早的看到這些問題。但是，程式設計師都會缺乏以一種簡單的方式解決此類問題的技能，這也就意味著很多情況下他們都只是在乙個已經注定命運的專案上埋頭苦幹。
通過一次又一次的觀察到這種情況，我意識到程式設計師們需要乙個高效的回退機制，這也就是為什麼我寫這個文章的原因。這些「吶喊」都只是隱喻層面的。也僅僅是當以下談及的問題場景出現的時候，你可以告訴自己的一些話，使得你有力量將一些不好的情況往好的方面發展。
假想一下你處於這樣一種情況，你需要去寫一些特定功能的**，但是同時類似的**已經存在。很顯然，最好的方案是修改已經存在的**，讓這些**對新的場景能夠相容。同時，這需要你將老的和新的測試場景都進行測試，以確保沒有引入任何回歸bug。專案管理人員為了時間考慮，會建議你簡單的將**拷貝乙份，然後進行修改，此時只需要測試新的應用場景。在這種情況下，你需要使用此條規則。「don』t repeat yourself!」。
其中乙個主要原因是，重複的**是bug的主要**地之一。當有兩個函式或模組，都實現幾乎相同的任務，在某一時刻業務發生了改變，此時很有可能程式設計師只會記得更新其中的乙個，而忘記了另乙個，這就產生了bug。同時這也降低了**的可理解度。如果當新人碰到這兩個幾乎相同功能的**時，會好奇究竟選擇使用哪個，甚至更糟的是，會兩個都用上。寫相同功能的**可能是中捷徑，但是最終還是會為此付出代價的。
第二個場景涉及到重複性的工作。程式設計師經常可能想要將重複工作自動化，但是管理者經常不會為此投入相應的資源，相反還會以「只需要幾分鐘」為藉口進行爭論。這些人經常不會意識到，重複性的工作很容易出錯，並且花費的時間會增長。5分鐘的工作可能會變成10分鐘，10分鐘的變成15分鐘，等等等等。很快，就會看到程式設計師瘋狂敲擊鍵盤，看上去很忙的樣子，但實際上並沒有完成什麼有意思的工作，很像乙隻敲鍵盤的猴子。
此時，程式設計師就可能需要使用「no monkey business！」了。程式設計師的職責就是程式設計，如果讓他們做一些欠考慮的，無意思的重複工作就是浪費他們的能力，最終會導致負面情緒的增長。除此之外，將一項任務自動化會讓程式設計師以一種批判的眼光去看著這件事，可能會在這個過程當中發現乙個漏洞，而這個漏洞可是是之前被忽略的。
在公司層面，很多活動中更傾向於規避風險。比如在廣告中，可能因為一句錯誤的台詞導致公關危機；在財務中，乙個錯誤的財務計畫可能會導致公司破產；在市場調查中，一件新產品需要被公眾所接受。然而，在談及技術上的規避風險是，公司通常會有很大的慾望去冒風險。通常表現在通過減少或免去測試來節約成本。儘管類似測試驅動開發這樣的工程實踐會帶來一些好處，但是我依舊聽到很多關於說服程式設計師不要寫自動測試用例來減少時間的爭論。一些人會說，真正的程式設計師是了解他們在做什麼，所以他們不需要測試；另外一些人會說，測試的結果最終不告知使用者，因此它不是產品的一部分，這就意味著測試時可以在程式設計師的私人時間內完成。
事實是，忽視安全在實際中太普遍了。人們不會意識到他們是在乙個不安全的環境中（譯：個人覺得是開發流程中的不安全性）工作。但是，你可以通過在乙個專案的事後分析的典型結論中來證明這個事實。他們通常會將失敗歸結於糟糕的需求或者糟糕的預估，但是永遠不會歸結到不安全的環境上。他們永遠不會說「我們失敗是因為我們的開發環境出的問題，它沒有預防一些錯誤的發生」。這就是為什麼我們需要使用「safety first！」
相對於其他的系統的工程來說，軟體開發時乙個比較年輕的系統工程。自然，也從其他的工程學裡借鑑了一些東西到軟體工程學中。其中乙個就是試圖去**未來的需求。
假設你現在是一位市政工程師，你被要求去建設一座雙車道的大橋。在任何時候，都值得去思考，這座橋需要四車道，因為這樣才能把基礎建的更牢靠，並且在未來想拓展成四車道也變得方便。按照這個邏輯，專案就有乙個額外的，沒有人要求的需求了。它是基於設計者的假設而加入的，同時設計者認為早做比晚做成本更低。
第乙個問題是，沒有任何跡象表明在需求出現前而去臆想需求會使得成本更低，尤其是我們使用現代的、迭代的實踐方法。第二個問題是，每當非被要求的功能性的需求被提起時，管理者通常決定不會解決。這就導致了乙個這樣的企業文化：**的質量參差不齊，有些會變「腐爛」直到完全沒用。更糟的是，它會降低程式設計師的士氣，因為他們所工作的內容是之後從不會被用到的，因此會變得沮喪。
如果是在這種情況下，當不必要的需求浮現時，程式設計師此時需要說「yagni！」。
這是為最喜歡的一條。程式設計是一種持續冒險的活動。你可能需要去檢視一些幾年前由你不認識的人寫的**。這些**可能執行在一些特定的場景下，你永遠不會知道你在此過程中會遭遇什麼，可能是一段很優雅的**，也有可能是完全無法工作的**。這才是程式設計的樂趣！
假設你現在是名廚師，你到了乙個一團糟的廚房裡。可能你有種立馬把裡面清理乾淨的衝動，然後才進行工作。作為一名程式設計師，當你遇到一團糟的**時，你也會有那樣的衝動。可能**的清理工作並不是專案的一部分，你這種好的想法也有可能被禮貌地推到一邊。「那是個好主意，但是我們現在不用去做它。」。此時，你需要說「yes now！」。
乙個成功專案的最重要的文化氛圍就是，一旦出現了問題，立馬修復。如果沒有這種文化氛圍，那麼就會出現「破窗」理論。然後程式設計師就習慣工作在那樣設計很垃圾的**之上。這樣團隊士氣就會受到傷害。因為是我將**搞得很垃圾和**本來就很垃圾就變得很重要。「yes now！」幫助團隊集中焦點在對的事情上，而不去關注是誰讓事情變得糟糕。
最後一條警告…
這五聲「吶喊」是很有用的工具，但是和任何工具一樣，濫用會適得其反。這些建議通常是用在當出現了一些壞的決策時，有些時候可能會導致一些衝突。衝突有時是個很好的提示，提示我們需要在多個選項中選擇乙個最好的方案。同時也意味著要小心使用這五聲「吶喊」。
維持常態是拒絕改變的一種心理傾向。當開始使用這五條告誡時，決策的思路也開始改變，很多人最初都會去拒絕。出於這個原因，最好的方案是溫和地使用這個五條告誡，同時在最關鍵的情況下使用它們。當改變發生後，其他人就會慢慢地注意到它帶來的好處，然後就可以在更多的場景進行應用。
改變很難。尤其是要改變我們使用了幾十年的習慣時。明智地使用者五條告誡，你會發現你的**和專案在逐漸地往好的方向改變。
《程式設計師的吶喊》導讀
程式設計師的吶喊 痛苦是本書的靈感源泉。唔，還有酒精。而當痛苦累積到一定程度的時候，我就會忍不住開始抱怨。再加上酒精作祟，什麼刻薄 甚至滑稽 的話我都說得出來。現在我還會時不時地回頭翻看這些東西，每次都忍俊不禁。原來我很毒舌嘛。和絕大多數程式設計師不同，痛苦在我身上留下了獨特的印記，迫使我的世界觀發...
譯 程式設計師開會的代價
簡評 這是 黑客與畫家 的作者 paul graham 的一篇經典文章。程式設計師作為抽象系統的創造者遵循 maker s schedule。寫 時需要整塊連續的時間思考，如果工作常常被幾個會議打斷，那一天下來根本做不了任何實質性的事情。程式設計師特別討厭開會的乙個原因是 他們的日程跟其他人不太一樣...
好的程式設計師和差的程式設計師
好的程式設計師，軟體產品質量高，問題少，維護工作量小 差的程式設計師，產品不斷地出問題，不停地修修補補 所以，專案更離不開差的程式設計師，因為問題不能沒有人解決。好的程式設計師，文件和編碼清晰，工作容易交接給其他人員 差的程式設計師，文件和編碼混亂，那堆可怕的複雜邏輯只有他自己能理解 所以，差的程式...