How do you design your code?
-
Personally, I like to start with an understanding of what the s/w is going to do. If I can't explain what it is going to do in english, I am not ready to start writing the code. Of course, writing a complete spec isn't possible, or even desireable, but a big picture understanding is key to avoiding rewrites. I also try to think about the different kinds of users my program will have. Some users need a single button that does what they mean, darn it. Others need a lot of knobs. Often, supporting both types is easy if you design the system that way up front. Next, I think about the parts of the system and decide what each part is going to do. I also try to decide how I can test the parts. It does no good to write code that can't be tested. Design for testability is an art, but can help prevent a lot of grief. Next, I decide what programmatic interfaces each part will provide. For each interface, I try to write a trivial example of how that interface is going to be used and make a judgement of how much data will flow through the interface. Different data volumes require different interfaces. For example, java ODBC is very slow compared to writing a special sql call designed to handle megabytes of data. But, if you are only fetching the data for a single web page, who cares. Also, some interfaces are going to be obviously error prone -- experience can be the guide here. So, I try to decide interfaces that won't be a stumbling block for myself later or for other developers. Next, I document this example program in the comments of the s/w I am writing so I can refer back to it later -- and I update the example when I see I guessed wrong as I write the code. Next, I implement the pieces and test as I go. I make sure that all my interfaces are tested. You can't always test every if statement in the code itself, but you can surely call all the functions at least once with realistic data. Test Driven Development makes a lot of sense, but I like to write a little code first, then test it. During this phase of development, I make use of valgrind on linux, or purify on unix and windows. I also use purecov to make sure that every line of code in my s/w is exercised at least once during my tests. In my opinion, these tools are essential to getting the code written properly. Lowell
The chief cause of problems is earlier solutions!
-
I’ve been trying out different methods for planning out projects and code. I've tried some things like mindmanager http://www.mindjet.com/us/[^] and freemind but still usually end up just typing a rough draft/outline in visual studio and fill in the blanks from there. So, I was wondering what everyone else uses for this sort of thing? Is there a built in productivity tool for doing your code architecture that I'm missing or a nice third party app that gives me a nice visual representation for colleagues but doesn't slow down my code writing process 'Thanks 'DrewG
I like Enterprise Architect http://www.sparxsystems.com.au/[^] It's much cheaper than most other similar programs, and I've been quite pleased with the past few versions.
-
My approach is different depending on the project. I often start with the user interface for several reasons: 1. The user interface gives me feedback earlier, reducing the chance I'll waste time on something that has to be rewritten. It also gives me ideas on cool features to have, from playing around with it. 2. It drives the following development, as it's clearer what needs to be done to implement the functionality. 3. It gives me a way of immediately testing the features I write. Next I often try to get a simplistic case working, even if most of the subroutines and classes are just stubs that return a constant or print a message. At this point, some of what needs to be done is clear (cohesive classes/subsystems), and some is unclear. I work on the clear parts because it reduces the chance I'll need to rewrite them, and implementing them gives me a better idea how the unclear parts need to be implemented. For some cohesive functionality, I'll create a separate toy project just to play around with it, without all the other baggage. Once it's working, I'll move the relevant classes into the main project. Design Patterns are useful in implementing subsystems, but, contrary to the name, aren't very useful in designing the software architecture. With the popularity of object-oriented development, many programmers seem to have forgotten the lessons learned from function-oriented development (e.g. Constantine and Yourdon's Structured Design methodology): Short, simple functions that push the complexity down to lower-level functions. Structured Design complements object-oriented design, and I use it to make my methods simple and understandable. This has many benefits: 1. The low complexity of simple, short methods reduces the chance of bugs. 2. It makes methods more reliable. 3. It makes maintenance easier (for me and others), since each method can be understood immediately (as opposed to staring for hours at a 200-line method, wondering what it does). 4. It makes documenting the method easier; the functionality can often be succinctly captured in one or two sentences. This further improves understanding by maintenance programmers, reducing maintenance costs. During development, I have a working system at all times. As soon as I get something working or fix a bug, I back up the whole system to a sequentially-numbered backup directory. Then I feel free to aggressively pursue the next development step, knowing I can easily back up to a working version.
Oh my lord - I've a long-lost twin!* *Except my backups are zipped images of my entire development directory structure. -- modified at 7:29 Wednesday 18th July, 2007
"Good Fortune is when Preparation meets opportunity"
-
You have to keep in mind when you ask such a question here that most of the replies will be from people that have never had to design a truly large application and so it's easy to just say "I just start writing" etc. I'm guessing you mean something large. I start with Paper and pencil usually. I start out by plotting out the tasks that the users will want to accomplish, I think about how to design the app so that those tasks can be accomplished as easily as possible in as few steps as possible then I write it out as the end result I want to achieve complete with rough sketches of screens and forms etc, then work backwards writing a list of business objects that will be required. I *always* think of the user interface very early in the design stage once I know for certain what tasks will need to be performed. I don't mean tasks as in "user clicks on blah blah" I mean tasks as in work related or real world related tasks, i.e. "User makes an invoice" etc. I tried a UML modelling program for our last big project, in the end it was a complete waste of time because we tried to use it for the actual early design phase and then ended up changing it constantly and it became a giant pain in the ass. I think the best way is to go through the paper and pencil stage plotting it out like a storyboard for a movie, come up with the business objects that are required, list it all out, then enter it into a simple list in a document or spreadsheet with the requirements and details about each object and code from there. The important bit, no matter how you do it, is to think from the users perspective of the tasks they want to accomplish and have the UI planned out in advance. It's the single most important part of any software that will be used by a lot of end users and it's vital that it flow properly and be simple to use and be task oriented in the way that the end user will think. Too many projects end up crappy and hard to use because a geek designed them thinking about the "data" first and not the actual real world tasks that need to be accomplished. When you think about tasks first you end up writing an app that works the way the user wants it to work, simply and intuitively and you easily find ways to combine things and simplify things before you ever write a line of code. I honestly don't think any software is useful for designing an application because they lock you out of the proper creative mindset that you need to come up with truly great things.
"I don't want more
How many lines of code (or actual users, or whatever is the measure) does it take for you to qualify something a "truly large application? Is this a good place for 'size doesn't matter'? That's never really true (not even in it's normal context). But, come once we've reached some reasonable threshhold in size, it's technique that dominates. I feel the need to object to the idea that the scenario really changes significantly. Ultimately, a program has a core (perhaps we'll call it main() ?). This entry point has options. Some of these options have options, &etc. If you've been programming a while, the majority of what you'll do is what you've done [Oh, my precious ego! It's fallen and it won't get up]. The fun part is those unique problem-solving scenarios: how often is that the whole shootin' match? (It is a reason why the world continues to need live programmers). By and large, a big application is pretty much a lot of little applications with a exceptionally good data/state connections. Perhaps I abstract this whole thing too much? I've been contimplating (as I type) some of the considerations I have to emphasize as the lines of code mount - but actually, it seems like the same rules still hold - the distinctions are minor. Particularly if you make it part of your modus operandi to reuse the same objects throughout the application. But, that's sort a standard consideration, so where's the real difference? The labor is a labor of love, spawned of creativity.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
-
Thanks, I try not to get too caught up in design unless I know that I probably won't be doing maintenace or all of the dev for that matter. Then I just try and make everyone else's job easier by forcing them all to start from my page ;)
Balboos wrote:
When you stop getting "I just thought of a better way" moments, you may consider seeking employment in a less challanging environment.
:laugh: I couldnt agree more
I threw in a few other answer to other comments, but I'll give you the following philosophy (of mine) for consideration: Don't think "outside the box." You shouldn't have a box.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
-
How many lines of code (or actual users, or whatever is the measure) does it take for you to qualify something a "truly large application? Is this a good place for 'size doesn't matter'? That's never really true (not even in it's normal context). But, come once we've reached some reasonable threshhold in size, it's technique that dominates. I feel the need to object to the idea that the scenario really changes significantly. Ultimately, a program has a core (perhaps we'll call it main() ?). This entry point has options. Some of these options have options, &etc. If you've been programming a while, the majority of what you'll do is what you've done [Oh, my precious ego! It's fallen and it won't get up]. The fun part is those unique problem-solving scenarios: how often is that the whole shootin' match? (It is a reason why the world continues to need live programmers). By and large, a big application is pretty much a lot of little applications with a exceptionally good data/state connections. Perhaps I abstract this whole thing too much? I've been contimplating (as I type) some of the considerations I have to emphasize as the lines of code mount - but actually, it seems like the same rules still hold - the distinctions are minor. Particularly if you make it part of your modus operandi to reuse the same objects throughout the application. But, that's sort a standard consideration, so where's the real difference? The labor is a labor of love, spawned of creativity.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
It's a subjective thing, but my projects tend to be commercial applications that we sell publicly or small in-house utilities or add-ons for that commercial software. Basically if it's small enough that I can hold the whole idea in my head without forgetting any details and can write it in a month or less then I'd consider it a small application. If it's large and complex and takes months to years to write then it's a large application. Anything that I know I'll be spending a significant amount of time on, I'm going to be much more thorough in my planning and design stages. Particularly anything that is destined for the public. Lines of code mean nothing. You can have a relatively simple application that contains thousands of lines of code. Our main application has hundreds of discrete business objects in it. Some are root (parent) objects, some are children of other objects or grandchildren, some are specialty list objects that are read only or editable collections etc. It's very complex logic wise but the code is all essentially the same in all the different types of objects. There are a *lot* of lines of code but I don't consider that at all in anything, more the complexity of the sheer number of objects and their interaction with each other.
"I don't want more choice. I just want better things!" - Edina Monsoon
-
I’ve been trying out different methods for planning out projects and code. I've tried some things like mindmanager http://www.mindjet.com/us/[^] and freemind but still usually end up just typing a rough draft/outline in visual studio and fill in the blanks from there. So, I was wondering what everyone else uses for this sort of thing? Is there a built in productivity tool for doing your code architecture that I'm missing or a nice third party app that gives me a nice visual representation for colleagues but doesn't slow down my code writing process 'Thanks 'DrewG
If you will visit http://www.cancercode.com/[^], it points back to mindjet. It is a great book, back in the startup days when it was possible to think up something like that while desperate to leave your wife a legacy while possibly dying of Leukemia. But German Socialized Medicine reportedly bent to allow him his computer in the ward, the rest is history. The book discusses somewhat the necessary deception of investors - they managed to conceal The Sole Architect's weakness during negotiations, since it remained sufficiently in remission.
pg--az
-
/off topic
pjd1001 wrote:
I wonder how many contemporary novel's you've read lately - operative word is contemporary, which I'll define as written in this century.
umm, not that this is relevant at all to the OP, but since you wonder;P.. i was published in a magazine(a cheap one circulated to participating schools across the country) for being in the top 40(in the participating schools nationwide) for accelerated reader points(ie. passing reading comprehension test for large novels and the likes) in the sixth grade... in the last week not so many... and not to be picky but novels is the plural of novel not novel's /end off topic I think that we are talking about, or at least have a different interpretation of, what a programmer is in contrast to a lead developer or architect. In my eyes, a programmer (or development team member) writes code that complies with business rules and business needs. The programmer does not go out to the business and ask what it needs, instead the business talks to an architect(or a developer well versed in platform advantages and design patterns). Then either through meetings with staff or by him or herself(if they wanna be cool like that and take all the credit for when things break:)), the architect/lead developer comes up with a design and brings this to his staff of programmers who write up the code and perform unit tests and things like this. That way people skilled at writing code do just that, write code, and people skilled at requirements/risk based application design, design applications. I would assume that people writing code for nasa projects such as voyager or other embedded systems have great skill at design patterns and application modeling(architecture) as well as a great need to have a well thought out design process that everyone is aware of. That way you dont have redundant functionality brought on by multiple programmers just "writing code" to get the task at hand done. A heart monitor especially would have this need, as it would have to be very very light on battery pull so software size would need to be minimal yet complete/
In the sixties when voyager was being developed they didn't have patterns etc. Of course things were designed and of course a great deal of time and effort was spend on ensuring the s/w was robust and adaptable - its worth recalling that when the camera arm on one of the craft failed, the camera pointing software was changed to move the spacecraft rather than the arm - whilst the system was millions of miles from home. But the design process was not the mechanical undertaking as some have described, instead it was a creative engineering process that took time, interaction and imagination. The claim was made by one contributor to this discussion that he/she could design a 1 year project in 1 day, at the end of which they'd have code stubs etc etc. What happens for the other 364 days I ask - programming, golf, beach bumming ??? Rgds PhilD IMO - The most valuable tools for s/w development are - gestation time, whiteboard(s), a comfortable bed and a good shower (i.e. one with lots of warm water, under which one can spend time).
-
I’ve been trying out different methods for planning out projects and code. I've tried some things like mindmanager http://www.mindjet.com/us/[^] and freemind but still usually end up just typing a rough draft/outline in visual studio and fill in the blanks from there. So, I was wondering what everyone else uses for this sort of thing? Is there a built in productivity tool for doing your code architecture that I'm missing or a nice third party app that gives me a nice visual representation for colleagues but doesn't slow down my code writing process 'Thanks 'DrewG
The subject naturally drew my attention. When I started programming in early 90s, I, literally, hardly thought or heard of Designing. The only way to me was to study practical project sources from big guys (especially, those who Born to Code in C) line by line, read printed-on-paper bundles, and wonder, Gee! How do they do it? C and it's closest predecessors were the only rival to each other in the jungle. Pascal was my fav that turned my nose to Delphi. Great. Still I was ignorant of Designing the code base. Then came newborn successors like Object Pascal, C++ followed by Java. The era of older design pattern got all upside down. Objects brought it all with them to Design code before you do the coding. Now In the age of .NET, we know or hear much about how they do design their code. My contemplation is: It all began well with Java (Pals, I am fan of C#.NET). If you study the Guideline from Java, and comply accordingly, you will come halfway with it. There are tools. I hardly use any. I visualize what I want to do. Take care of user friendlyness. I always remember a quote of Norton, "Firstly, I make sure it runs, then I make it efficient", may be efficient in all respect starting from user's point of view to developers points. The tier design approach helps me much. And the abbstraction philosophy I like the most. Though it all varies from projects to projects depending on types. For database, Requirement Analysis and Firsthanded database design helps me. In Systems Programming, I follow different approach. What so ever the type is, my own approach of "Test Run, Test Run, and Test Run", helps me better than anything else. My own design grid might come to some help to you. +-Steps--------------------------+-Presentation Layer-+-Logic Layer-+-Backend/Abstraction-+ | Requirement Analysis | | | | |--------------------------------|--------------------|-------------|---------------------| | System Design & Pseudocoding | | | | |--------------------------------|--------------------|-------------|---------------------| | Coding and Development | | | | |--------------------------------|--------------------|-------------|---------------------| | Test | | | | |--------------------------------|--------------------|-------------|-------------------
-
Once again, experience proves correct, Looks like Ive got more reading to do. Thank you very much for the great post! Are there any references/communites that you would recommend?
As far as I know there is not place following those methodologies. Companies like Microsoft came up with its “Microsoft Solution Framework” which is mainly focusing in schedule and milestones more than doing analysis and design. Essentially the different between bottom-up and top-down is the sides of the system to develop where top-bottom is for small-medium systems while bottom-up for medium-big systems. The best is the combination of both where you start using bottom-up to perfectly understand the real problem and then apply the top-bottom to understand the management. Bottom-up starts with interviews and top-bottom starts with management processes. The best school for this is practice, practice and more practice. Do not write any line of code until the problem is totally understood, at that time you will have everything documented and the knowledge of the flow of the information. Everything will be in pseudo-code and diagrams, as well as modularized (now UML). Also you will know what can be encapsulate, what to share, what structure accepts or returns or share, what kind of interface to use, possible number of modules, functions, procedures; what can go to a services, to the web or simple apps; the db model that suit your final approach; also will have future expectations and by consequence the knowledge of your needs; as well as to know the language or languages to use if the system is versatile.