Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re^5: The problem of documenting complex modules.(Summation.)

by BrowserUk (Patriarch)
on Jul 17, 2015 at 15:35 UTC ( [id://1135184]=note: print w/replies, xml ) Need Help??


in reply to Re^4: The problem of documenting complex modules.(Summation.)
in thread The problem of documenting complex modules.

This is why I personally like to do documentation, then coding, then unit testing. But my unit tests are written to the docs, not the code.

That is, or should be, a different set of docs. Design documents make lousy user documentation.

Conversely, I like to start with the (or at least a) application that will use the library I'm going to write.

I define the library interface in terms of the functions/methods that the application needs to fit its structure and use of the library. Those calls can then be mocked up to allow the application to be written and (functionally) tested. In a simplified form if necessary.

Once the api is defined and shown to satisfy the requirements of the application; it becomes much simpler to write a library to fit that api. (And *just* that api.)

The (simplified) application then also serves as both a test harness for the api; and as example code for user documentation.


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

Replies are listed 'Best First'.
Re^6: The problem of documenting complex modules.(Summation.)
by einhverfr (Friar) on Jul 20, 2015 at 08:30 UTC
    That is, or should be, a different set of docs. Design documents make lousy user documentation.

    I think it depends on the sort of module. Ideally, in my view, the user documentation should be at least a part of the design documentation. At very least it represents the contract as offered. If that is hard to document, you have design problems.

    That doesn't mean that's all of the documentation, but my experience is that clear user documentation is a general indication of clear design (exception made for Microsoft Xenix).

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1135184]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others contemplating the Monastery: (6)
As of 2024-03-28 10:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found