| I would trust documentation with a grain of salt. Very rarely do I find intensive and accurate documentation for distributed systems. However, documentation may be helpful for things such as stand-alone components and REST endpoints. Those would be taken with possibly 2 grains of salt. The one thing that you would never want to do is actually read through the code line by line*. HOWEVER, let it be noted that I mean this as an initial point of insertion. As a Computer Scientist, your first step should be in attempting to ask the right questions. Think of it like a game of 20 questions ( N questions in this case...). To do this, one of the best things I have done is to follow the process. All distributed systems attempt to solve one or several use cases. Define these use cases and then analyze the code basis from there. For example, a use case that involves a REST Endpoint can be updated your profile photo. The use case would define a point of entry (where/how to submit a new photo) and a point of submission (the REST Endpoint). From this, we can search for two components in the system that facilitate this task. === A good word of advice in understanding any code base is that, nine times out of 10, it is ALWAYS easier to read code once you understand its purpose. === > Language Specific Strategies As for some good language specific strategies, be knowledgeable of what Paradigm the language falls into. For example, Java code tends to have a single point of entry for most cases. Whereas Javascript (as a functional language) can have several entry points (or even none at all). For functional languages, be mindful of how they are structured. Functional languages are not object-oriented by nature but they can be if implemented properly. As such, try to notice the key differences (i.e. prototyping). > Cloud Debugging? I would not consider it. Debugging should be a constant process of development. Not even the best developers can write perfect code from the start but with enough work and constant QA testing/Unit testing during the development process, any code base can become easily manageable for debugging. In addition, learning how to read Stack Traces can save HOURS of debugging. > Tracking knowledge from Module to Module Personally, I keep notes. I pretend as if I am writing an API document. Nine times out of ten, most modules take an input and provide an output after some calculation. So long as the calculation is sound, I do not worry about the calculation and only record the call to the module itself and its return. Other cases like classes can be tracked by the same notion. > OH THE COMPLEXITY It's a necessary evil. No one ever said being a developer was easy. And no one ever said the best things in life are free and easy. I work hard for what I do and for what I want. I love my job. I don't think I would ever consider changing careers. Sometimes the complexity does become overwhelming and its hard to handle. But if you wish to know my little secret, schedule yourself some mandatory free time. And stick to the schedule. This doesn't mean try breaking away from the computer, but just do things that help you relieve stress. Talk to a friend and have a drink or two. Developing is tough on the mind but it is an occupational hazard in the least. > Updating/Maintenance If it's open source, let the users dictate when the updates should happen. I believe in Agile development and trusting the users. But when it comes to updates and maintenance on a corporate system, always try and set some goals for the change. Why are you updating/performing maintenance? Is it to improve the speed/response time? Is it worth the cost of time/labor? > GOLDEN RULE: Ask Questions. Be Skeptical and always tread carefully. We are Developers. We are Problem Solvers. Not Problem Makers. BG: I have 6 years of experience working with Corporate level architectures and distributed systems. And earned my BA in CS minor in Information Systems. In my time, I have worked with multiple functional, object-oriented, and web based languages. I have also worked as a Full-Stack Developer for roughly 3 years now. |
I did not think anyone would take time to answer so many of my questions. I agree with you on lots of points you mentioned above. Regarding the documentation I usually trust it if the module or the system is new, but if its old enough, i assume its outdated, architectural drift exists and only take that as a reference of how the system was planned to be like.
This also gives a lot of use-cases to begin with and understand the control flow. Regarding test cases, integration and regression tests help a lot in finding failures but I feel more confident about them if written by the same developer as the original thought for the code change is more pure with him and the reviewer.
For knowledge tracking, I guess there is no easy way, one learns from experience and time, but it would be great if there were some great tools to capture thoughts and map them to a definite state in the application without making any change in the codebase.
I have been in my academics for 6 years doing my bachelors and masters and less than a year in my professional career. The sheer amount of stuff one needs to know about building scalable and distributed applications is just amazing and nerve-wracking at the same time and I will keep your secret in mind :)