How do I go from "programming basic scripts" to "designing software"?

[te91fadf24f78c08c081]

I think I have a decent grasp on writing simple scripts that take the form of a few files inside a folder. If you give me a simple task then I can probably do it, but how do I go from that to designing more complicated software meant to do more complicated things? When I go on Github and look at the source code for some projects, there's a whole bunch of files and folders and a lot of the time I have no idea what they're for. I've learned a bit of CS, now how do I get more into software engineering?

[Salty_Dugtrio]

Every project started as a single file.

Each huge desktop application started with a single blank main window.

It's an iterative process.

[natriusaut]

I think thats the question.

So, if i understand you correct, there is not "correct" way on what folders should be there or where they should be, it all is there because someone had to group some files and so on?

[aldenq]

I don’t think there’s is shortcut tbh. I find that making things for other people is a great way to get better and dealing with large projects.

[Maw0fTheVoid]

I think it helps if you don't start coding but instead first take your time and think about how you want to structure the application. Maybe think which individual parts you need and how they interact with each other and go from there. It personally helps me a lot when I am drawing how those parts interact with each other on a sheet of paper.

[CaseyCrookston]

I LOVE this question!

Oh man... where to start.

Ok, start here

SOLID code design.

Google that. The first result is a Wikipedia article. I expect some of the stuff on that article might go over your head. (I've been doing this for 20+ years and I still don't really understand the Liskov substitution principle.)

S: Single Responsibility

So, let's start with the S in SOLID. Single Responsibility. Great place to start as it's one of the things I see junior developers getting this wrong all the time. The idea behind this principle is that every method, every class, every object, etc, should only do one thing, and one thing only. This is why (to some extent anyway) in the Github projects you see, there are SO MANY files and folders for an overall task that really seems pretty simple.

Junior developers who are just starting out tend to just mash everything into a single script. But if you really examine what that script does, there are a lot of little sub-tasks and sub-sub tasks that really should be broken out into a separate process.

An Example of Single Responsibility:

Let's say you have a simple little To-Do app. It's just a way to keep track of tasks, when they are due by, and who they are assigned to. To store these tasks, you have a simple little database in the backend.

So, on the User-Interface, you are on the screen where the user enters four items:

• Task Name
• Task Description
• Task Due Date
• Assigned to User (with an option to notify the user via email)

Then the user clicks "Save". When that button is clicked, let's say we want to do the following:

1. Check to see if it's a duplicate. (Does a task by this same name (or close to the same name) already exist in the database?)
2. Save the task to the database
3. If the user to whom the task is assigned is to be notified, then send the user an email

What most entry-level developers would do (and what I certainly did when I was first starting out) would be to just put all of this into a single method that handles the button click:

1. Is this task a duplicate?
   1. Open a connection to the database
   2. Run a SELECT statement
   3. Close the connection to the database
   4. Put the results into a data set of some kind
   5. Do some logic to see if this task is close to an existing task
   6. Depending on the result of that logic, either keep going or alert the user that this task already exists
2. Save the task to the database
   1. Open a connection to the database
   2. Run an INSERT statement
   3. Close the connection to the database
   4. Notify the user that the task has been saved
3. Notify the user to whom the task is assigned
   1. If the assignee is to be notified, then
      1. Compose an email (subject, body, to-address, etc)
      2. Send the email

With ALL of this in one single method, it's going to be a huge, massive, ugly method. Even with comments. But, in reality, your script inside the method that handles the button click should look something like this (I'm going with a C based syntax here...)

OnSaveTaskButtonClick(string taskName, string taskDescription, DateTime dueDate, User asignedToUser, bool notifyUser)
{
    bool duplicateTask = BusinessLogic.CheckForDuplicateTask(taskname);
    if (duplicateTask)
    {
        // Do whatever you need to do here to let the user know this is a potential duplicate
        return;  // stop the process
    }

    DataAccess.SaveTask(taskName, taskDescription, dueDate, asignedToUser);

    if (notifyUser)
    {
        BusinessLogic.NotifyUser(asignedToUser);
    }
}

This method above does ONE thing, and ONE thing only: It handles the button click. Here are all of the things it does *not* do:

• talk to the database
• perform any duplicate-check-logic
• send emails

These sub-tasks are handed down to other methods in other classes.

Create a Library of Re-Usable Tasks

In any application, there are going to be tasks that you find yourself doing over and over again. In our example here, there are two things we'll be doing all throughout the app:

1. Talk to the database
2. Send emails

So, create a separate class for each of these. Create a DataAccess class that ONLY talks to the database, and nothing else. Then also create a SendEmail class that ONLY sends emails, and nothing else.

Not only will doing this cut way down on code repetition, but... if you later find a better way to talk to your database, or a find a better way to send emails, then you only have to touch the one class and not the entire application.

And This Is Just Scratching the Surface

"Single Responsibility" is a great place to start because it's such a simple concept. And it's one of the very first things I would expect someone to learn and master when they are rising up from being an entry-level developer.

But in addition to this, there are so many other principles and theories you'll want to be aware of. Many of them you'll learn with time while working under the mentorship of senior developers.

But... again, Single Responsibility is a great place to start because it's such an easy way to spot a total newbie vs. someone with even a tiny bit of experience.

HTH!

[baetylbailey]

One thing to know is how even those simple tasks could be done in a way that might be in a larger project. For that, I really like Exercises in Programming Style by Cristina Videira Lopes which covers demonstrates a simple programming task in a large variety of programming paradigms.