Miroirs/cooperative-software-development
1
0
Fork 0
mirror of https://github.com/amyjko/cooperative-software-development synced 2024-12-25 21:58:15 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Correct author's name (Fucci et al., 2016)

Browse source
This commit is contained in:
Davide Fucci 2018-02-23 23:26:48 +01:00 committed by GitHub
parent 2f3c20dc8c
commit 8388315f56
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
specifications.html
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>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>