Codebase restructuring - Clean architecture (uncle bob)

[arvryna]

I have been hearing about this for a long time, many devs follow this approach and in many job description i see this as an important keyword. What do you think about it ?

[arvryna]

And recently i had this codebase reviewed by a golang enginner with few years of experience, and got some strong comments ))

I received a review of the code, 1. The code in the example is illogical, incoherent.

Main function:
func Start() {
flags, err := data.ParseCLIFlags()
if err != nil {
fmt.Println("Error parsing flags: ", err)
return
}
if flags.Version {
fmt.Println("Blazer version: ", data.Version)
return
}
setup(flags)
}

It ends with setup (), which actually starts something there.

2. The structure of the application is extremely non-standard, contradicts the recommendations.

3. The names of packages and functions are not idiomatic (the "data" package, for example).

4.The exported functions have no comments. Although I am present here are:

// Constants. < - Interesting comment.
const Version = "0.3-beta"

5.There are no tests. In general!

6. I did not understand what this program does.

we need to find a way to re-structure our project )

[setraj]

we can start small. function by function and file by file we can do.
The objective should be to make our code testable.

[arvryna]

Alright

[setraj]

Clean architecture code (uncle bob) book reading was the first thing we did at our current organization as a team for the first week.
We should try to follow it thoroughly.

[arvryna]

wow

[arvryna]

he has another book called clean code, you read that too ?

[setraj]

correction above.