SFML community forums
General => General discussions => Topic started by: Halsys on November 09, 2012, 05:38:06 am
-
Uh hi, new member here on the forums.
Been using SFML 2.0 for quite a bit sometime here, Working on a bunch of prototypes with it.
I just wanted to say hi, from the United States and wanted be part of a great library and its community.
I might ask a few questions here and there about some things.... I'm still pretty Avid with C++.
Your Forum header for General was "For everything that is not a help request"...
So if this is not supposed to be here... let me know, please?
I might show you guys a couple of my Prototypes I have been working on...
So, Ya... Sorry if this odd for anyone and there standards.
If I didn't say hi, it would have eaten away at me for not.
Oh and a quick question? Is it smart to build a engine or focus immediately on the game? or Both at the same time? Not all questions are stupid... not that its stupid at all... Okay maybe to me its stupid.
When I think of triple A games, I think engines and Vivid graphics. Ie:Source or Unreal or Frostbite
When I think Indie games, I imagine Very rushed primitive mock ups. Ie: The prototype of Worldofgoo or Braid
This is coming from somebody who over plans everything... and maybe over think too.
Which one is best any way aswell?
-
So it's a help thread nevertheless... ;)
There aren't many popular engines that were developed on their own. The way you should go is writing a game and at the end you'll hace some sort of an engine that could be polished a bit further. Never try to create a generic game engine, it just leads nowhere. Take for example, Quake, CryEngine, Cube-Engine...
That indie games often don't have the nicest codebase is more a finacial problem. ;)
-
Well that's what I have been doing any way but I keep on wanting to plan ahead.
If it wasn't for classes, I would be tearing my the hair out from my skull.
I have been using my mock up Actor class which will be the base inheritance for future Game items(Players, enemies, Doors, Weapons)... So I only need to issue drawing for one kind of class...
Whats a pain to think about is purely Graphics, I would use Window.Draw(X) but that appears to have fallen off the face of the earth so OpenGL is my only option, No biggie... Because its a 2D game it might actually help.
-
I would use Window.Draw(X) but that appears to have fallen off the face of the earth
What?? ???
Are you maybe looking for window.draw(x)?
-
Ya, Doesn't appear to exist with my copy of Code::blocks.
I saw Sprite.draw, But I couldn't figure out how to use that either.
Its been bugging me for weeks. Maybe I just need to rebuild SFML 2.0... and see if that works.
-
Auto-completion is a (usually buggy) feature of the IDE, NOT the official doc. Don't rely on it, go read the documentation and tutorials on the website instead.
-
See I knew I was crazy... I never had auto correct fail on me till now.
Know any way to fix it?
-
Is it smart to build a engine or focus immediately on the game? or Both at the same time?
There is an often-cited article Write Games, Not Engines (http://scientificninja.com/blog/write-games-not-engines).
Don't forget that a lot of functionality has already been implemented. For SFML, I once listed some additional libraries (http://en.sfml-dev.org/forums/index.php?topic=9135.msg61716#msg61716) that might be interesting. Also take a look at other libraries like Boost, maybe you don't need to reinvent the wheel.
Know any way to fix it?
Use Visual Studio and Visual Assist X :P
No, maybe Code::Blocks also has a symbol database in a file which can be deleted/reset. But as Laurent said, it is probable that the auto-completion is not very mature and still buggy. You will find more about it on Google.
-
I believe even I have written an article on this... (http://www.morleydev.co.uk/blog/2011/08/13/video-game-engine-easy-flowchart/)
The tl;dr version is: The engine is the result of the game. Good code is inherently reusable, so the good parts of games will be reused (one reason I try and use strict TDD (http://en.wikipedia.org/wiki/Test-driven_development) is to ensure reusability and modularity). This gets cobbled together into what is called an 'engine'.
The best engines tend to be driven by a game. Even if it's known this "engine" is going to be used in other projects, it's features are derived from the games it's being written for. The engine then evolves and grows from these requirements until it reaches maturity after a few projects.
This keeps developers focused and the features usable, instead of getting distracted by the various shiny things they can try but have no need for and will probably never actually get used enough to justify their existence.
Trying to make an engine before starting a game is very much "putting the cart before the horse", as one commenter on my article points out :)
-
Well both of you strike a good argument(And articles), I never did want to reinvent the wheel.
The fact that I'm here, on a forum of a "Multimedia" library, proves that I speak just that.
Also i'm in the right place... considering what you guys told me.
And I knew making a engine would be a stupid endeavor, You guys proved it and now I know for sure.
If I wanted to make a engine all by my lonesome... there would be no "game".... or engine.
Not that I couldn't do it but because I would get bored... I like games not tech demos.
I was also right that it WAS a stupid question... Ha!
If this is all true(About the game not the engine), What would the workflow be to make it?
And I did see TDD, I like it, and I might try it. but I want this to be answered.
So far my workflow has been very hectic and irrational most of the time.
And what I usually get is either incompatible code from the last thing I implemented.
Or I strike gold and get something I want, Which is 4/5's of the time.
I watched Notch write a game for a Ludum Dare, on I think twitch?
He had this workflow about it where he kept pounding at it and didn't care to much for the structure of it.
So it looked crude and inefficient(Structure not speed), Granted this was Java and he can see his changes as he set them. But it wasn't enough for me to stand up and say "Forget this, its Java now".
Then I watched one of the Amnesia Dev's, No different, He had low level code for the complicated and High level scripts for the simple, and yet again... he got it out fast, even faster than notch did.
So basically I believe at that point, that a good workflow and style is key.
So you can tell, I am not all sorts of confused. I'm actually hoping you guys might have a tip that might help me. Maybe a library that has a usable interface to Python like the amnesia Dev? Or is that something I might need to make?
But so far, I got a lot to chew on now, Thanks!
-
As for the Auto correction... I would just go get Visual Studio, but I like my IDE to be on Linux too.
OR I might just not worry about it and keep reading the documentation.
(Taking your advice Laurent :P)
-
As for the Auto correction... I would just go get Visual Studio, but I like my IDE to be on Linux too.
OR I might just not worry about it and keep reading the documentation.
(Taking your advice Laurent :P)
I use QtCreator and I'm pretty happy with it. It's available in Windows, Linux and Mac.
-
Well both of you strike a good argument(And articles), I never did want to reinvent the wheel.
The fact that I'm here, on a forum of a "Multimedia" library, proves that I speak just that.
Also i'm in the right place... considering what you guys told me.
And I knew making a engine would be a stupid endeavor, You guys proved it and now I know for sure.
If I wanted to make a engine all by my lonesome... there would be no "game".... or engine.
Not that I couldn't do it but because I would get bored... I like games not tech demos.
I was also right that it WAS a stupid question... Ha!
If this is all true(About the game not the engine), What would the workflow be to make it?
And I did see TDD, I like it, and I might try it. but I want this to be answered.
So far my workflow has been very hectic and irrational most of the time.
And what I usually get is either incompatible code from the last thing I implemented.
Or I strike gold and get something I want, Which is 4/5's of the time.
I watched Notch write a game for a Ludum Dare, on I think twitch?
He had this workflow about it where he kept pounding at it and didn't care to much for the structure of it.
So it looked crude and inefficient(Structure not speed), Granted this was Java and he can see his changes as he set them. But it wasn't enough for me to stand up and say "Forget this, its Java now".
Then I watched one of the Amnesia Dev's, No different, He had low level code for the complicated and High level scripts for the simple, and yet again... he got it out fast, even faster than notch did.
So basically I believe at that point, that a good workflow and style is key.
So you can tell, I am not all sorts of confused. I'm actually hoping you guys might have a tip that might help me. Maybe a library that has a usable interface to Python like the amnesia Dev? Or is that something I might need to make?
But so far, I got a lot to chew on now, Thanks!
-
As for the Auto correction... I would just go get Visual Studio, but I like my IDE to be on Linux too.
OR I might just not worry about it and keep reading the documentation.
(Taking your advice Laurent :P)
I'm late to this, but just wanted to add my opinion.
shitty working code is better than non-shitty, will work one day code. GNU Hurd is an unfair example, but still an example.
Throw your code out there and make it work. Don't worry about style, structure, or anything else. Once that's done, refactor mercilessly.
The problem with writing an engine before a game is that it requires experience. You don't know what problems need to be solved, you know what problems you *think* need to be solved. So you write sloppy code, get it working, then later on, use your practical experience to refactor it. By then, you have a much better idea of the problems you need to solve, and you may even know a bad way to solve them (Because you did just that).
If Carmack wanted to write an engine before the game, let him. He knows what the hell he's doing. You most likely don't, write the game, let the engine be emergent.
-
Of course the "write shitty working code then refactor" approach has the slight downside that shitty code tends to be difficult to refactor by nature whilst good code is inherently easily refactored and re-used. You can easily code yourself into a spiderweb of a corner if you don't keep that in mind xD
Hence why I do the whole TDD thing, breaks things down into such small parts they tend to be easy to refactor and manage. Also it emphasises refactoring as one of the most important steps when coding, which is nice because...well, it is.
-
Of course the "write shitty working code then refactor" approach has the slight downside that shitty code tends to be difficult to refactor by nature whilst good code is inherently easily refactored and re-used. You can easily code yourself into a spiderweb of a corner if you don't keep that in mind xD
That's a statement that you cannot prove or disprove, you can only assume.
Your other assumption is that worrying over the design is somehow going to get you to the spot you want to be when you're inexperienced.
The truth, the thing people don't like to say, is that both approaches are just as likely to 'fail', meaning, you end up with a design that's not good for the task at hand, and it's directly as a result of the experience of the developer (or lack thereof). That experience factor outweighs any amount of planning you do.
You'll find you save time by not making decisions. "I don't know what is best here, so I'm going to do the simplest thing that works and see how the usage shakes out" is often times a superior approach, especially when you're developing software you've never developed before.
At least when you're doing that, you're not wasting time building abstractions and architectures that are ultimately harmful (or at the very least go away because they weren't really useful). In both cases you'll find yourself having to refactor, in one of those cases, you spent a lot more up front work, and throwing TDD into the mix just amplifies it even more.
-
That's a statement that you cannot prove or disprove, you can only assume.
That applies to the most other answers here, including yours. Beginning a sentence with "The truth" doesn't change that ;)
Throw your code out there and make it work. Don't worry about style, structure, or anything else. Once that's done, refactor mercilessly.
That's too extreme. While you are right that a long and detailed planning phase is pointless when the developer has no experience, he should not spend no thoughts at all, either. Imagination of code structure before writing it is an important part of experience. When you plan already the first time, you have later the possibility to see how much could be realized 1:1 in the code and where assumptions were wrong. This way, you can learn much more than when you have nothing to compare with.
-
Hehe, just to put the obvious out there:
I think it's good to have a balance when you're coding.
Don't take either hard-line approach - do a bit of everything.
So before you start typing, think about what you're trying to achieve. Plan it around everything else that's in the system or going to be in the system. Don't spend too long doing this, because for all you know you're going to change your mind later :P But at least plan a little. This way you can save a lot of time later, and often come up with better design and better code.
-
That applies to the most other answers here, including yours. Beginning a sentence with "The truth" doesn't change that
Everyone makes assumptions, but some assumptions are more dangerous than others. The inexperienced believe they can think their way around that inexperience, the experienced know better.
Balanced isn't relevant, we're talking about a specific context, an inexperienced developer trying to write a game. That's automatically unbalanced, said developer has no idea what a balanced approach is, much less the ability to take one.
Instead of believing you're smart enough to 'figure it out', it's better to admit that you're not, and *plan* for mistakes by making them as cheap as possible. One of Erlang's strengths isn't its ability to never fail, it's the ability to minimize the impact of the failure. It's the same idea here.
If you're writing YAGE(Yet Another Game Engine), have at it, use your prior experience to try and navigate some of the pitfalls you've seen. Until then, admit that you suck, and work on minimizing the impact of your mistakes.
And to be clear, by inexperienced, I mean inexperienced writing that type of software. An experienced game developer trying to implement a CMS is probably going to make a bad job of it, no matter how many years they've been developing. Until their 2nd or 3rd CMS. In other words, we're all inexperienced in some area's that we may have an interest or a need in.
-
I'm not saying use upfront design. I think upfront design is pretty useless because code changes and evolves.
TDD is not upfront design, it's about letting the code evolve and writing it in a way that makes it easy to evolve. You can do that without TDD, I just find TDD makes this easier for me and gives me a peace of mind about refactoring without breaking anything. I wouldn't have that piece of mind otherwise, and I like that piece of mind. Also it makes it easier for me to track down and isolate bugs if I discover them.
TDD is, in fact, all about: "I don't know what is best here, so I'm going to do the simplest thing that works and see how the usage shakes out".
It's all about expecting mistakes and making them as cheap as possible by making it easier for you to correct them as you let the code evolve.
Code evolves, you can't design it all upfront and you can't fight this. What you can do is learn to work with it, and always remember code can change. Don't resist change, and try your best to not code in a way that resists change.
Yes, you have to let the code "shape itself" as it grows, but you also have to remember that ugly code will make this difficult and can impede this growth. The trick, which you get better at with experience and nobody is ever perfect at (because nobody is ever perfect), is to write code that gets the job done and is easy to extend, debug and refactor.
I try and do that through TDD, others may want to do BDD (which I don't much like), others just throw code and see what sticks. What I was trying to convey is that keeping in mind this goal of getting the job done in a maintainable manner, I reckon, can help limit the times you code yourself into the trap of difficult-to-maintain code.
And of course, always refactor as you go. Refactor constantly whenever you see the need for it. Refactoring is possibly the most important step in coding.
A lot of the above also applies against writing an engine first, an engine typically needs something to evolve out of otherwise it's just another example of "upfront design". Things like Unity have the requests and needs of the users which can be used to drive development. But a personal project doesn't even have that...
-
One thing I like to tell people is the following:
If you cannot couch your argument in anything but 'maintainability', it means you have a weak argument and you really need to look at the alternative.
readability, maintainability, scalability, these are all nebulous ideas that you can't really put your finger on. As such, they're the go to for people who have no real concrete basis for their beliefs, whether that's due to inexperience, or emotional appeal (ie, they just want to do it that way).
I don't mean to pick on you, but talking to me about maintainability is like trying to speak to an Atheist about God (or your deity of choice). I'm just flat not interested in hearing it.
I'll argue until we're both blue in the face, until the conversation turns to maintainability, readability, or scalability. At that point I check out to go do something worthwhile.
-
Isn't maintainability just a shorter way of saying "ease of making modifications and additions without a big risk of breaking the rest of the program that works, and ease of debugging when something goes wrong and the cause tracking down"?
That's what I always thought they meant, unless there's some other definition I'm not aware of regarding code? :P I can gladly go through and change it to be more clear if that helps.
-
Instead of believing you're smart enough to 'figure it out', it's better to admit that you're not, and *plan* for mistakes by making them as cheap as possible. [...] Until then, admit that you suck, and work on minimizing the impact of your mistakes.
That sounds already different from "Throw your code out there [...] Don't worry about style, structure, or anything else". Have you considered that reflecting about code in advance can minimize the impact of mistakes, too?
I am not saying the beginner should write an engine first, but I'm considering it a bad idea to not spend any thoughts at all, just because of small experience. But since you have not responded to my previous argument and now write a whole post about why you don't like the (in my opinion clear) term "maintainability", I doubt more and more that this discussion will yield meaningful results...
-
Isn't maintainability just a shorter way of saying "ease of making modifications and additions without a big risk of breaking the rest of the program that works, and ease of debugging when something goes wrong and the cause tracking down"?
So maintainability means familiarity with the codebase?
http://www.infoq.com/presentations/Simple-Made-Easy
Really pay attention to his distinction between simple and easy, this talk is phenomenal.
Maintainability is important, but the problem is that it isn't concrete. I could argue The One True Brace Style and use maintainability, but at the end of the day, as a developer, having the brace on the same line vs the next has no bearing on my ability to read the code (and I question anyone who claims it does).
At the end of the day you have truly beautiful code, truly awful code, and then there's this huge grey area in the middle. Most code falls in that grey area.
Nexus,
I can't respond to every little thing, if there's something in particular you want me to respond to, let me know what it is. Having said that, as you discovered, my position is not the extreme of 'absolutely no thought', I didn't respond to that particular point because there was nothing to respond to and I didn't want to get into a rousing discussion over whether or not it was a strawman argument (and I still don't).
-
Let me put it this way, if I gave you one massive main function that did everything and asked you to add a feature or fix a bug, it would take you a lot longer to figure out what to do than if I it was neatly ordered into well named and loosely coupled classes and functions.
Going along the shades of grey, then you must admit there are things closer to the former, and things closer to the latter, and it is desirable for code to be closer to the latter than the former.
You could even quantify that in a scientific study by having "ugly" and "neat" code that accomplishes the same goals, giving it to a bunch of programmers and timing how long it took them to finish certain tasks. When looking at the time taken for these tasks, the hypothesis would be that the "neater" code should take trend towards taking less time.
Going back to code after even a couple of weeks, I find, is very similar to coming to it with new eyes. I have to reacquaint myself with it, which takes time. Not as much time, usually, as new eyes. But time.
And you could likewise quantify that in a scientific study by having a bunch of programmers write code in a variety of ways, come back in a couple of weeks and be asked to perform a task against it. When looking at the time taken to extend, the hypothesis would be that the "neater" code should trend towards taking less time to perform the tasks.
At my work, the old code has parts where it's a mess of inheritance and what we now at work consider poor practices. Whenever the business requires us to add something to that old code, we dread it because figuring out where to make changes and what to change takes a lot of time.
The new code is a lot easier to understand, extend and debug. I can get to grips with the parts of it I've never seen before a lot faster than the old code because of this, I can see where I need to make those light-touch changes and track down where bugs are a located lot faster.
And because it's got decent tests around it, often identifying a bug is just creating a black-box test that forces the bug to manifest itself. And I can fix the bug with all the other tests still green, meaning I can have some peace of mind I haven't broken it completely and more importantly, if I have broken something I can see that immediately without waiting for it to fail QA.
The legacy code is a time sink that costs the business money because we can't work with it as quickly as we can the newer code, even when we have still never seen the newer code before (and this is a massive code-base so that's not uncommon).
Yes, most code ends in that huge grey area. Nobody is perfect and no code is perfect code. Doesn't mean we shouldn't try as hard as the needs of practicality, business and time allow.
Ultimately I think you're getting hung up on a word instead of my point of "remember you'll need to work on this code again, so don't make it too spaghetti-like in the name of 'banging it out', because you'll just slow yourself down in the future". Time is money, I find the time debt built up in implementation is paid back when I need to debug, refactor and extend.
You know, I think at first we were arguing for pretty much the same thing. I wasn't arguing against "banging it out", just saying it may be wiser to try to do so in an intelligent manner even if it's a little slower. And of course, refactor mercilessly and constantly. As soon as you finish something, look to see how that could be refactored to improve it, and then refactor. Refactoring is not a last minute thought, it's a vital step after all.
If you're going to argue it accomplishes something, you also have to argue how or the how has to be self-evident. I may have failed to do that adequately, and if so I apologise.
-
Maybe ichineko is a uni coding teacher? He has their attitude(he really does). They seem to have switched their head with their a**.
one massive main function that did everything
Sounds like the practices some C teachers at my uni endorse, just one .cpp file, everything in main().
You could even quantify that in a scientific study by having "ugly" and "neat" code that accomplishes the same goals, giving it to a bunch of programmers and timing how long it took them to finish certain tasks.
Again, figuring out what spaghetti code does(and I mean extreme spaghetti code, something that should warrant getting authors face bashed in) is the exam around here, along with writing complete game in sdl or whatever else(I'm so using sfml for that bullshit..) and then compiling it on linux, three months into C 'study'. ;D Good luck begginers..
The 'throw it out there and make it work' attitude is somewhat strong in teachers around here.
And also the attitude of 'If I say so you must listen and I don't have to explain my decision'.
-
The 'throw it out there and make it work' attitude is somewhat strong in teachers around here.
And also the attitude of 'If I say so you must listen and I don't have to explain my decision'.
At least here in my country there's different approaches, while some professors go for lumping everything in one place, others go for a big class structure, some say that software designers would be unnecessary if all programmers were good programmers (a bit extreme, but I kind of see where he's going).
The pattern goes in that most older professors go for lumping while the younger ones tend to go for a structured way of doing things even if sometimes going with old practices (unnecessary inheritance and polymorphism being one or using C when they could use C++ just because they're used to it).
In my opinion I think that making things work in order to understand them and then going for a structure once you do is the right choice.
Since you can't know how to build something if you don't know what you're building it with. Of course the testing takes time, but once you know your all-around environment you can make well thought structures without taking too much time because you already know how things work.
-
In my opinion I think that making things work in order to understand them and then going for a structure once you do is the right choice.
Since you can't know how to build something if you don't know what you're building it with. Of course the testing takes time, but once you know your all-around environment you can make well thought structures without taking too much time because you already know how things work.
Basically. Software is emergent, it's a mistake to think you can successfully plan ahead for something you've never done. Software developers tend to be intelligent people, but they put too much faith in that intelligence.
At my work, the old code has parts where it's a mess of inheritance and what we now at work consider poor practices.
Lots of inheritance was a 'best practice' for many years. Who do you think wrote that kind of code? The ones who believe you should do the simple thing and move on, or the ones who believe you should think deep thoughts and write 'maintainable' software?
What things are you doing today that the future developers are going to complain about because you architected it in such a manner as to cause them undue pain? What best practices are you employing now that in 10 years we'll know has a tendency to lead to difficult architecture?
I don't know, and neither do you, but the difference is that one of us is moving forward as if we do.
And that's a major reason why I dismiss arguments about maintainability. Well, that and the aforementioned nebulous nature of it that causes people with weak arguments to fall back to it constantly.
So at this point Morley, it's safe to say you've continued trying to press the maintainability argument, which means I'm finished with the conversation. I'm just not interested in something that's neither actionable, nor concrete.
-
Your issue with maintainability is you perceive vagueness in the goal, so I went out of my way to try and clarify everything without vagary. I didn't even use the word maintainability in that post, so I'm not sure how you can say I was still "pushing" it.
Heck, at this point I'm willing to say you're arguing for the sake of arguing since my entire argument has included your basic point of "just smack it out", but with a single caveat of "try and remember you'll be seeing that code again".
This is not upfront design. I have never called for upfront design, and been calling for, the entire time, doing the simple thing and moving on. Light touch changes, and try and code in such a way as to make light touch changes easy to do.
Don't write a lot before you refactor mercilessly, write a single part and refactor that mercilessly. Then write the next part, refactor mercilessly. Then the next, refactor, then the next, refactor, then the next, refactor. That way the code evolves and the constant refactoring keeps it neater.
You haven't responded to a single point in my post, simply dismissed it without showing you even read it beyond one line, which you quote mined completely out of context. Remember, I said what is now considered poor practice.
I fully allow future best practices will not be the same as current best practices, languages and tools evolve. These new practices are better. They continue to get better? That's amazing, can't wait. Until then, I fail to see the evil in trying to do the best you can with what you've got. Especially since whilst it may not help in ten years, but ten days? Ten weeks? Ten months, even?
We have refactoring and code completion tools not available those years ago, and so we can do things with ease that would have been difficult those years ago. And that has driven a lot of practice changes and will continue to do so.
And when I say a mess of inheritance, I mean things like deep inheritance structures with god parent classes that contain behaviour that depends upon their children's behaviour. That kind of mess.
-
I can't respond to every little thing
Sure, but you can write two posts to explain your problems with the term "maintainability". I know it's easier to pick single words out of context instead of responding to arguments, but it's not the base for a discussion.
Lots of inheritance was a 'best practice' for many years. Who do you think wrote that kind of code? The ones who believe you should do the simple thing and move on, or the ones who believe you should think deep thoughts and write 'maintainable' software?
In C++, there are several problems. Modern C++ techniques have only come in the 2000's with authors like Meyers, Sutter, Alexandrescu. And at the moment we are only seeing the first practical implications of C++11 being more and more supported. People interested in the language experience progress first, it takes a while until the "average developer" learns new idioms.
A second problem is the vast amount of terrible literature for C++. Many books have taught an antiquated C++ style, close to the beginnings at "C with classes". The same is true for C++ libraries, it is not easy to find a well-designed API as in SFML, especially in the field of game development. Inheritance overusage was, and still is, a big problem. Not only in C++ -- take a look at the Java standard library, especially the collections. Java has fewer abstraction tools than C++ -- in C++ they often were not used, although available.
I believe that this "not-usage" is not only a result of small practical experience, as many experienced people (in terms of finished projects) still don't use modern C++. It is rather also a consequence of the difficulty to find good articles or books, which in turn is due to the complexity of C++ and the slow spread of knowledge in the community. A lot of techniques can't be learned only by programming, thus I find it important to read about them, and to try to apply them in projects, beginning with the first project.
It is a fallacy to say "look, maintainability regards led to these bloated hiearchies, therefore it is better if we do not do it". You can't just leave out all the cases where intense planning resulted in good code design.
-
MorleyDev, a rose by any other name is still a rose.
Nexus,
that's revisionist history, inheritance/type based polymorphism had been a part of C++ for 15+ years at that point.
In general, code was not written like that because people were just starting to figure out the ramifications of the "new" C++ standard, it was written like that because as an industry that sort of architecture was a best practice. C++ developers didn't start preferring composition over inheritance, the industry did.
Todays best practice is tomorrows mistake
It is a fallacy to say "look, maintainability regards led to these bloated hiearchies, therefore it is better if we do not do it". You can't just leave out all the cases where intense planning resulted in good code design.
You are not understanding me.
maintainability and scalability arguments are roughly the same in terms of usefulness. Here's what I mean.
We need to do X because it's more scalable
vs
we need to make sure we can handle 10k concurrent users even though we're only estimating needing 3k concurrent users. The business leaders tell us they expect us to double in size over the course of the first 6 months, that should give us breathing room.
One of those will lead to much better decisions than the other.
Likewise with maintainability.
We need to do X because it's more maintainable.
vs
We need to make sure this algorithm can be changed out easily since we're not sure exactly what the performance requirements are, but we know that this is going to be integral to said performance.
And look at the counter-argument
we don't need more maintainability.
vs
No, I don't think that piece is going to be the bottleneck for performance. Why don't we stay simple, slap this algorithm in, but with the idea that we may need to abstract it later. We'll get something up and running quickly and then test, because I think we're going to find the performance bottleneck is going to be the DB I/O, not the number crunching.
One of those leads to a more valuable discussion.
Which is why I say, if the only argument you have for doing a thing is that it's "maintainable" or "scalable", or "readable", then you have no argument.
Lets write tests because it's changeable. vs We're writing accounting software, which can get our asses sued, so for the calculation module, we're going to Unit Test. We're also going to implement code reviews, but only for this module because both of these things have an up front cost that isn't worth it for the rest of the application. risk vs reward.
What tends to happen is that when people don't have the knowledge either due to inexperience or external factors (business doesn't know what's going on, the software is new, what have you), you need to be making concrete decisions based upon that lack of foreknowledge, not based upon 'maintainability', et al.
And that's the context we're speaking in, someone who is learning. It is better to stay simple, and refactor mercilessly, than to wax poetic about how you have 90% test coverage.
It's all about making good decisions, and basing your decisions on something as nebulous as "maintainability" rarely turns out to be good.
-
Well ichineko, now I'm convinced we've been arguing for pretty much the same thing xD I may have not been expressing that properly, if so I apologise, my mistake.
To repeat and I hope in a clearer way: I've been trying to push the idea of doing things as needed, and anticipating the fact you can't plan for the future. Trying to remain able to react quickly. Which is especially useful as code evolves because things will change a lot in those early stages as you learn more about solving the problems you face.
Don't make concrete decisions, and as an extension try not to let your decisions become concrete by accident. You know, expecting things to need to change so not burning your bridges behind you, so-to-speak...