知乎神回覆：集中全世界程序員的力量，能三天內開發手機淘寶嗎？

這是我在知乎上看到的一個問題，我相信做爲咱們程序員來說，心裏確定都知道答案了。確定不可能的，除非阿里的程序員把代碼拿出來，而後再部署一套，畢竟全世界的程序員也包括阿里的程序員嘛。可是，這個確定不是題主想問的。

其實，我更想經過這個問題給你們推薦一本書，那就是《人月神話》，相信不少程序員都聽過這本書，我不知道又有多少程序員讀過這本書呢？我只是想說：對於程序員來說，若是你想開闊本身的眼界，豐富本身的知識，軟件工程和軟件管理類的書籍是必讀的書目，並且你若是又想往技術管理的方向進階的話。

這個問題，若是從《人月神話》的角度去回答的話，應該是這樣的：

在衆多軟件項目中，缺少合理的時間進度是形成項目滯後的最主要緣由，它比其餘全部因素加起來的影響還大。致使這種廣泛性災難的緣由是什麼呢？

首先，咱們對估算技術缺少有效的研究，更加嚴肅地說，它反映了一種悄無聲息，但 並不真實的假設——一切都將運做良好。

第二，咱們採用的估算技術隱含地假設人和月能夠互換，錯誤地將進度與工做量相互混淆。

第三，因爲對本身的估算缺少信心，軟件經理一般不會有耐心持續地進行估算這項工做。

第四，對進度缺乏跟蹤和監督。其餘工程領域中，通過驗證的跟蹤技術和常規監督程 序，在軟件工程中經常被認爲是無謂的舉動。

第五，當意識到進度的偏移時，下意識（以及傳統）的反應是增長人力。這就像使用汽油滅火同樣，只會使事情更糟。愈來愈大的火勢須要更多的汽油，從而進入了一場註定會 致使災難的循環。

在《人月神話》中有這麼一句話：

簡單、武斷地重複一下 Brooks 法則：向進度落後的項目中增長人手，只會使進度更加落後。

在《人月神話》中，它講到了人們的一個謬誤：

那就是不少人的思考方式是在估計和進度安排中使用的工做量單位：人月。成本的確隨開發產品的人數和時間的不一樣，有着很大的變化，進度卻不是如此。所以我認爲用人月做爲衡量一項工做的規模是一個危險和帶有欺騙性的神話。它暗示着人員數量和時間是能夠相互替換的。

什麼意思呢？

人數和時間的互換僅僅適用於如下狀況：某個任務能夠分解給參與人員，而且他們之間不須要相互的交流。可是在咱們的軟件編程，系統編程中，這是不可能的。

當任務因爲次序上的限制不能分解時，人手的添加對進度沒有幫助。不管多少個母親，孕育一個生命都須要十個月。不會說由於一個母親懷孕 10 個月可以生出一個孩子，因此我找 10 個母親，就能夠在一個月內生出一個孩子來。

對於能夠分解，但子任務之間須要相互溝通和交流的任務，必須在計劃工做中考慮溝通的工做量。所以，相同人月的前提下，採用增長人手來減小時間獲得的最好狀況，也比未調整前要差一些。由於可分解，可是每一個子任務之間又溝通密切的話，隨着人數的越多參與，溝通的時間成本也會顯現，因此，人數越多可能溝通的時間成本也會致使項目延期，開發的很慢。

溝通所增長的負擔由兩個部分組成，培訓和相互的交流。每一個成員須要進行技術、項目目標以及整體策略上的培訓。這種培訓不能分解，所以這部分增長的工做量隨人員的數量呈線性變化 。

軟件開發本質上是一項系統工做 —— 錯綜複雜關係下的一種實踐 —— 溝通、交流 的工做量很是大，它很快會消耗任務分解所節省下來的我的時間。從而，添加更多的人手， 其實是延長了，而不是縮短了時間進度。

因此，你說呢？若是集中全世界程序員的力量，三天以內能實現一個手機淘寶嗎？答案是顯而易見的，不可能。由於人越多，就越亂。可能光架構的設計這些程序員就能爭吵一個月。尤爲是集中全世界的精英程序員來開發的話，協調溝通，夠你們喝一壺的，你們吵吵一個月都未必可以進入開發階段。

原文連接：http://mp.weixin.qq.com/s?__biz=MjM5NDkxMTgyNw==&mid=2653063239&idx=1&sn=29a6a749f824e5ac4550ac5a4c6b4d1a&utm_source=tuicool&utm_medium=referral

---

自學C/C++編程難度很大，不妨和一些志同道合的小夥伴一塊兒學習成長！

C語言C++編程學習交流圈子，【點擊進入】微信公衆號：C語言編程學習基地

有一些源碼和資料分享，歡迎轉行也學習編程的夥伴，和你們一塊兒交流成長會比本身琢磨更快哦！