What is the best way to keep your projects organized from start to finish?

2    11 Feb 2019 15:49 by u/Marsog

Basically, how do you guys keep your programming projects organized and not turning into such shit you quit on them because coding them is more of a hassle than enjoyable?

19 comments

1 u/Donaldo_Trumpo 12 Feb 2019 10:16

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.

0 u/ElijahBrown 11 Feb 2019 15:52

That depends a lot on the scale of your operation.

If you're a sole worker managing your own projects, it's just a matter of personal initiative.

If you're managing a team, it's a matter of creating a system of record keeping on the progress of various projects.

0 u/i_scream_trucks 11 Feb 2019 16:05

dont let a woman anywhere near it.

0 u/AnthraxAlex 11 Feb 2019 16:11

Avoid functional scripting languages for complex applications.

0 u/Marsog [OP] 11 Feb 2019 17:52

Does python count as a functional scripting language?

0 u/AnthraxAlex 11 Feb 2019 17:55

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.

0 u/Marsog [OP] 11 Feb 2019 18:06

Thanks for the answer. Do you know of an easy way to combine python and another language like C# or C++? Python and C are the only languages I barely know.

0 u/justlogin 11 Feb 2019 18:44

Honestly, most scripts I write for specific purposes just pipe one unix command to another. You can often process HTML/XML with grep/awk/sed and maybe xmllint/json_pp if the required filter is simple and local enough and hack something together. That is entirely improper but will do often enough. :/

0 u/AnthraxAlex 12 Feb 2019 16:17

I do the same thing for a lot of work but most of the time the scripts are system level glue tying together lots of already written functionality. I don't necessarily think of that stuff as an app though. To me an application is more monolithic than that and narrower in scope.

0 u/justlogin 12 Feb 2019 18:54 
#!/bin/sh
# extract webpage title from a downloaded webpage (via wget)
# intended for youtube pages, a title is always present
# takes first title to ignore titles of related videos
# !!! obsolete !!! use youtube-dl
grep -io '<title[^<]*</[^<>]*>' "$1" | sed -e 's/^[^>]*>//; s/<.*$//' | head -1 | tr -d '\n\r'
0 u/AnthraxAlex 11 Feb 2019 18:50

You can call python or c++ from c# using com interop bindings if you have some external library you want to consume from your c# app. I'd recommend learning c# over c++ because it's going to be more widely used except in niche use cases.

0 u/cantaloupe6 12 Feb 2019 00:50

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

0 u/justlogin 11 Feb 2019 17:56

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 if you don't get the reference. Or maybe you mean Project Management aspects? The absolute best way is to only ever work on things similar to what you have already done!

0 u/Marsog [OP] 11 Feb 2019 18:08

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.

0 u/UndeadTed 11 Feb 2019 22:54

  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.

0 u/cantaloupe6 12 Feb 2019 00:59

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.

0 u/Marsog [OP] 12 Feb 2019 02:54

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.

0 u/cantaloupe6 12 Feb 2019 03:19

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 ones 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.

0 u/oligarchsalamander 06 Mar 2019 18:40

I adjust the structure continuously throughout development. I keep it as simple as possible and extract functionality out as it gets large enough, or becomes clear enough that it's a separate piece of functionality. Or a piece of functionality that could become more detailed and specific if it were moved to its own area.

I try not to over plan the structure at the start because it's always wrong. You need an src directory, some primary files go there, generally that's all I have with a util directory inside the src directory maybe. As I end up with too many files there I reorganise it into more directories within the src directory, each one of them perhaps having their own util directories.

Or maybe I don't use util directories, I dunno. I find structure to be nearly as enjoyable as solving problems.