現代軟體工程 第十一章 【軟體設計與實現】 練習與討論

標籤：android   使用   java   sp   問題   代碼   工作   時間   bs   

一、            如何避免在產品開發後期不斷有重大修改，導致其他模組的連鎖反應？

我認為首先前期的需求分析要儘可能完善並確定，需求變更是程式員所不能承受生命之重。另外題目中談到的設計模式變更方法，是個很好的控制策略。項目早期採用Tell-mode，可以先行設計並編碼，有較高的自由度；到了項目穩定階段，採用Ask-mode，預設不同意變更設計，需要等待肯定回覆，有效避免了修改的頻繁，避免其他模組的連鎖反應。

二、            每周進度報告

報表可以協助我們掌控項目進度，把握項目目標。如果你看到每個人每天花費的時間在不斷增加，但是真正需要解決的Task和Bug都沒有變化，甚至緩慢增加，則意味著團隊離目標越來越遠。

三、            如何避免詫異反應

1.解決客戶對功能詫異問題：PM的分析和說明能力要可靠，甚至敢於拒絕。需求說明中要從使用者的角度去描述和解決方案，鼓勵使用者經常參與設計和計劃。

2.解決各模組功能不配合問題：利用“情境驅動”方法，首先保證典型的使用者情境能夠實現；從情境出發，各模組更容易相互整合。

3.解決新手無法開發問題：任務估計值乘以4，或者分配其他工作比如測試，這也是很好的貢獻。

四、            團隊成員不給力

軟體工程其實就是“人”的問題，在軟體開發過程中要恰當得處理人與人之間的關係。實際中各個角色不一定能各司其職。一方面因為個人利益拖三拖四，從編碼到測試都落後於原來的計劃，更何況當初的需求定義的本就不合理；另一方面，有人的能力不夠，比如語言不通，或者沒有開發過完整的大程式，勢必會拖全組後腿。前一點大家都容易克服，也依賴PM的領導能力；而技術水平與經驗不可一蹴而就，大家既然在這專業混，如果技術讓人唏噓的話，臉上也無光啊！

五、            解決問題OR搭架構

文章吐槽了Java程式員出現的一些問題，Java的使用方式影響了人們對它的好感。每個人都把自己想象成架構師，淋漓盡致的發揮物件導向特性，這不是在解決問題，而是計劃問題，導致有非常多的層次和大量的抽象概念以及樣本化代碼，別人很難理解這些代碼在做什麼。可能我們在荒野中看到的大部分Java代碼，很多是非常差的開發人員寫出來的。Java已經最大程度的被OO束縛，從代碼到整個Java生態系統。即使越來越多的開發人員意識到這些問題，並重返編程本質，也難以掙脫現在的局面，Android工程師依舊被使用Java困擾。

現代軟體工程 第十一章 【軟體設計與實現】 練習與討論