Author Topic: Flow chart for DB3 idea...  (Read 3928 times)

Offline Botsareus

  • Society makes it all backwards - there is a good reason for that
  • Bot God
  • *****
  • Posts: 4483
    • View Profile
Flow chart for DB3 idea...
« on: January 20, 2011, 03:32:06 PM »
My professor suggested we add a flow chart system to DB3 so it is easier to upgrade.

Numsgil cool?

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Re: Flow chart for DB3 idea...
« Reply #1 on: January 20, 2011, 04:12:26 PM »
If you mean something like a UML diagram of classes or something like that... ugh no.  That gets out of date so easily, especially in rapidly evolving software systems.  I've never seen any real world project use anything like that.

If you mean more like a diagram of the different modules and how they fit together, check out this diagram (note it's very out of date, and I was't super formal about it).

Offline Botsareus

  • Society makes it all backwards - there is a good reason for that
  • Bot God
  • *****
  • Posts: 4483
    • View Profile
Re: Flow chart for DB3 idea...
« Reply #2 on: January 22, 2011, 11:00:56 AM »
« Last Edit: January 22, 2011, 11:06:28 AM by Botsareus »

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Re: Flow chart for DB3 idea...
« Reply #3 on: January 24, 2011, 02:20:21 PM »
If you're specifying classes and methods in boxes and connecting classes together with lines to show inheritance, etc. you're almost certainly doing UML diagrams. See Wikipedia's entry.

This is one of those things that is changing over time, and CS departments tend to lag behind production environments.  Back in the day (and this is still the case for critical software systems like Mars rover code), code was documented and justified in excruciating detail with reams and reams of text and pictures and stuff like that.  However, over time, coders have come to realize that we need a more "plastic" environment to create software in, since our ideas of "good design" change as we start writing the code.

There's a good article on this I found recently: Hackers and Painters.

Here's a relevant quote:
Quote
For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.

For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.

My coding style has evolved over time, but this is more or less how I tackle problems nowadays:

1.  Figure out what you want to do in broad terms.
2.  Write some throwaway code to get a sense of how it might work.
3.  Write some very specific tests that pass/fail and especially test edge cases.
4.  Get the throwaway code to start passing tests.
5.  Get disgusted with the code, throw it out, and start over.
6.  (Optional) Repeat step 5.

It almost sounds sort of crazy, but lots of very good code comes from this approach.  To solve a problem well in code, you have to have solved it before, which means to write good code you have to write some horrible, terrible code and then scrap it and start over (often more than once).

...

All that said, if you're doing a CS degree you have to drink your professor's koolaid.  There's time to become disenchanted with the whole process later.

Offline Botsareus

  • Society makes it all backwards - there is a good reason for that
  • Bot God
  • *****
  • Posts: 4483
    • View Profile
Re: Flow chart for DB3 idea...
« Reply #4 on: January 25, 2011, 03:04:01 PM »
lol, I work the same way at home. At school is a different story  :banghead: