讀《移山之道——VSTS軟體開發指南》

標籤：des   ar   sp   art   問題   代碼   工作   時間   bs   

讀《移山之道》這本書差不多用了一個星期的時間，感覺還是收穫了一些知識的，以前只是會簡單地編個小程式（雖然現在也是這樣），但看過這本書之後我對軟體開發這個概念的認識度有了從一片模糊到瞭解大體概念的轉變。但是畢竟用一周時間讀透這麼一本完整的書不是一件簡單的事情，我也只是瞭解到了一些皮毛，在閱讀的過程中也遇到了很多問題，一些基本的問題在後面的學習中已經解決了，有的還在困擾著我。

（1）在書中瞭解到了一個術語叫 Work Item，但書裡並沒有提到一個vs裡出現過的叫做issue的Work Item，這是什麼情況呢？

　　經過瞭解發現，這本書裡講到涉及到vs的都是vs2005，由於版本較老，沒有issue這個Work Item，而現在的高一點版本的vs則有issue。我沒有較多的實踐用過這個Work Item，但據我查資料所瞭解這個Work Item實際用起來還是挺方便的，預估風險以應對敏捷開發裡的突髮狀況等等。

（2）關于敏捷開發，前期的設計很重要，開始可能會寫的非常簡單，但經常在後期代碼增多時發現簡單的方法已經不能用了，會出現不一致的情況。之後可能還要重寫，比較繁瑣。當然解決這個問題的方法無疑是在下手之前先考慮周全，但是這個看似簡單的方法幾乎沒有人能百分之百做到，感覺比較不好把握。

（3）結對程式設計是一類創新型的編程方法，一個獨立的工作由兩個人一起合作完成，這種方法有利也有弊。

　　益處很多，比如

　　1）結對程式設計讓我們在有partner的前提下更有信心，有人和自己並肩作戰。也更有動力，不能被同伴落下，不能拖同伴的後腿。

　　2）由於是兩個人一起完成，所以思維更加多元化，方法也比較多，可以在眾多選項中選擇最好的那個，提高編程的品質。

　　3）結對程式設計能夠更有效地交流，相互學習和傳遞經驗。

　　Every coin has two sides.結對程式設計的益處這麼多，那有什麼弊端呢？

　　我想經曆過的程式員都知道，這種編程方式需要雙方進行深入的溝通交流，交流的好了才能保證代碼的品質，但是萬一雙方不是適合彼此的partner，問題就大了，從來不溝通  交流，又或者兩個人的思維習慣變成習慣差異大，自己做自己的又做不好，去合作又找不到合適的方法，確實很揪心呢。

　　不過這種問題也很好解決，因此我們應該要學著去結合雙方的思維和能力，去一起解決問題。

（4）這本書只要瞄過一眼的就知道，整本書是講故事為一條線來展開的，剛接觸的時候還覺得很新鮮，讀到中間會覺得有點為了講故事而講故事，很牽強的與知識聯絡到一起，但是讀到最後就變得豁然開朗，回顧整本書，如果沒有這個故事，那可能有一大半的東西理解不了也記不住，總之這種方式還是挺迷人的，也能讓人更好的學習。但是這種方式是不是能讓大部分的人接受呢？我認為可以做一些調查，徵集大家的建議，好的地方繼續發揚，需要改進的地方加以修改，或許效果會更好吧。

（5）最後一個問題是我沒找到答案的，也思考了很久。TFS中為什麼不允許Dev自己新增工作呢？有什麼限制的地方？

讀《移山之道——VSTS軟體開發指南》