1、程序不會照自己所想的跑。只會照所寫的跑。2、我對軟件設計的方式導出的結論，有兩種方式。一是把軟件設計得單純到很明顯不會有缺陷，不然就是把軟件設計得復雜到沒有辦法看到明顯的缺陷。3、有意見的話你寫。4、要殺一個程序員不需要刀，改三次需求就好無論需求多晚才能確定，完工5、期限永遠不會變。這是所謂的「期限守恒定理」。6、客戶總是覺得水跟追加需求是不用錢的。7、一個人掛了大家都掛了。8、bug過了一晚可能就變成需求了。9、顧客想受PM喜歡，要自己了解到系統開發需要時間與金錢，早點確定需求。PM想受顧客喜歡，則要讓程序員討厭自己。很多PM跟程序員都暗自想著有錢有時間的話什么系統都想自己動手做，這樣10、有成就感不過都沒這種機會。11、質量的劣化程度依需求改變的次數與規模而定。12、業務是認為空想能夠實現的夢想家。PM則是深信任何障礙都能突破的冒險家。程序員則是被夢想家和冒險家拋到漆黑海里的漂流者。13、有才能的程序員第一次看到設計細節時，要先理解程序的目的。接下來要設法讓PM了解到用指定的方法、時間并無法完成這個工作。14、程序是運氣與直覺堆砌而成的奇跡。若不具備這兩者，不可能以這樣的工時實現這樣的需求。修改需求是對奇跡的褻瀆行為。而追加修改則是相信奇跡還會重現的愚蠢行動。15、PM需要持久力，程序員需要爆發力。16、每天準時下班，工作會變多。17、完美的程序需要完美的時間與金錢。18、詳細設計要在程序代碼的批注里做完。批注是程序員唯一的自衛手段，至少要讓自己看懂。19、還有時間看程序代碼的話就執行他。CPU跑得比腦細胞快。至少這時候可以休息。20、程序的異常該稱為「bug」還是「技術或需求上的限制」是看期限還剩多久決定的。21、禱告上線沒有問題，然后跑吧。22、程序不是用腦記的，要用身體記住。23、當誰寫的程序代碼跑出嚴重bug時，那個人通常都不在了（xxx定理？）24、需求書就像航海圖，客戶則是水流。水流陰晴不定，航海圖就變垃圾。25、程序員必須在沒有航海圖的海上憑自己的力量找到大陸。26、多想個10秒鐘，你可以不說「嗯，這個做得到」。27、人是無法從別人失敗記取教訓的動物。砍成本、改需求、加需求、趕上線，從來沒有人從眾多失敗中記取教訓。28、老手用來提振精神的魔法格言：「比起以前來說算是輕松…」。新人用來提起干勁的魔法格言：「把這件工作做完的話…」他們還不知道工作是沒有終點的。29、程序、PM、經理不是職務。是逃不掉的連環責任。30、能夠迅速想到解法的程序員太多了。31、他們能用一分鐘想到方法，用一天去寫程序。32、上線后的除錯才叫做bug。33、追加需求確定后交貨期限就無法確定，交貨期限確定后追加需求就無法確定。這稱為「追加需求與交貨期限的測不準原理」。34、除三個錯就會冒出一個新錯。這稱為bug的無窮循環。不祥的預感總會實現。不過程序員不應該去煩惱不祥的預感，那是PM的工作。35、不懂計算機的操作者是發現bug的天才。而且他們通常無法重現那個bug。36、每次開會就更改需求的客戶，他的操作手冊要等到程序上線后才能寫出來。37、程序員所不滿的需求也一定會讓客戶不滿。（這是說程序員覺得難寫的地方常常是PM溝通有落差）38、正因為健康，程序員才能做不健康的事。39、那是你說的需求，真的。40、壞了也是因為需求。41、「程序代碼的可信度，不會比寫的人還可信。」42、唯一不產生bug的方法，就是不寫程序。第二好的方法，就是在期限跟43、人員確定之后的每次改需求，都重新檢視過整個項目。(但通常大家都忘了)44、共同責任是程序員的責任。45、如果可以改行的話，想找個準時下班不叫「逃跑」的工作。46、對職業程序員來說，漂亮的程序是單純而自然的邏輯、簡單而基本的指令、豐富的批注，也就是新手程序員也能馬上動手改的程序。而要寫這樣的程序，需要單純、簡單、美麗的需求。但可惜客人總是喜歡搞很復雜。47、PM對程序員說的「常識」每三小時變一次。48、小學生時第一次看到計算機，初中時第一次學會怎么用，高中與大學學會程序語言，出社會后才發現自己早就走錯路49、「不要讓老板當業務需求比較好」50、說來說去，要去研究根本不知道為什么會運行的東西為什么不會運行了，找愛迪生來也沒搞頭。51、就算程序里沒bug，編譯器會有bug。就算編譯器沒bug，OS會有bug。就算一切都沒bug，客戶會決定什么是bug。52、需求與需求書是不同的東西，通常都是。53、比期限更重要的是靈感與睡眠。比知識與經驗重要的是手冊與時間。過了三天看上去就是別人寫的程序代碼。無論怎么檢查，不管怎么確認，上線前一晚就是睡不著。沒有什么事情比讓一開始就找不到任何bug的程序直接上線還要可怕的了。

總結

以上是生活随笔為你收集整理的收集53个程序员段子的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。