原则,策略,规范也是构架的一部分
原則,作為大的方向,影響到構架的設計和實現
- 運行效率和開發效率優先級,
- 可讀性和開發效率
- 安全性
- 穩定性
- 負載量
- 團隊開發
- 溝通原則
確定原則就是確定一個總體的方向,當一些可選項發生沖突的時候,就可以根據總的原則進行決斷。
如,當前這個系統需要進行一些技術性嘗試,而不是一個生產系統,那么,我們可以不考慮過多的安全,易用,穩定方面的設計,直接實現功能,解決技術問題就可以。
再如,系統的穩定性比較重要,那么,我們的穩定性設計就一定要可靠又可靠。
再如,系統的安全性比較重要,那么,數據的安全,訪問的安全就要謹慎又謹慎。
再如,系統代碼的可讀性和可維護性作為首位重要的原則時,代碼的質量,以及規范就非常重要,當遇到代碼結構不清晰,但是效率非常高的部分,團隊成員就可以根據當前系統的原則進行取舍。
如果一個項目的原則有很多,我們一定要進行優先級的排列,否則,原則作為指導方向的意義就削弱了。
有了可以度量的原則,其實仍然需要團隊成員的參與,才能將原則具體實施,所以,溝通和決策中的原則也應該是構架要考慮到的,雖然這離軟件構架稍遠了點兒。
項目中的溝通是頻繁溝通,還是適當溝通,還是避免溝通。溝通的成本,時間頻度、長度,形式,效果,都是需要考慮的問題
溝通的原則一般可以包括,關鍵活動和非關鍵活動的溝通。
設計溝通。
問題反饋溝通
決議原則
改進原則
策略。
- 對于總體原則的把握
- 應對變化策略
一次性的變化,如界面的文字的修改,布局設計的變更。這些屬于設計的進步,不需要反復修改,那么直接修改代碼即可。
?
比如說,有些變化是經常性的,那么
?
一次性的變化和經常性的的變化不是互斥的,在一定的條件和需求下,可能會相互滲透,如一次性變化變為經常性的變化,而經常性的變化轉回一次性變化,但是后者往往不需要再增加工作量。
經常性的變化,或者不確定性,是構架需要解決的問題,其策略要在構架時確定。如,使用變量值作為變化依據,配置文件中的項作為變化依據,數據庫中的配置表作為變化依據,還是使用外部服務作為變化依據。如元數據服務和工作流服務,都是更高級的適應變化的服務。
- 可伸縮性場景和策略
?
?
規范。
- 過程規范
- 代碼規范
- 界面規范
比如,在策略中我們確定通過配置方式進行變化的隔離
轉載于:https://www.cnblogs.com/haio/archive/2011/01/29/1947328.html
總結
以上是生活随笔為你收集整理的原则,策略,规范也是构架的一部分的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Android数据库存放的具体位置
- 下一篇: Contracts for Java