Merge pull request #24 from dfucci/master

Correct author's name (Fucci et al., 2016)
This commit is contained in:
Andrew J. Ko 2018-02-24 14:18:48 -08:00 committed by GitHub
commit a3535a6464
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -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>