Help a noob understand. What does the "code refactor" business mean?

Users who are viewing this thread

Marty187

Regular
Just like the title says mostly/ I'm not that tech/programming savvy so if anyone can explain it to me and what the long term benefits of it are it would be much appreciated.

Cheers,

Marty
 
Imagine you wrote an essay. Then after you are done you rewrite the essay to be more concise and organize it better but it still says the same thing and makes the same points. Sort of like that.
 
Somewhere I saw that there was a move from C++ to C Sharp in the development process. This is just my suspicion so take it with caution!
As for the short summary of the difference - a C++ coder does not necessarily can code in C Sharp. Same applies the reverse.

I think what happened here was, part of the code was written by non C Sharp coders. At some point TW might onboard some new developers (students) which were C Sharp coders and they decided to move completely to C Sharp at some point.
I have a small experience with C Sharp (I did not like it due to .NET) and some more experience with C++. Basically I think they need to get rid of the old code and rewrite it in C Sharp. The reason why I think this is the case are the huge amount of crashes. In most of the cases those occur during some incorrect "reference/initialization" of other parts of the code.

This is just my guess and I hope I am wrong because if I am right it will take lot of time to get this done.
 
Refactoring: Reorganized code but the same behavior.

It is often important when one realizes they made the wrong design decision(this happens constantly in ALL software development) and need to reorganize to support future things they plan to implement. While technically never "necessary" it is definitely considered best practice in terms of changing architecture during development.

Sometimes refactoring can be used as an excuse for other problems, but really it is a regular important part of software development.
 
Somewhere I saw that there was a move from C++ to C Sharp in the development process. This is just my suspicion so take it with caution!
As for the short summary of the difference - a C++ coder does not necessarily can code in C Sharp. Same applies the reverse.

I think what happened here was, part of the code was written by non C Sharp coders. At some point TW might onboard some new developers (students) which were C Sharp coders and they decided to move completely to C Sharp at some point.
I have a small experience with C Sharp (I did not like it due to .NET) and some more experience with C++. Basically I think they need to get rid of the old code and rewrite it in C Sharp. The reason why I think this is the case are the huge amount of crashes. In most of the cases those occur during some incorrect "reference/initialization" of other parts of the code.

This is just my guess and I hope I am wrong because if I am right it will take lot of time to get this done.


