How do you begin your projects?

[TJMAudio]

So lately I have been trying to get into more OOP design and out of sloppy, repetitive coding.  One thing that ends up making my projects a mess is that I get cluttered extremely quickly.  I end up using require_once way too much, which results in me limiting myself to how open both my design and functionality is.

 

How do you go about starting your projects off (do you write out your plans, draw a rough layout, etc.)?

Do you use a database to hold your headers, meta tags, etc. and then pull them in a function?

 

Any other tips on how to get OOP design without getting myself cluttered and in too deep would be appreciated!

[donbueck]

Great question! I think everyone probably does it differently though. One of the best methods that I have adopted (for the bigger projects) is to start by writing technical documents. Describe the features, how they interact, behavior, etc. That way you avoid a lot of problems down the road. Once you have the outline, things tend to fall into place pretty much of their own accord.

[Acs]

It depends if you are on a team or doing the project alone!

 

Since I do most of my stuff alone, I try to visualize mentally how the application win run and then write some diagrams of how it might work. Not really complex ones, just simple stuff, and then I comment the code and sometimes leave comments saying that "this" will be used with "that" etc

[TJMAudio]

It depends if you are on a team or doing the project alone!

 

Since I do most of my stuff alone, I try to visualize mentally how the application win run and then write some diagrams of how it might work. Not really complex ones, just simple stuff, and then I comment the code and sometimes leave comments saying that "this" will be used with "that" etc

That is one of the main reasons I created this thread.  All of my projects thus far have been solo, however when I look back at my biggest (and most technical), current project I often tell myself: "Man, if I decide to pick up another programmer on this, he is going to be digging through includes for 2 hours trying to figure out just what is going on in this mess!".  I want to get away from that completely. 

 

I guess the biggest thing I could do is stop getting so excited over a new idea, sit back, collect the information I have, plan it out, and then start coding it.  I rush into things, and write a whole new function because I realized I needed something in the last function, but completely forgot, and end up putting that new function in another file, because the first function gets called too early.. and it just became a mess.

 

Thanks for the tips so far guys.

[Daniel0]

[A team project] is one of the main reasons I created this thread.  All of my projects thus far have been solo, however when I look back at my biggest (and most technical), current project I often tell myself: "Man, if I decide to pick up another programmer on this, he is going to be digging through includes for 2 hours trying to figure out just what is going on in this mess!".  I want to get away from that completely. 

 

If you're concerned about that then I would suggest you to use an industry standard framework. In that case your potential future developer will have extensive documentation and he is ensured that you, to some extent, follow specific coding guidelines and patterns. I would recommend Zend Framework, but other popular ones are symfony, CodeIgniter and CakePHP.

[Zane]

I have the same problem. My ADD only seems to come out the most when I actually use my brain.

 

The main thing that gets me running in circles is that I'll get an idea that there is an even better more efficient way to do what I'm doing and I'm already so clairvoyant about it that I"m 100% positive that it'lll work, only problem is that is that is steals me precious time from the actual objective.

 

So what do I do? Recently in my little projects, I've been trying my best to just bite the bullet and do it the "easy" way. Get the main idea to actually work in a laissez-faire type of way and then come back afterwards and polish it up; because debugging your own work is usually ...always easy

 

If you're a true programmer and not a person that posts every inch of error code into a forum expecting its output to be gold.

 

For me, planning on paper never does much. I always end up writing things I already know and drawing pointless diagrams of where my data's being sent to and why.

Because all in all my notes get left on the table half the time where they loose their lives to a spilt drink or something, or someone else's ignorance.

 

 

I would definitely quit splitting all your stuff up into a bunch of random function files

[keeB]

I guess I'll be the first to say it..

 

UML Diagrams [1] and CRC32 [2] cards.

 

Since I work in a professional environment with all of the code that I write, the flow is something like this

 

1) My boss or I think of a missing tool that would be useful for testing our product.

2) Research best tools available to accomplish the job

3) If there aren't tools which accomplish what we need, I

  3a) Write a high level proposal with cost analysis and project time line with deliverables at certain milestones. At this point I've thought on a high level how this would be accomplished but haven't gone in to any great level of detail. This is

  3b) If proposal is accepted (which it usually is because I'm pretty damn good.. )

      3aa) Come up with design. UML and CRC32 cards are useful for figuring out issues right away.

      3ab) Have a co-worker proof read design

      3ac) Publish design proposal

      3ad) If accepted, finally write the damn code!

 

For anything non trivial, there's a lot of thought and pre-planning to do before you actually write code. The reason being, when you actually sit down to write it, you should have a very clear direction and goal.

     

 

[keeB]

Ooops, can't edit...

 

[1]: http://en.wikipedia.org/wiki/Unified_Modeling_Language

[2]: http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card

[BloodyMind]

thanx alot KeeB

I've been stuck of thinking of procedural programming

like bottom up planning and it was hard

but finally my latest method of planning

is to write the abstract functions of the system to subsystems

then break them down to classes

but this way seems better thanx again for the info

[dbo]

1) I basically like to put together a "wish list" of all the features I'd like the said system to have.

2) Think about the complexity/value-added of the said feature set to determine what is most important.

3) Rough out a sitemap of the pages needed (UML, class diagrams and things might be needed)

4) Hand draw what these pages should look/function like.

5) Build out exact image mockups of what the pages should look like.

6) Implement framework and/or any necessary base classes.

7) Build out my page templates.

Build out my views so that I can do a click through.

9) Implement my database (if necessary).

10) Write the business logic (controllers).

11) Testing (I won't go into details on this one... depends on the type of project)

12) Production rollout (knowledge transfer if applicable)

13) Maintain

 

This is sort of the more detailed approach. If I'm doing something for a client it's more like:

 

1) Statement of Work

2) Requirements Definition

3) Requirements Signoff

4) Sitemap

5) Sitemap Signoff

6) Design (Mockups)

7) Design Signoff

Build

9) Final Review/Signoff

10) Launch

[ming_andrada]

i've been readin this thread for 2hrs...

 

it really helped me...

 

 

certified newbie webdev <===