我認為一天最好的開始是早上起床后泡杯好咖啡�？Х葯C里散發(fā)出迷人的香味，太美味了。煮好之后，倒進杯子里，放點糖，就O了。

你有沒有想過用圖標來表示泡咖啡的流程？或者其他普通的事情，例如洗澡？當然沒有！

對于其他比這些麻煩一點的事情，比如軟件項目開發(fā)，少量的設計工作是很有用的，或者說是必須的。

問題就出來了，架構(gòu)設計值得花那么多時間和精力么？好吧，還是先回答這個問題：早期的設計能降低項目中的風險么？

項目的目標和挑戰(zhàn)越大，風險越多，成功完成的難度就越大。 

如何識別風險：最簡單的就是從需求出發(fā)，找出看起來最難實現(xiàn)的事情。 

收集需求是決定做什么和怎么做的基礎。當然，有時候?qū)е马椖渴�敗的問題從這一開始就出現(xiàn)了，有一些假設低估了這一關(guān)鍵關(guān)鍵階段并且從根本上動搖了架構(gòu)師的角色：

1. 需求分析是別人的職責

（業(yè)務）領(lǐng)域驅(qū)動架構(gòu)選擇，而不是反過來，（業(yè)務）需求會產(chǎn)生架構(gòu)問題。至少你得協(xié)助業(yè)務分析師（進行業(yè)務分析）。

2. 我一邊寫代碼一邊學習領(lǐng)域知識 

雖然軟件原型（開發(fā)）是降低工程上的風險的好辦法，并且可以識別出最困難的問題，但是寫代碼對分析業(yè)務領(lǐng)域來說就是浪費時間。提前進行建模才是提出產(chǎn)出比最好的方式。 

3. 相關(guān)方已經(jīng)完全理解了需求

人和人之間徹底的溝通是很難的。如果別人不明白你在做什么和為什么做這些的話，軟件架構(gòu)師的角色是很難做的。

4. 業(yè)務領(lǐng)域和架構(gòu)決策是無關(guān)的 

開發(fā)人員可能會從過去的項目中拷貝架構(gòu)（設計）。也可能是遵循公司的標準，但是卻忽略了之前做出選擇的原因，他們很可能就不知道現(xiàn)在這個項目的（實際）要求。

5. 我已經(jīng)明白了需求

至少你腦子里應該有需求文檔，但是設計人員應該使用模型來增強推理能力并且暴露出有風險但并不是很清晰的方面。

標簽： 軟件架構(gòu) 軟件設計師 

版權(quán)申明：本站文章部分自網(wǎng)絡，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。