lol I hope you are wrong because that sounds like a massive project (unless there's a very good day for it).
 
Somewhere I saw that there was a move from C++ to C Sharp in the development process. This is just my suspicion so take it with caution!
As for the short summary of the difference - a C++ coder does not necessarily can code in C Sharp. Same applies the reverse.

I think what happened here was, part of the code was written by non C Sharp coders. At some point TW might onboard some new developers (students) which were C Sharp coders and they decided to move completely to C Sharp at some point.
I have a small experience with C Sharp (I did not like it due to .NET) and some more experience with C++. Basically I think they need to get rid of the old code and rewrite it in C Sharp. The reason why I think this is the case are the huge amount of crashes. In most of the cases those occur during some incorrect "reference/initialization" of other parts of the code.

This is just my guess and I hope I am wrong because if I am right it will take lot of time to get this done.

lol I hope you are wrong because that sounds like a massive project (unless there's a very good day for it).

Duh replied in another thread they had hoped to have it wrapped up and ready for release today but found some unacceptable bugs. So sometime next week likely we'll see it, but regardless that means they are just about done.

EDIT: Here https://forums.taleworlds.com/index...r-singleplayer-and-engine.422296/post-9487287
 
Duh replied in another thread they had hoped to have it wrapped up and ready for release today but found some unacceptable bugs. So sometime next week likely we'll see it, but regardless that means they are just about done.

EDIT: Here https://forums.taleworlds.com/index...r-singleplayer-and-engine.422296/post-9487287

When they are done refractoring will that also mean that fixing bugs and implementing/updating features will be easier for them so they can roll out changes more quickly/efficiently?

Thanks for the aswers so far people.

Cheers,

Marty
 
It means adding some specific new features will be easier for the developers.
It doesn't mean the team will be more efficient of better managed or that their release roadmap will be more predictable, you need to "refactor" the project management for that.
 
It means adding some specific new features will be easier for the developers.
It doesn't mean the team will be more efficient of better managed or that their release roadmap will be more predictable, you need to "refactor" the project management for that.

There's a reason companies like Rockstar, CD Projekt Red, and many others avoid roadmaps and timelines and estimates (which will INVARIABLY be interpreted as "promises" by gamers) - Making accurate software engineering estimates requires a LOT of time and labor, particularly when you're in the business of creating your own game engine. Most games today are made with pre-made engines like Unreal 4 that have been in development for nearly 20 years and have thousands of resources and documents online. In almost all cases it makes more sense to use that time and labor to simply drive the game forward, software development is mostly iteration and a lot of trial and error due to the enormous amount of variables involved.

 
Somewhere I saw that there was a move from C++ to C Sharp in the development process. This is just my suspicion so take it with caution!
As for the short summary of the difference - a C++ coder does not necessarily can code in C Sharp. Same applies the reverse.

I think what happened here was, part of the code was written by non C Sharp coders. At some point TW might onboard some new developers (students) which were C Sharp coders and they decided to move completely to C Sharp at some point.
I have a small experience with C Sharp (I did not like it due to .NET) and some more experience with C++. Basically I think they need to get rid of the old code and rewrite it in C Sharp. The reason why I think this is the case are the huge amount of crashes. In most of the cases those occur during some incorrect "reference/initialization" of other parts of the code.

This is just my guess and I hope I am wrong because if I am right it will take lot of time to get this done.
I am not sure if I like that. The good thing is C# leave more stuff for modders. But C# isn't as efficient as C++
 
well.. .in the TW . it's meaning "already successfully sell the game so. we have to go $$summer vacation$$ . "
ps . don't worry we have TW Defence force.
think why they didn't sort code last 8 years.
 
I think most people hit the nail on the head here. I'm not a coder myself but know one guy and also googled it up as I was kind of curious as to why the sudden delay.

It is very much a good idea, but from what I can ascertain from the information provided to me; it's often done nowadays 'as you go' as it makes the whole process much easier. Or else something like this happens where it all piles up and you have a bunch of "smelly" code that needs to be addressed.
 
Otherwise you end up with this and can't make further changes. Just ask CCP how Eve Online's POS code is.

artworks-000217017541-6wyf93-t500x500.jpg
 
There's a reason companies like Rockstar, CD Projekt Red, and many others avoid roadmaps and timelines and estimates (which will INVARIABLY be interpreted as "promises" by gamers) - Making accurate software engineering estimates requires a LOT of time and labor, particularly when you're in the business of creating your own game engine. Most games today are made with pre-made engines like Unreal 4 that have been in development for nearly 20 years and have thousands of resources and documents online. In almost all cases it makes more sense to use that time and labor to simply drive the game forward, software development is mostly iteration and a lot of trial and error due to the enormous amount of variables involved.

I know it's hard to plan and maintain a schedule when things keep changing.. But that's how project managers earn their pay. You have to know when are you going to be done with the game, even if it's an estimate. Their people have plenty of experience by now to give good estimates.
Gamers would always find something to complain about, but if the company is transparent enough to warn people of delays because of problems, the reasonable fans (a majority) would appreciate it.
But if the company itself doesn't know, then they'll waste time and be inefficient - because no one cares. They'll also be unable to say much to the fans beyond the date of the next minor release.
 
It's pretty much impossible to make any reasonable assumption about the whole code refactoring thing.
We don't know if we are talking about the whole game or just some parts of it. We also don't know how good they are getting the job done and we don't know how big the difference will be.
All we know is that it takes some time and that it hopefully helps them to update the game faster and better.
 
Back
Top Bottom