It is our first game and we are a start-up. We had a programmer who suddenly 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 a lot and we want him out.Now during a conversation he said that he would not document the code so as we could be dependent on him. I looked 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?Details of the code:Written in C# and targeting a mobile platform using Unity3D.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.Again hefty use of strings in either invoking methods or passing parametersUpdate function everywhere which could have been reduced to coroutines.Naming is poor and inconsistet Absolutely no pooling with usage of destroy and instantiation. I am expecting memory leaks.What protocols should I adopt to understand the code and work on top it?
What is the best way to understand code in a project with null documentation?
documentation;reading code
What you need are Characterization Tests.A characterization test is a test that characterizes the actual behavior of a piece of code. THere's no Well, it should do this or I think it does that. The tests document the actual current behavior of the system. (Feathers, Working Effectively with Legacy Code, 186)You can use characterization tests to develop documentation for the code after-the-fact. This is not the preferred way of doing it, of course; it is better to write tests before writing code. But when you are dealing with a legacy codebase (and according to Feathers a legacy codebase doesn't have to be old—a brand new codebase has the same characteristics as an ancient one if it does not have tests) characterization tests are a great boon.Feathers says (186):Here is a little algorithm for writing characterization tests:Use a piece of code in a test harness.Write an assertion that you know will fail.Let the failure tell you what the behavior is.Change the test so that it expects the behavior that the code produces.RepeatNote that these tests are different that regular TDD tests in that they are not intended to describe what the codebase should do. They only describe what it does—which is exactly what you are wanting to determine.If, of course, you find that it does something wrong, you now have tests that allow you to change this behavior with TDD. You change the test to expect what you actually want, and then fix the code until it does that.Feathers has quite a detailed treatment of how to write such tests. He also discusses in other parts of his book how to get the code into a test harness in the first place (and thus he assumes it in step #1 above) but that goes beyond the scope of this question.