Printable View
currently i am working as a c developer on linux platform. I have reviewed code of opensource projects like runit and monit ( utilities used in linux ). They are nicely coded. I have a task to develop same kind of project. I just wanted to know how to make such initial design of particular c program. I have read book of software engineering but I want a practical design of such a code.
do anyone know any link to literature of whitepaper regarding this? any other idea?
Dilsetalk
Some "truths" about programming in the real world, which most academic texts on s/w engineering tend to gloss over.
1. There isn't an infinite amount of time to design and develop things.
2. The requirements will never be complete.
3. The requirements will always be self-contradictory.
4. The customer never really knows what they want. On the seldom occasions they do, they'll seldom be able to communicate that in a clear and unambiguous way (see 3.)
5. If you're doing any kind of embedded work, the hardware will a) be late, and b) be buggy.
Expanding on #5: c) and you'll be expected to compensate for it.
Do not forget that
6. Requrements will be changed just before the release date of the project requiring to redesign the most part of it
I'm sure your engineering book says that you start with a requirements document, then write a design document. Then you write the code according to the desing document.
But of course, in the real world, the requirements will not be 100% complete, accurate and unambiguous (as stated earlier). The design document will often make assumptions based on the author(s)'s understanding of the requirements. These assumptions may of course not match the customers actual requirements (and may not actually work in a real program - for example recently I had a problem where the requirement was that I'd call Function A in Library X from my Function H in Library Y. Function A in Lib X would call Function G in Lib Y - all Lib Y functions have a generic lock to prevent multiple threads entering the Lib Y functions - so the entire application would be waiting forever on a deadlocked situation because function G is waiting for Function H to finish, but Function H can't finish until after Function A has finished, and that doesn't happen until G has finished - so it will NEVER happen).
It is often a good idea to make a quick prototype for a project, before writing the final code. You will then find some of these quirky bits that won't work as you expect. You may or may not choose to show the prototype to the customer. You do NOT deliver the prototype to the customer, you rewrite the code based on the understanding you gained from making the prototype.
--
Mats
7. Real world data or conditions always breaks something.
8. Someone, somewhere has 'interpreted' the design differently or 'improvised'. You will not find this out until it is too late and something breaks.
9. Someone, somewhere has the specific piece of information or equipment you require but no one knows whom or where they are (or they are on R&R until....).
I just finished commissioning a project for a railway asset protection system in the outback. I was working up to 230Km down a dirt track in 30-40 C.
The servers did not get transported to site from the FAT (arrived 3 days later but without rails, which turned up another 3 days later).
The 'on track' equipment was stored, unlocked, at an abandoned camp (only lost a few minor items).
The sites did not match the design and required additional work and equipment.