小看了軟件危機，喫虧了，爬起來

        以前從來沒有認真的考慮過軟件危機的問題，這次團隊開發的過程中，只是匆匆做好規劃而帶來的重複工作、低效率等問題都嚴重的影響了開發的進度。
        當然上面的這些問題，還都是在不考慮很大一部分同學都還是新手的原因。一直都想問老師個問題，就是多數團隊成員在編程方面還不是很熟練的情況下如何避免或者說是減少軟件危機對整個項目進度的影響。雖然你可以把一切都想的，計劃的很完善，但是有時候，明明是一個很小的問題，卻需要你讀一段很長的代碼，而且還有相當的一部分代碼是不正確的。往往讓你有一種衝動，就是什麼也不想說，乾脆自己上手來寫完其負責的整個模塊。
       在編碼的時候，往往會碰到某個成員，不惜花費很長的時間來爲了一個較人性的設想不斷的修改自己的代碼，明明用另一個方法也許就是幾分鐘的事兒。這種精神雖然值得敬佩，但是畢竟影響了項目的開發進度，所以我個人覺得是不值得提倡的。
       前期的開發過程中，很多時候，當新手碰到難點時，經常就是跳過，等待積累多了一些以後再回來修改。也許在學習編程的過程中應該這樣，但是，在真正的做一個項目的時候你會發現，有時候，連自己都不願意回頭看自己寫的東西，更何況別人呢？
       在思路尚未清晰的時候不要亂敲代碼，不然你很可能很快就會發現，忙活了半天之後，才意識到前面寫的都錯了。所以小組成員在開始寫之前一定要把想法表達出來，與設計者交流，以免做無用工。
       做這個之前，一直在想自己能有什麼收穫。看，現在收穫已經來了。