tag:blogger.com,1999:blog-1298974142445162186.post5281722093899625540..comments2024-03-19T15:58:12.198+08:00Comments on 搞笑談軟工: 你的軟體架構有多軟Teddy Chenhttp://www.blogger.com/profile/02066842119056439711noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-1298974142445162186.post-9429226334863891682016-02-18T13:41:05.424+08:002016-02-18T13:41:05.424+08:00多使用UML 做分析就好了多使用UML 做分析就好了ozzyhttps://www.blogger.com/profile/15588940940526463385noreply@blogger.comtag:blogger.com,1999:blog-1298974142445162186.post-26160162641272410952010-04-22T22:35:59.256+08:002010-04-22T22:35:59.256+08:00這邊講的『偷跑』比較像是 iteration 0,就是專案開始之前的準備活動。就 Teddy 的認知...這邊講的『偷跑』比較像是 iteration 0,就是專案開始之前的準備活動。就 Teddy 的認知 spike solution 比較像是專案已經正式開始之後,用來將某件不確定性很高的工作區分成 spike activity 和 implementation activity(錯了請更正 Teddy)。不過,不管如何,其實精神都是一樣的,所以你說得沒錯,就是 spike solution...Teddy Chenhttps://www.blogger.com/profile/02066842119056439711noreply@blogger.comtag:blogger.com,1999:blog-1298974142445162186.post-66133214780871451662010-04-22T13:42:08.757+08:002010-04-22T13:42:08.757+08:00偷跑是指spike solution嗎?偷跑是指spike solution嗎?Hector Leehttps://www.blogger.com/profile/16869818215231172762noreply@blogger.comtag:blogger.com,1999:blog-1298974142445162186.post-20069832338196804292010-04-21T21:04:20.622+08:002010-04-21T21:04:20.622+08:00Hi Hector:
在開始一個新的專案之前,Teddy 會先『偷跑』把軟體架構框架先定義好並且做...Hi Hector:<br /><br />在開始一個新的專案之前,Teddy 會先『偷跑』把軟體架構框架先定義好並且做出一個雛型出來(姑且把這個偷跑階段看作 iteration 0,耗時幾天到2周左右)。此時的軟體架構只是很粗略的概念驗證,用來評估此架構能否支持後續的功能開發 (算是一個空殼子)。專案正式開始之後藉由每個 iteration 完成若干個 stories (需求) 來逐步的完成軟體架構中的每個元素。<br /><br />當然這麼做是有一些先決條件。如果開發團隊中沒有對於軟體架構比較有經驗的人,或是開發團隊對於新的專案領域之前沒有類似的經驗,那麼要在短時間找到一個軟體架構雛型是比較困難的。例如,Teddy 沒有做過 ERP 系統,也不知道有沒有現成的 ERP 軟體架構可以直接拿來抄(直接抄襲合適的軟體架構這是很有效也很管用的一招),在這種情況下如果要 Teddy 在兩個禮拜內定義出 ERP 軟體架構雛型可能就沒辦法達成要求。此時,也許可以考慮混用 UP (Unified Process) 和 agile methods。套用 UP 的術語,在elaboration phase (大概 2-6 個 iterations 左右,依據專案大小而調整) 之後 architecture baseline 需要成型,這樣可以避免過多的 up-front design 以及降低『發散到不可收拾』的問題。<br /><br />當然,agile 死忠者可能會說,不要想那麼多,直接做功能,在透過 refactoring (refactor to patterns) 慢慢建構起軟體架構。不過說真的除非開發團隊的人都很強,不然這一招很有可能會演變成您所說的『發散到不可收拾』。<br /><br />最後,可能也是最重要的一點,就是平常要多看 software architecture 與 design patterns 的書或資料。如果全部或大部分的開發人員都經驗不足,何方法或是流程能幫上的忙就很有限。Teddy Chenhttps://www.blogger.com/profile/02066842119056439711noreply@blogger.comtag:blogger.com,1999:blog-1298974142445162186.post-71658474051339710982010-04-21T14:04:05.411+08:002010-04-21T14:04:05.411+08:00之前有一次試著在需求/設計/開發階段做Iterator, 結果案子發散到不可收拾, 不知道您是怎麼做...之前有一次試著在需求/設計/開發階段做Iterator, 結果案子發散到不可收拾, 不知道您是怎麼做收斂的?Hector Leehttps://www.blogger.com/profile/16869818215231172762noreply@blogger.com