Is this the way you build out a real-world codebase?
Posted by throwaway0134hdj@reddit | ExperiencedDevs | View on Reddit | 19 comments
Assume you are the sole developer and you’ve gathered all requirements from the client.
Starting from the ground up - all code is composed of some combination of variables, loops, conditions.
The meaningful combination of those variables, loops, and conditions we bundled up as a reusable function - a chunk of logic that can be called later in our codebase.
As things evolve, we might run into a situation where we need multiple occurrences of the some “thing” or “entity” (bank accounts, users, orders, abstract concepts) then you want to bundle that up as a class with self-contained state and methods. Here we can basically copy and paste the same entity indefinitely with custom state but with access to the same methods/behaviors.
We hook up a database and ORM to map out all the states and interactions of those objects.
Is this essentially how real-world codebases/apps are developed out?
ExperiencedDevs-ModTeam@reddit
Rule 1: Do not participate unless experienced
If you have less than 3 years of experience as a developer, do not make a post, nor participate in comments threads except for the weekly “Ask Experienced Devs” auto-thread.
adambkaplan@reddit
Not really - in my experience the entity bits are one of the first pieces that are built. Entities and domains naturally emerge from even the quickest/most cursory requirements analysis. Exercises like user story mapping also help identify what sort of application/architecture is needed.
DB/ORM is “next” for me, one the initial entity model is creates. Shared “business logic” is last, added incrementally as each concrete feature/user story is implemented.
throwaway0134hdj@reddit (OP)
Can you give an example of this in where you are determining the classes from the requirements phase
adambkaplan@reddit
Here’s a real world example from what I’m working on (a CI/CD platform):
Developers on this platform need to define an “Application.” The application has a name, description, and version number.
Each application consists of one or more components. Each component has a name, description, a reference to a Git repository (url and branch), and a reference to the artifact it produces.
For each application, the system creates a “snapshot” representing the most recent successful build of each component. These snapshots can then be used to test or deploy the application as a whole unit.
This is just the “tip of the iceberg”, but I bet you can start drafting an entity/relationship diagram in your head.
tonygoold@reddit
Software is normally developed top down, not bottom up, which is what you’ve described. You architect the solution at a high level and decompose each piece incrementally before writing a single line of code. If someone wrote code using the approach you described, it would be a horrible mess and inevitably require a complete rewrite. An important skill for developers is being able to see the big picture and plan accordingly.
throwaway0134hdj@reddit (OP)
Thanks. Could you give an example of the top-down approach for maybe sth like a banking app.
tonygoold@reddit
Sorry, I'm not designing your app for you. If you want examples of what this process looks like, search for things like:
That should be enough to get you on the right path. There are also many, many books on software architecture and data modelling.
abrahamguo@reddit
I always recommend starting with the data model. What types of records will you need to store, and how will they be related to each other?
throwaway0134hdj@reddit (OP)
Basic data model would be: Customers, Accounts, Transactions
kkingsbe@reddit
There’s different architectures and ways of developing software (event-driven, domain-driven, test-driven, MVC, etc). I’d start with looking those terms up, that’ll get you going in the right direction
throwaway0134hdj@reddit (OP)
I get the general idea of the architecture styles but when you are putting your fingers to the keyboard what is the thought process of developing out the codebase?
kkingsbe@reddit
If you’re working with others on a project, at least 75% of the work will be done before you start programming.
throwaway0134hdj@reddit (OP)
I sometimes do sole dev greenfield work. Trying to vague how others approach it.
nitzky0143@reddit
It's usually iterative, not a straight line. You evolve the codebase in cycles...Gather requirements, implement some functionality, refactor as new needs arise, some tests, repeat.
throwaway0134hdj@reddit (OP)
Yeah for the small coding projects I’ve done it’s never linear… like code a little, then client says “No not that” and then I iterate indefinitely until it’s the way they like it. I’ve taken some CS courses but mostly self-taught and wondering if I’m doing it right. I understand there really isn’t any set standard or one size fits all solution though it’s kind of fire at the hit and do what makes sense in that particular situation.
Teh_Original@reddit
You might be interested in reading this: https://caseymuratori.com/blog_0015
What you've described is a way I've seen it done. The best way? Maybe, maybe not.
throwaway0134hdj@reddit (OP)
Yeah I’m just trying to define some kind of mental model for how software emerges and the step by step process of it.
soundman32@reddit
I nearly gave up programming when I realised it's really just putting stuff in one list and filtering that list into another list, and you just repeat that over and over.
local-person-nc@reddit
"gathered all requirements from the client". Stopped taking it seriously there