軟體架構師應該知道的97件事 筆記(三)

31. 程式設計是一種設計

 

代碼即文檔，寫代碼即是設計行為，而非生產行為。

 

32. 讓開發人員自己作主

應該給自己的團隊足夠的自主權，讓他們發揮自己的創意和能力。不要過於拘泥於細節，要為開發人員創造一個良好的開發體驗，如自己設計的API是否易於理解及使用，如果經常被誤用，應該怎麼修改。而且要創造一個良好的氛圍，讓大家主動起來，如果遇到什麼問題，及時的向你徵求意見。

 

33. 時間改變一切

讓結果說話，認真執行KISS原則。現在的設計，可能會被兩三年之後的自己所否定，同樣，以前的設計也容易被自己否定，所以不要跟以前的工作過不去。

 

34. 設計軟體架構專業為時尚早

軟體開發仍處於相對初級的嘗試階段

 

35. 控制項目規模

盡量控制和縮小項目規模，提高項目成功機會。

a) 抓住真正需求

b) 分而治之

c) 設定優先權

d) 儘快交付

 

36. 架構師不是演員是管家

炫耀和作秀放到市場營銷上去，而不是設計中，架構師應該把自己看成管家，承擔著管理他人資產的責任，為客戶利益著想。

 

37. 軟體架構的道德責任

任何浪費使用者時間的行為，就是不道德的行為。即使只浪費使用者一點時間，但影響到幾百萬使用者時，累加起來就是一個非常長的時間。應該浪費自己的時間，節省使用者的時間。

 

38. 摩天大廈不可申縮

軟體相對建築，擴充新功能要簡單的多，而且產品發布越早，公司的淨收益就會越高，所以，應用軟體只要具備了使用者要求的關鍵功能就發行就緒了。提早發布，還能持續改善軟體架構的品質。

 

39. 混合開發的時代已經來臨

混合編程是指在同一套軟體系統中同時採用多種核心程式設計語言。

把若干強大的工具組合起來，形成更巧妙的解決方案。

 

40. 效能至上

效能和其它指標一樣重要，減少軟體回應時間，提高人機互動效率。

不要拿摩爾定律來安慰自己，認為硬體及系統的速度足夠快並且以後會更快，而忽略了軟體效能。

 

41. 留意架構圖裡的空白地區

架構圖中的兩個模組之間，仍有很多細節需要考慮，比如A和B的通訊，在架構圖上可能只是簡單的一個箭頭，但實際上要考慮兩個程式之間的回應時間，如果逾時如何處理，如果中間電纜出問題怎麼辦等。

 

42. 學習軟體專業的行話

使用行話可以提高交流品質及效率。如企業架構模式、應用架構模式、整合模式、設計模式、反模式等。

 

43. 具體情境決定一切

設計架構的過程就是做出明智決策的過程。脫離了具體的情景比較技術的優劣是無意義的。

 

44. 侏儒、精靈、巫師和國王

一個團隊中要有各種性格和各種特長的人，招聘時盡量招聘不同性格的人。

相同的人在一起，視野往往不夠開闊。安排任務時也盡量根據團隊成員的特點來安排，讓大家相互學習。

 

45. 向建築師學習

要想成為偉大的建築師，優雅豐富的心靈遠比聰明才智重要。 --- 弗蘭克·勞埃特·賴特

建築師應該是偉大的雕塑家，或者偉大的畫家，否則他不過是個建築工人。 --- 約翰·拉斯金

架構應該蘊涵適當的藝術成份。