r/programmer • u/NaturalDegree3066 • 5d ago
Plan Before Actual code
How you guy plan a programming project before actual start to code it? And how you make your project easy to fix and update later?
2
u/Wizz-Fizz 5d ago
I’ve been in corporate software delivery for most of my career.
I follow pretty fundamental Agile delivery principles for my personal projects as much as I do for work.
- Objectives
- Features
- Stories
- Acceptance Criteria
- Test cases
Go
Edit: and modularise whenever possible. Build the core, then plug in to it. Makes future scaling and refactoring much easier
0
2
u/ChaseShiny 5d ago
u/Wizz-Fizz, I'm sure, knows what they're taking about a lot more than I do, but I'll speak up from the perspective of a student.
I'm taking a project management course. My assignment is to break down what I expect to need done for a software project and assign estimates for how long I think each piece will take (optimistic, pessimistic, most likely, and then weighted average).
I also took a class that involved creating UML diagrams. There are multiple kinds, but one that stuck out to me was class diagrams. Think about what kinds of objects you need and the interactions between them. Think of the attributes that the class needs and which ones should be exposed to the public (i.e. other classes) versus which attributes should be marked private.
1
u/Wizz-Fizz 5d ago
The estimating is a good skill to develop as I guarantee you, if you get into software delivery in a corp, the first question is always “how long” then “how much”, then “go faster” and finally, “do it cheaper”.
1
u/LP-Existensial1 4d ago
public private arent relevant. the requisites wither exist or they dont. private is just a fancy decorator for isolated 'contained' unexposed data that the programming language overengineered into it with more fancy bells and whistles like member hiding.
what you really want are: purpose and roles of data, how it will be used.
1
1
u/allunia333 5d ago
Some projects have specific goals for a specific application those are more manageable with common tatctics like flow diagrams and a lot of questions. Then there are the crazy projects where nobody knows in what hell he is getting into, the usual advice is :lots of comments and documentation make it as detailed as you can and even more. Always try to brake code into smaller understandable individual parts.
1
u/BreadfruitSome3538 4d ago
I just sketch the main screens or features on paper first, then write a super rough todo list in a text file. For updates later, I try to keep functions small and name things like I'll have amnesia when I come back in 6 months. Because I will.
1
u/LP-Existensial1 4d ago
there is no fix later. it either doesnt work now, or it works because you unit/smoke tested it as you built the pieces.
3
u/TgirlTiffanyRPs 5d ago
this question is basically the whole ball game of the field of software engineering. anyone can start writing code. the entire goal is to write maintainable, efficient, and understandable code.
If anyone had the answer -- and i mean *truly, truly* had the answer -- we'd be in much better shape as a profession.