個人閱讀作業

標籤：問題   代碼   工作   ad   line   設計   程式   技術   編程   

????《移山之道》這本書，光聽書名就有一種霸氣在裡面，自古以來，"道"這種看不見摸不著東西，一直是人類的探索求知慾的終極目標所在，道即是道理，是規律，是方法，作者將編程的道理與規律比作"移山之道"，這本書光從書名就已經吸引了我。這是一本很有誠意的書，鄒欣老師並不故作高深，語言非常平易近人，你可以輕易的分辨這本書和《軟體工程---實踐者的研究方法》哪本讀起來更有趣（這才不是吐槽）。由於結對程式設計作業，只有零零碎碎的讀了一些，並不算多，只能說有一些小小的體會和問題吧。

????這本書的主要介紹了一種叫MSF軟體開發方法和VSTS工具，可是我基本把這部分快速的略讀了，後面的九到十一章講的是合作編程的問題，結對程式設計項目一直在折磨我們，（我和隊友的合作還算默契，就是程式總是出bug TAT），其實最大的問題還是溝通的問題，雙方想法的點點不同最後都會體現在代碼裡，那麼現在問題來了：Q0.挖掘機技術到底哪家強？……… （亂入了），好吧

????Q1.如何在團隊合作開發時，怎麼有效溝通？

????Q2.當團隊成員水平不平均的時候，如何保證所有人都能跟上進度？

????舉個實際的例子，本次結對程式設計，最開始我對C#不熟悉，代碼閱讀時很有問題，我的隊友閱讀程式能力很強，所以他的進度會有些快，最早我也沒太在意，當他開始開發的時候，我只能貢獻微薄的力量，慢慢的在中後期的時候，我個人才漸漸開始對這個項目的全域有了更清晰的認識，也有了一些新的想法，但是想回頭的時候deadline又很近了。

Q3.書中介紹了開發方法，但是當不是所有人都熟悉相應的開發方法時，進度有時候反而可能跟不上，尤其有deadline比較近的時候，這樣怎麼辦，是一步步按既定流程麼，還是什嗎？

Q4. 團隊成員工作的設計與分配，由一個PM來負責，那麼在他的設計中應該細化到怎樣的程度，能夠合理的發揮團隊成員的能力？

????

????????

個人閱讀作業