Mathias Bauer <[EMAIL PROTECTED]> writes: > Not exclusively. Also developers will benefit from a spec if they have > to refactor/change/extend the code later on. Believe me, I can't count > the occasions any more where I would have been glad to have a > specification for a feature that needed a larger rework. Without a spec > we very often are standing in the dark and hope to be lucky not to > damage too much things just because we just don't know about their > existence. > Hi Mathias,
yes, you might catch a few bugs using this approach. But I think one of the key messages of agile software engineering is that in the end, the code determines behaviour, not documentation. Put differently, code and documentation will quickly diverge, simply because there can't be technical, automated means to check that they are in sync. The only proven way to prevent something to break in the future is to explicitely test against it in an automated unit/integration/UI test. _Before_ a CWS gets integrated. Fixing the root cause of your problem is not providing more documentation, but providing more automated testing. Hey, and yes, having a feature documented is _also_ nice - just as well-commented code and interfaces. It makes working with the code much easier - but still, even inline autodoc comments are not up-to-date in all cases... Cheers, -- Thorsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
