mirror of
https://github.com/amyjko/cooperative-software-development
synced 2024-12-26 21:58:27 +01:00
Correct author's name (Fucci et al., 2016)
This commit is contained in:
parent
2f3c20dc8c
commit
8388315f56
1 changed files with 1 additions and 1 deletions
|
@ -90,7 +90,7 @@ function min(a, b) {
|
||||||
|
|
||||||
<p>When the consequences aren't so high, other factors dominate: writing functional specifications is very hard and very time consuming, you need tools to verify the annotations themselves, and you have to maintain annotations. These barriers deter many developers from writing them (<a href="#schiller">Schiller et al. 2014</a>). Some forms of specifications, like the UML diagrams we described when discussing architecture, lack the benefits of formal specifications <em>and</em> require a lot of work to create, leading many practitioners to find them not worth the effort (<a href="#petre">Petre 2013</a>).</p>
|
<p>When the consequences aren't so high, other factors dominate: writing functional specifications is very hard and very time consuming, you need tools to verify the annotations themselves, and you have to maintain annotations. These barriers deter many developers from writing them (<a href="#schiller">Schiller et al. 2014</a>). Some forms of specifications, like the UML diagrams we described when discussing architecture, lack the benefits of formal specifications <em>and</em> require a lot of work to create, leading many practitioners to find them not worth the effort (<a href="#petre">Petre 2013</a>).</p>
|
||||||
|
|
||||||
<p>Specifications can have other benefits. The very act of writing down what you expect a function to do in the form of test cases can slow developers down, causing to reflect more carefully and systematically about exactly what they expect a function to do (<a href="#fucci">Fuci et al. 2016</a>). Perhaps if this is true in general, there's value in simply stepping back before you write a function, mapping out pre-conditions and post-conditions in the form of simple natural language comments, and <em>then</em> writing the function to match your intentions.</p>
|
<p>Specifications can have other benefits. The very act of writing down what you expect a function to do in the form of test cases can slow developers down, causing to reflect more carefully and systematically about exactly what they expect a function to do (<a href="#fucci">Fucci et al. 2016</a>). Perhaps if this is true in general, there's value in simply stepping back before you write a function, mapping out pre-conditions and post-conditions in the form of simple natural language comments, and <em>then</em> writing the function to match your intentions.</p>
|
||||||
|
|
||||||
<center class="lead"><a href="process.html">Next chapter: Process</a></center>
|
<center class="lead"><a href="process.html">Next chapter: Process</a></center>
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue