- For there to be (documented) knowledge of everything the software does (and doesn't/shouldn't) do.
- For there to be a simple way of verifying the software behaves as intended.
- For it to be written in a way that makes it clear to a person looking at the code what it does, so it avoids any unintentional side effects when changed.
Point 1 doesn't require a specific format or way of recording this information. Use what works best for you, the team, the company, and the project.
Point 2 can involve a combination of tools and may require some manual effort.
Point 3 is dependent upon the skills and existing knowledge of the person making a change. It's okay to require a minimum level of knowledge of the language, framework, codebase, etc. The goal, as far as possible and in combination with other requirements, is to have unambiguous code that is clear about what it does. (With documentation--and possibly comments--explaining why, where necessary.)
0 comments:
Post a Comment
I get a lot of comment spam :( - moderation may take a while.