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

標籤：問題   代碼   工作   演算法   程式   如何   測試   軟體   簡單   

前幾天應老師課設要求，選取了課程推薦參考書《移山之道》並讀了一部分，使我發現了我目前進行中的工作中的諸多不足。

首先這並不是一個風格非常嚴肅的書，作者的敘述性比較強，並且能夠自問自答，就已經解決了我不少疑惑。

但是同時，我也從自身出發發現了一些問題：

1、在Team 專案中，工作量如何分配？如果對於一個足夠成熟的團隊，可以假定每個人都是可以信賴的，那麼這個時候就可以將工作量接近平均地分配，保證每一個人的利益，但是在我們目前這種不成熟至只做一次項目的團隊中，首先工作量的分配問題就已經很難找到平衡點。因為相互之間非常熟悉，所以考慮到個人的性格習慣、知識儲備、團隊認識等差異，平均分配工作的方式寸步難行；但是過分不平衡的分配會導致破壞團隊向心力等一系列問題。

2、運行效率和開發效率之間應該怎麼權衡？在以往的練習中，老師會要求我們盡量最佳化演算法，精進運行效率，不斷提高代碼品質。但是在這一次最接近實際開發的過程中，我們發現過度追求對於演算法的最佳化會大大降低我們的開發效率，使得我們開發代碼的其他步驟卡在演算法這一瓶頸上。我們盡量降低對演算法的要求來追求更高的開發效率，結果就是犧牲了一部分演算法的運行效率，這樣做不知道是否明智？

3、我很贊同書中所述的正常化開發流程，但是在實際的開發過程中，我們的團隊並不成熟，我們的成員已經相互理解並且能很好的溝通，團隊中並不是每個人都可以擔當，所以正常化的開發流程一定程度上在我們這種小規模的開發中並不適用。

4、最後是關於bug與測試的。首先我們必須接受我們的程式是有很多bug的。但是怎麼判斷這些bug的重要程度？怎麼確定對某個bug的修改不會影響其他功能？有沒有一種比單元測試更簡單快捷的方式來保證所有單元的正確性？即使我們經過了足夠的測試，還是不能保證在實際運行中不會出錯。那麼在維護階段出現bug有沒有比打補丁更規範適用的方法？

這些問題在實際的Team Dev看來可能相當幼稚，甚至在我經曆了這一學期的鍛煉之後就能夠輕而易舉地解釋，但是在目前來說，這些問題實在是一直困擾著我。希望在以後的開發過程中我能夠通過自己的努力解答這些問題。

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