Jump to content
  • Advertisement
zuhane

C# Managing a growing project

Recommended Posts

You are writing a program and unless you are basing it on previous code to some extent then you are writing a lot of code. It boils down to building on prior true and tested code. It takes time to get this code and there is no way around that.  Code is time and the creation of codebases take time. You need to have code or design or practices move from project to project and I'm sure you do to some extent. Keep this in mind and try to get better, it's the best you can do. Good luck. 

Share this post


Link to post
Share on other sites
Advertisement

Personally I just accept that there's going to be some level of technical debt. I start with prototypes and flesh out/reduce complexity & repeat code as I go without a huge fear of failure.
Perhaps not the most efficient use of my time but I spend about 25% of my time adding content, 25% programming new features, 25% bugfixing, 10% other, and 15% reviewing the overall codebase to reduce complexity or flesh out prototyped systems with error-resistant mature versions. The benefit of the review process is that you're more knowledgeable about the general codebase when you go to add a new feature. 

Share this post


Link to post
Share on other sites
Posted (edited)

There's always UML if you want to diagram things super formally. Sounds like you are knee deep in complexity from pursuing a modular approach. I would say code that won't be reused outside of the project doesn't need to be overly designed. As a general rule, I don't even design very hard I just jump in and code, then refactor into a design I like that helps me not repeat code everywhere. For example, I have a project that includes a game server, login server, and client. I have code that I refactored into a module that I can use across all three projects. I did this for udp communication, encryption and decryption, and a few other things. Other code I have no desire to use across projects and so I worry much less about its design. It is partitioned into functions/objects that minimize repeating of code. And that's all I do, my project spirals outwards, I refactor, add feature, etc. Old features are in old files I don't have to touch very often. The biggest way to not touch old code is to truly 100% finish a feature before moving on to other features, taking into account everything you can. This is how I am tackling the complexity of my MMO project. I will not add new features until I am 100% done with features that come before it. It has helped me flesh out the design of my data very well. I need a 100% decided on data structure to represent players and accounts, etc. As I said finishing features rigorously helps to prevent from touching old code, unless something about your design is the culprit. My simple designs do not have rippling effects from changes, and all I did was not repeat code. Just divided it up with an eye to not repeat code and to provide a good interface. I already have 3 or 4 classes shared across projects I haven't changed a bit. If you can manage to write code abstract enough to work across projects, it seems you don't have to work on it often.... there's that lol. The code in those files does what it's supposed to do and there's no changing requirements on my end... maybe it's just a miracle lol.

Edited by Dreadstew

Share this post


Link to post
Share on other sites
Posted (edited)
On 5/14/2018 at 8:47 PM, zuhane said:

the code becomes more and more intertwined and interdependent

You have to use a decomposition to ommit it. Just devide a whole tasks to tiny separate subtasks, each of wich solve a problem of its competence by universal way. It allow to ommit remaking of similar mechanics and eliminate unnesessary dependences and  then construct complexive mechanics from its simple bricks. Open-Close is one of principles that help to make decomposition proper. Gang of Fours also have lot of very usefull concepts, but of course described not all possible tricks into its area. But general concept of any of its techniques - is to analize fields for dependences and similarities and determine zones of responsebilities for components and interfaces of interoperation and data interchange before develop a code. It allow to minimize or ever complete avoid refactoring, becouse minimize components dependeces,and also significantly reduce code size .

Edited by Fulcrum.013

Share this post


Link to post
Share on other sites

I've found that it's best to keep working until the code starts getting hard to manage, then refactor until it's manageable again, then write more new code.

Up-front planning sounds good in theory, but it has a few problems in practice:

  • If you spend too little time planning, then you'll run into problems that your design didn't anticipate.
  • If you spend too much time planning, you run the risk of your design becoming just as unmanageable as your code.  Worst case, you never manage to leave the design phase.
  • A lot of ideas that sound great in the design phase turn out to be unworkable in the coding phase.  Some of my worst spaghetti code came out of a beautiful up-front design that had to have new incompatible features patched in to meet new requirements.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!