I started by placing breakpoints in the front-end code, specifically focusing on parts dealing with fetching and posting comments. These breakpoints serve as critical inspection points, allowing me to closely monitor the execution process, from sending requests to the server to displaying the fetched comments. I also placed a breakpoint in the backend API controller for the comment functionality. The breakpoint was specifically placed next to the lines of code that handled how the ArrayList was stored with the comments for a specific game.
I then initiated the backend, clicking run and debug, and started the frontend by clicking play. After clicking through the frontend a few times, we can see the variables in the text editor itself, without having to print to console. It depicts the "Current" game name being populated with comments. Then, clicking continue in the backend, and clicking continue in the frontend, we see the comments loaded in in frontend page.
Summary/Reflection: Setting breakpoints throughout the front-end and back-end code proved invaluable for gaining insights into the inner workings of our comment feature, showcasing the effectiveness of interactive debugging. This approach eliminated the need for console output by allowing direct observation of variable states and control flow within the IDE. The ability to halt the execution at key points and examine the live data helped me understand the integration between the two ends of our application more deeply. Overall, this method of debugging not only facilitated a more efficient problem-solving process but also enhanced my grasp of how different parts of the codebase interact in real-time.
I started by placing breakpoints in the front-end code, specifically focusing on parts dealing with fetching and posting comments. These breakpoints serve as critical inspection points, allowing me to closely monitor the execution process, from sending requests to the server to displaying the fetched comments. I also placed a breakpoint in the backend API controller for the comment functionality. The breakpoint was specifically placed next to the lines of code that handled how the ArrayList was stored with the comments for a specific game.
I then initiated the backend, clicking run and debug, and started the frontend by clicking play. After clicking through the frontend a few times, we can see the variables in the text editor itself, without having to print to console. It depicts the "Current" game name being populated with comments. Then, clicking continue in the backend, and clicking continue in the frontend, we see the comments loaded in in frontend page.
Summary/Reflection: Setting breakpoints throughout the front-end and back-end code proved invaluable for gaining insights into the inner workings of our comment feature, showcasing the effectiveness of interactive debugging. This approach eliminated the need for console output by allowing direct observation of variable states and control flow within the IDE. The ability to halt the execution at key points and examine the live data helped me understand the integration between the two ends of our application more deeply. Overall, this method of debugging not only facilitated a more efficient problem-solving process but also enhanced my grasp of how different parts of the codebase interact in real-time.