[–] UndeadTed 0 points 4 points (+4|-0) ago 

  1. Spend time architecting your software first. No need to go overboard, but you need to know what major system parts you will have and what components each of those will have. Major system parts should have their own sub-project.

  2. Break things up by feature or component so that everything that is needed for it is in one place. In the future when you want to modify a feature or component, all its stuff will be in one area. (Compare this to project that break things up by say file type, which is a nearly useless way to break up a project) This is also great if you're breaking up parts of the project for multiple team members, where each can work on one discrete unit.

  3. You will re-organize your project at some point, just accept that. As you get further into a project, you'll have a better idea of the overall design and behavior, and therefore will want to move things around to fit that. For this to happen once or twice isn't abnormal, but if you're doing it continually it points to bad design / architecture.

  4. Everything goes into source control together in one place. This includes documentation, SQL scripts, upgrade scripts, etc. Don't make a future coder or yourself try to remember where various things were put on different systems or services.

[–] i_scream_trucks 1 points 3 points (+4|-1) ago 

dont let a woman anywhere near it.

[–] Donaldo_Trumpo 0 points 1 points (+1|-0) ago 

If you're not using a framework, you might test out a few. Good frameworks are designed to be organized in a way that is easily expandable while remaining compartmentalized. There are microframeworks as well, if you're working on a smaller project.

Also, if your code is AIDS, go back and refactor it rather than trying to throw it out and start over. Code always shifts towards AIDS when it is first written.

[–] justlogin 0 points 1 points (+1|-0) ago  (edited ago)

I'm sorry to say that I'm not very skilled at this either...

Here is an interesting article, "Katamari Darcy" refers to a silly video game [add video] if you don't get the reference. Or maybe you mean Project Management [basic intro to SCRUM, trigger warning: nigger] aspects? The absolute best way is to only ever work on things similar to what you have already done!

[–] Marsog [S] 0 points 0 points (+0|-0) ago  (edited ago)

I meant for personal projects that are medium/large sized. I usually start these projects after multiple smaller "Test" projects only to quit halfway through because of bandaid over bandaid over bandaid. Thanks for the article.

[–] AnthraxAlex 0 points 1 points (+1|-0) ago  (edited ago)

Avoid functional scripting languages for complex applications. People try to use the functional style to write an application with half a million lines of code and then wonder why it's a chaotic mess of monkey patches and there is no organization or structure.

[–] cantaloupe6 0 points 1 points (+1|-0) ago 

Absolutely - above a half million it'd be horrible.

[–] Marsog [S] 0 points 1 points (+1|-0) ago 

Does python count as a functional scripting language?

[–] AnthraxAlex 1 points 1 points (+2|-1) ago 

Yes. I love python but there's just certain levels of complexity where it's better to use another tool. All of the massive projects using it end up rewriting in something else once they hit a certain complexity.

[–] cantaloupe6 0 points 0 points (+0|-0) ago 

Personal projects or giant teams? 1k lines or #M? Small projects use git have an architecture, add a task list and purpose in comments as documentation.

[–] Marsog [S] 0 points 0 points (+0|-0) ago 

personal project, probably more than 1k but less than million. Will include many sub-systems and features that I will have to build all from scratch.

[–] cantaloupe6 0 points 1 points (+1|-0) ago  (edited ago)

For about 500k lines you can use a spreadsheet. Identify features and sub-tasks. Prioritize those. Identify what a minimal viable system would be, what should it do? Identify what technology you believe should be used - have at least three vendors. Try to adopt an existing well known architecture, can the system be split up as services? Create unit test so you know if changes break you system. Create a data-model so you have an idea of what's needed. After building a minimal viable implementation what updates to parts provides the most economic utility? Is there some part you can outsource? Is there tech you can adopt? They'll be making on going improvements.

Make some S.M.A.R.T. goals. Use a distributed source control system for exploratory work. Keep the sections of the system small enough to be held in one's head.

Create documentation that explains what the functionality should do and use a standardize format do you or anyone could come back later and have an explaination - include sequencing diagrams.

If you use REST services parts of the system can be mocked with scripting for a fast turn around.

The code should be very readable so that anyone could look an understand. For a small team comments explaining confusing points or todos can be helpful.

It may be necessary to look at the data rate - depending on the functionality.