驅動測試開發(tdd)是唯一能讓你寫出沒有bug的程式的方法。只有結對程式設計是可行的。我們之所以成功就是因為我們使用的是遠端開發人員。等等等等……
像這樣的話每天我都能看見。
像這樣的風言風語十分能蠱惑人心，它愚弄我們，讓我們認為這就是我們不能遇到阿拉丁的那個茶壺裡的精靈的唯一原因。最終，這些人所寫的會讓你也這麼認為。
如果你隨機找100個程式設計師，問他們「開始乙個新專案前首先想到的技術方案上什麼？」相信你會得到100種不同的回答。
那麼，為什麼有這麼多的人看起來堅信自己的方法才是唯一可行的？
在我看來，這答案既十分的簡單，又十分的複雜。說簡單，是因為有些人就是喜歡說。說複雜，是因為軟體業實際上是一系列亞文化的聚合，它們不斷相互對抗來保衛自己的職業安全。我知道，這話有多重含義。
我之所以會談論這些，全是因為昨晚讀到了chris sturgill的一篇文章，是關於測試以及它們如何被過度吹捧。文章提到的所有觀點都有理有據，令人信服。
讓我們進入正題。
軟體開發中沒有所謂「正確」的方法。我重申：軟體開發中沒有所謂「正確」的方法。程式設計界裡有些人喜歡搞圖騰崇拜，他們拒絕接受這樣的事實。他們執著於幾小時前剛學到的一些誘人的新出現的熱門技術，他們認為這是能讓工作做好、能開發出可信賴的軟體的唯一辦法。
我很抱歉讓你們失望。這些新出現的熱門技術很可能並不新。很可能只是一些曾經流行的技術的新的市場炒作。從另一方面講，你拋棄以前學到的所有東西，你改變以前的所有做法，你全面擁抱你學到的這個新的「唯一」的方法。事情不是這樣的。別這麼做。
做乙個優秀的程式設計師就意味著你要學會妥協折中。這意味在a專案是你需要使用一種技術方案而在b專案上你需要使用另外一種。這意味這你需要在你的思路和老闆/客戶的要求之間做平衡。很多時候事情並不能做到雙方達成統一，但這並不意味著你該懊惱、痛斥為什麼不按你的思路去做。
真正重要的是，秉持自己的觀點，但柔軟的應用。
只有這樣，你才能走的更遠。
軟體開發方法的理解
1 xp，scrum是軟體開發過程的管理方法 其中包括時間安排，人力和物質資源按時間階段的劃分利用，主要體現 統籌管理安排 瀑布式開發也是一種開發過程管理方法。同樣xp，scrum也可以放在面向過程的開發中，但xp是為物件導向量體定製的衣服，給面向過程穿上，效率 效益就大打折扣。2 領域驅動設計，風...
軟體開發中的併發
併發作用 1.在互動式應用中，快速響應使用者的請求，提高感知響應的時間 2.充分利用硬體資源，計算資源 3.簡化應用設計 併發壞處 1.難於測試 2.併發應用執行在複雜的環境下，軟體不確定性增多 3.處理同步，通訊的問題，增加程式設計複雜性 4.併發開銷對效能的影響，包括上下文環境切換，同步等 併發...
軟體開發中的「格調」
在三年之前，我從學校畢業，進入公司，正式開始了軟體開發工作。我從完成第乙個開發任務的過程中學到了很多東西，包括 1 編寫程式只是軟體開發中的乙個流程，並非全部 2 程式編寫需要遵循一定的規範，遠遠不只是實現功能那麼簡單 3 程式編寫者是程式的第一負責人，要對自己的程式進行充分的自測，而非只要程式編寫...