Well, I would surely not recommend you to go over the application code and look for things like classes, interfaces, data model, design patterns etc. It definitely has to be everything else than the application code.
If you have just landed on to a new application development project and shall be going to start working on the application soon, you may want to understand some of the following on day one rather than nitty-gritties of the application itself:
- Business overview: The idea is to understand key business functions which is served by the application. The output of business overview can be functional decomposition which can be later related to one or more modules of the application. The key is to understand what is value addition to business by making use of the application. I would like to re-emphasize that understanding functional decomposition of business (related with application) is the key.
It is key to understand business relevance of the application.
- Overview on functional & non-functional aspects of application
- Application architecture & related details: The idea is to get a high level understanding on key architectural components (modules/components). It will be good to understand the mapping between these modules and the business functions.
- Details on integration with other applications: The idea is to understand internal and third-party systems which integrates with the application to deliver the business offerings. One may want to understand the integration protocol, patterns and the tools & frameworks used for integrating with the application. In my experience, I have found the company/business units’ team to be using different protocols such as SOAP/REST, thereby leading to inconsistencies in technology stack.
- Details on Non-functional aspects such as performance, security: The idea is to understand the performance aspect of the application in terms of required system throughput etc, and also the security objectives that needed to be fulfilled. From efficiency perspective, it may be good idea to ask questions regarding the volume of requests arriving to the application in a given time frame. From security perspective, some of the following can be good questions to ask or understand:
- Access control for different functions
- Authentication/authorization mechanism (whether single-sign on)
- Technology overview: This would help you to understand underlying technology stack such as application server, programming languages, databases, component model, database ORM framework etc.
- Overview on some of the following: These are some of the areas which may be of interest to architect or technology lead level person who will be involved in building team, setting up environments (development and QA), setting up build and deployment etc.
- Team working on the application; Skills requirements
- Preferred development methodologies & related environment: Most commonly, this could be either of waterfall or agile method.
- QA environment and preferred methodologies: It is good to understand QA tools & frameworks and practices used by existing team, if any, working on the application.
- Build & deployment methodologies & related environment
- Software quality governance (code review, unit testing)
But, believe me, the last thing that you would want to do on day one, and which may prove to be of no use is going into application, looking at the code and trying to figure out what does it aim to do. This will leave you in the state of confusion and be of no help. The most important activity you may plan to do out of all of the above is try and understand the business that the application caters to.
Check out my latest book titled as First Principles Thinking: Building winning products using first principles thinking.
- Agentic Reasoning Design Patterns in AI: Examples - October 18, 2024
- LLMs for Adaptive Learning & Personalized Education - October 8, 2024
- Sparse Mixture of Experts (MoE) Models: Examples - October 6, 2024
I found it very helpful. However the differences are not too understandable for me