你的項目有一個大泥球么? 有什么解決辦法？
大泥球這個問題在之前我遇到過，但是不知道它就是大泥球。在我最早寫代碼的時候由于代碼量小，而且寫一次代碼之后我不會再去看他，所以我在程序結構上和變量的命名方式上沒有多大的考慮，是要能夠加快我的這次開發就行了。這造成了我的代碼可讀性比較差，而我也不喜歡讀自己之前寫的代碼。
你的團隊是用什么方式建造軟件?
我們組的設計模式是大教堂模式，我認為，在我們這樣的小規模編程使用大教堂模式要比集市模式好得多，因為我們的人數比較少，使用大教堂模式可以讓我們分工明確。我認為，集市模式更適用于開源社區這種人流量夠大的地方，集市模式可以讓人們自由地參與到軟件中來，這其實是用數量彌補了質量。
這些情況在你的團隊中出現過嗎？
作者主要講述了開源軟件中的過度依賴問題，這個問題在我們的工程中也遇到過。
這是后來大家說的 “瀑布模型”，它有什么特點?
瀑布模型（Waterfall Model） 是一個項目開發架構，開發過程是通過設計一系列階段順序展開的，從系統需求分析開始直到產品發布和維護，每個階段都會產生循環反饋，因此，如果有信息未被覆蓋或者發現了問題，那么最好 “返回”上一個階段并進行適當的修改，項目開發進程從一個階段“流動”到下一個階段，這也是瀑布模型名稱的由來。
你的團隊在開發中用了那些敏捷的思想和做法？
- 每日站立會議
每日站立會議是老師要求的，但是我覺得這個很有用，每天我們的隊員在一起匯報一下今天完成的任務和規劃一下明天的任務，這是很有實用價值的。我覺得最大的作用在于鞭策隊員每日按時按量完成自己任務。 - Scrum
Scrum 是一個敏捷開發框架，我們團隊是分為了不同的角色，PM，開發人員，測試人員。不同的角色做不同的事，大大提高了開發的效率
軟件工程的方法論到底有多少好處？同時好好讀一下兩個文章的評論。
軟件工程在之前有了解過，但幾乎沒有過實踐，覺得理論的都是空的，但是真的用過軟件工程的方法之后我覺得軟件工程的方法確實在某些方法很有用。例如迭代，以前遇到一個大的問題不知從何入手，感覺完全沒有方向，總是想要找到一個完全的解決方案，然而在迭代中，每次開發一個小的版本，一點一點添加，最后形成最終版，我覺得這個很有用，可以逐漸解決問題，至少能夠盡快開始問題。又比如說極限編程，極限編程中有四個核心價值溝通（Communication）、簡單（Simplicity）、反饋（Feedback）、勇氣（Courage）。 XP用“溝通、簡單、反饋、勇氣”來減輕開發壓力和包袱；無論是術語命名、專著敘述內容和方式、過程要求，都可以從中感受到輕松愉快和主動奮發的態度和氣氛。這是一種幫助理解和更容易激發人的潛力的手段。XP用自己的實踐，在一定范圍內成功地打破了軟件工程“必須重量”才能成功的傳統觀念。總之，軟件工程的學習對于我們進行軟件開發是很有好處的。
文章列表
留言列表
