In 1992, Jack Reeves wrote a seminal article in the C++ Journal entitled “What is Software Design?” In this article, Reeves argues that the design of a software system is documented primarily by its source code. 源碼就是設(shè)計。UML diagrams 也許能夠展示一部分設(shè)計，但它不是設(shè)計的全部。只有源碼才是設(shè)計。非常推薦這篇文章！！！

?

Design Smells – The Odors of Rotting Software

• ? Rigidity – The system is hard to change because every change forces many other changes to other parts of the system. 僵化=難于修改
• ? Fragility – Changes cause the system to break in places that have no conceptual relationship to the part that was changed. 脆弱=一改就亂
• ? Immobility – It’s hard to disentangle the system into components that can be reused in other system. 難以提取獨立出來
• ? Viscosity – Doing things right is harder than doing things wrong. 粘滯=做好事難。比如編譯時間太長，開發(fā)人員就會傾向于修改只需要部分編譯的代碼，即使這樣修改與設(shè)計沖突。
• ? Needless Complexity – The design contains infrastructure that adds no direct benefit. 沒必要的復(fù)雜=過度設(shè)計。我們應(yīng)該保持設(shè)計的flexible，而不是一開始就認為后續(xù)會有很多變化，從而把架構(gòu)寫的很復(fù)雜。如何保持？看后面介紹的原則，以及測試驅(qū)動會驅(qū)動你的。
• ? Needless Repetition – The design contains repeating structures that could be unified under a single abstraction. 重復(fù)=濫用粘貼
• ? Opacity-It’s hard to read and understand. it does not express its intent well.晦澀=代碼難懂

?

What Stimulates the Software to Rot?

主要原因來至需求變化，而且經(jīng)常要求快速實現(xiàn)需求，導(dǎo)致開發(fā)人員寫出各種違反原設(shè)計的代碼，慢慢的Smell就產(chǎn)生了。

然而，我們不能責(zé)怪需求的變化。If our designs are failing due the constant rain of changing requirements, it is our designs and practices that are at fault. We must somehow find a way to make our designs resilient to such changes and employ practices that protect them from rotting.

轉(zhuǎn)載于:https://www.cnblogs.com/ustbdavid/p/3415226.html

總結(jié)

以上是生活随笔為你收集整理的敏捷开发原则与实践（二）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。