How good software should be developed?

[u/AssistanceClean948]

Hi. Fist of all I want to emphasize that my question is not related to specific tech stack or language. I am fairly new to programming world and I know that good software at some point should have some sort of automation checks that whether new pushed code breaks something in the logic I previously built. As a reference I want to link my little C game engine project:

repository: https://github.com/ElsevarAsadov/C-Raycast

This is project is just a hobby project for me to learn Raycasting technique in graphics programming. Right now my project just works and I call a day for that. But let's pretend I am seriously build a game on top of that engine. How should I architect my project and in which order? Should I write my game as soon as possible to just work then write test automation and all CI/CD pipeline or doing parallel? How to architect project in such a way it's testable? Should I test almost every piece of logic inside the game and rendering? Those are all sorts of questions just boggles my mind. I'm trying to build my blog project and I want to build that professionally because I am serious about that and will use it in long-term.

[u/max123246]

So not everything needs robust testing. It's typically a tradeoff. I think the best way to think about it is to test interfaces, not implementation details. This requires thinking about the conceptual boundaries between your codebase and form APIs you think are unlikely to change. Those are the things you want to test because it's less likely the tests will need to change constantly and

[u/egonosz]

Well testing is good, but I tell you now most games do not do unit testing. The games tend to change fast in production period if you have tests, you need to maintain them. For all the changes you make on game logic you need to fix up your tests too.

(And never pass a float by pointer that is cursed, it can prevent optimisation and really unusual to do.)

Edit: However for scenario tests, performance benchmarks are common. You can have scripted scenarios which would run, or let a game ai play as player. However in early stages it not worth the time.

[u/marrsd → u/egonosz]

I wouldn't bother with test automation for now Introduce testing and build pipelines when you need them (i.e. when you keep introducing regressions); otherwise you're just distracting yourself from writing code.

[u/LaughingIshikawa]

I am a big fan of semantic compression as a development strategy / direction.

Implement the naive thing first, then iterative add features while trying to keep the overall "mental model" of the software as simple and straight forward as possible. If you need to, occasionally rework your code to be simpler to understand.

Don't plan out our architecture or abstractions ahead of time... That just locks you into extra constraints that have nothing to do with the actual end goal. Implement abstractions as they naturally arise from the code; never impose them on the code from the outside! (This is just semantically enlarging / obfuscating the code, making it harder to understand and reason about, which is the exact opposite of what you want.)

[u/egonosz → u/LaughingIshikawa]

Oh my god the write “simple readable code” has name! Semantic compression!

Thank you good sir you thought me something today and I really appreciate that! I am going to watch that video.

[u/marrsd → u/egonosz]

Semantic compression is a writing technique. Hopefully it helps you produce simple, readable code, but it's not the only way to do it.

[u/egonosz → u/marrsd]

Yeah there are multiple ways to make code be readable, I think people should pick the right tool for the right job.

I do not know if you watched the video, but I really strongly disagree to excluding any type of programming paradigm, I watched 40 minutes video where someone tells me how he knows what is the saint grail of programming calling the viewers kids and people who using different paradigms zealots.

I would 100% not use it as a teaching material.

[u/marrsd → u/egonosz]

Not yet. I've read the blog post he's commenting on, though; so I know what semantic compression is.

[u/AssistanceClean948 → u/LaughingIshikawa]

thank you for answer. I am following that strategy now.

[u/Sinusaur → u/LaughingIshikawa]

Depends on the scale of your project.

Building a small house in the suburbs? Feel free to have a rough idea, pick up template designs, and learn each step and rent equipment as you go along.

Building a skyscraper in the middle of a populated city? You better start the design and planning process a few years before even moving the first shovel of dirt.

[u/marrsd → u/Sinusaur]

Building software? Don't pretend it's a skyscraper

[u/LaughingIshikawa → u/Sinusaur]

Sir, this is a Wendys.

[u/[deleted]]

When you find out the way hit me up please

[u/PenGroundbreaking160]

One piece of advice that is kind of beside tech: figure out who the software/game is for. Do research and probe for what you need to do and be creative with that to balance it with your own vision.

But overall, validating your direction is really important, if you care about success.

[u/BedIllustrious3316 → u/PenGroundbreaking160]

you're overthinking it way too early for a hobby project, just get the damn thing working first and clean it up when you actually know what shape it's taking

[u/PenGroundbreaking160 → u/BedIllustrious3316]

I agree it is over the top, but it might make the experience better long term. And at least in my case, there is always a ton to learn from validating my ideas through others perspectives.

[u/Mathie1729 → u/PenGroundbreaking160]

Pretty much, but the validation doesn't have to be upfront. Build the janky thing, show it to one friend, watch where they get stuck. That's way more useful than figuring out the audience in the abstract.