Tea time question : A quest to mastering methods in design phase of an application
Its almost that time to take a few minutes break and look at mastering methods. I learnt something from my variable thread the other day, which was to phrase my question correctly. So to start with, am asking you the coder//programmer to imagine that you were put into a situation as a software developer consultant/software design architect. Let us first establish that we all know about methods/functions. What we also know about these are thing like various ways that they get used. The question then goes as follows : You have a project, you know its requirements, know its basic flow and have established all the variables to be used. Now it is time to get these onto paper and work out the actual code flow without even touching any keys. You have a blank paper in front of you, you need to start the process....! The process that you put on eg paper will be used in development process. Programmers on the list : Define the easiest way to derive methods. Hope I've listed the question correctly this time around. :-) Rgds.
I personally create functions/methods based on "uses" For example, suppose i have a registration form, i will probably have methods like: printUserRegistrationForm() and consequently processUserRegistrationForm() But I normally find that i derive the variables AFTER coming up with the methods, and not before. And i've never been able to predefine all variables before I finish the project, but then again, I often use a laissez faire approach to software design :-) Have you explored using pseudo code and flowcharts? If done properly, these are just like coding on paper. On Tue, Mar 30, 2010 at 10:32 AM, aki <aki275@googlemail.com> wrote:
Its almost that time to take a few minutes break and look at mastering methods. I learnt something from my variable thread the other day, which was to phrase my question correctly. So to start with, am asking you the coder//programmer to imagine that you were put into a situation as a software developer consultant/software design architect.
Let us first establish that we all know about methods/functions. What we also know about these are thing like various ways that they get used. The question then goes as follows : You have a project, you know its requirements, know its basic flow and have established all the variables to be used. Now it is time to get these onto paper and work out the actual code flow without even touching any keys. You have a blank paper in front of you, you need to start the process....! The process that you put on eg paper will be used in development process.
Programmers on the list : Define the easiest way to derive methods.
Hope I've listed the question correctly this time around. :-)
Rgds. _______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Server donations spreadsheet
http://spreadsheets.google.com/ccc?key=0AopdHkqSqKL-dHlQVTMxU1VBdU1BSWJxdy1f... ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
Hey Peter, thanks for breaking the ice on this thread. :-) Actually I thought that the thread would be a very interesting e-conversation between programmers on the list and would generate interest for others to join the programming club thus I listed it. My plate is full with other things like learning vectors etc but am sharing some insights as I go along. Methods are the code building blocks and therefore determine the code flow in one's app/program. Flow charts may not be of help because they are provide an overview to certain levels eg decision making blocks of if/else. Rgds. On Tue, Mar 30, 2010 at 8:28 PM, Peter Karunyu <pkarunyu@gmail.com> wrote:
I personally create functions/methods based on "uses"
For example, suppose i have a registration form, i will probably have methods like: printUserRegistrationForm() and consequently processUserRegistrationForm()
But I normally find that i derive the variables AFTER coming up with the methods, and not before. And i've never been able to predefine all variables before I finish the project, but then again, I often use a laissez faire approach to software design :-)
Have you explored using pseudo code and flowcharts? If done properly, these are just like coding on paper.
I find that its much much harder getting the requirements / analysis phase right, and that far to many people start coding/designing waaaaay before they (or the client) understand the problem - but that is a different discussion. The design-phase tools/method will highly depend on the kind of solution/problem that I am facing, but here are some of the approaches I use: 1. E-R diagrams I just love E-R diagrams, whenever there is a database involved in the project, then I almost always use an E-R diagram as my starting point. Whiteboard, paper, electronic - the form is less important for me, since I tend not to go into complete details of the data model. Although I have started using Mysql Workbench ( http://wb.mysql.com/ ) and can highly recommend it. 2. Class diagrams If the project is more complex in nature (and if its going to build OO style) then I often use class diagrams. I use it to model special interesting/challenging fragments of the system, and never the "entire" system, since I find that to be a waste of time (most of it will be trivial anyway). Only the central methods of each class goes into the diagram. 3. Tracer-bullets & (mental) Sequence diagrams Finally it can sometimes be very hard to imagine how the "flow" of the system will work. When facing those situations I often start thinking in sequence diagrams, however I rarely put them on paper (I really should do it more often, to improve my documentation). Given a certain usecase, I try to (mentally) visualize the complete flow of method calls though the (coming) program - instead of paper I sometimes turn to code and using tracer bullets ( http://www.artima.com/intv/tracer.html ) and try to build a simple skeleton of how the call-sequence is going to be - never implementing functionality only the cross-method call-sequence. And then back to the "drawing board". I really want to mention wireframes aswell (always use those) but depending on perspective you might say that I use those prior to the "technical" design-phase, and hence are not relevant for this discussion. regards. webMike aki wrote:
Its almost that time to take a few minutes break and look at mastering methods. I learnt something from my variable thread the other day, which was to phrase my question correctly. So to start with, am asking you the coder//programmer to imagine that you were put into a situation as a software developer consultant/software design architect.
Let us first establish that we all know about methods/functions. What we also know about these are thing like various ways that they get used. The question then goes as follows : You have a project, you know its requirements, know its basic flow and have established all the variables to be used. Now it is time to get these onto paper and work out the actual code flow without even touching any keys. You have a blank paper in front of you, you need to start the process....! The process that you put on eg paper will be used in development process.
Programmers on the list : Define the easiest way to derive methods.
Hope I've listed the question correctly this time around. :-)
Rgds. _______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Server donations spreadsheet http://spreadsheets.google.com/ccc?key=0AopdHkqSqKL-dHlQVTMxU1VBdU1BSWJxdy1f... ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
participants (3)
-
aki -
Michael Pedersen -
Peter Karunyu