koobas.hobune.stream
What is the best way to understand code in a project with null documentation?
Hello Devs,
It is our first game and we are a start-up. I had a programmer who happen to do programming and suddenly he is seeming to be a dead weight. Though we knew him personally we thought that he was as motivated as we are and hence I never looked for a code review or documentation. Now it seems that he is slacking hell a lot and we want him out and pay him for all his work.
Now during a conversation he said that "He would not document the code so as we could be dependent on him". Now I am looking at the code and there is no documentation.
The code is all over the place. What would be the best way to understand his code. This question might be really vague but so am I. I am little stressed with the internal problems and I have to get this job done.
Now to give in insight of the details on the code :
The game play mechanic and camera is scripts are the main and they have no documentation.
Too much of Send/Broadcast messages so I am not able to see the references through mono. (irony is that our target is mobile)
Again hefty use of strings in either invoking methods or passing parameters
Update function everywhere which could have been reduced to co routines.
No documentation
Naming conventions are poor with no consistency
Absolutely no pooling with usage of destroy and instantiation. I am excepting memory leaks.
Any advice would be great. As my head is not functioning properly due to the stress, I am just expecting any sort of help or protocols I should adopt to understand the code and work on top it. It could be links from outside or your own experiences. Anything literally. If you want more info from my end, kindly let me know. I would like to provide as much as possible so as to get the best help.
Thank you.
I'd ask over at http://programmers.stackexchange.com/
I've seen similar questions there in the past so I know it's a good place to ask about this kind of situation.
As a side note, you'd do well to get rid of him as soon as possible even if it means you'll have to re-write everything.
I'm sorry to hear about what happened, and his code sounds like a nightmare to maintain or review. Good riddance, I say. :|
I$$anonymous$$O, scrap all the code if possible and get a new programmer. Sounds like you shouldn't even bother with this pile of mess.
Thanks you for your help. We might have to do that. That is what we are thinking too.
What I usually do is break down the code using the order unity calls functions and such. First look at function Awake to see what that does, then function Start, function Update, function FixedUpdate and so on and so on. Just go through step by step and try to understand the code, the function calls it throws, what is used for what. You get the idea.
One thing: Be patient and try to create comments at functions and code-pieces you understand. It may be a slow process, but at-least you understand the whole code when you're finished
One way to build a project is to slap some barely working junk together, to test whether a certain approach will work. Then remember the general idea and do it for real (know as "Plan to Throw One Away.") You've now successfully completely stage 1 of that plan!
I'd scan the code for the guts. Does the camera move on a spring, Lerp+LookAt or pre-done animation curves? Do units move using rigdbodies, character controllers or hand-positioning? Is selection a raycast or OnMouseOver? Bigger explosions by changing which particleSystem vars (or just using 4 predone sizes?) ...
