CSC/ECE 517 Spring 2024 - E2443 Reimplement grades controller: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
mNo edit summary
Line 18: Line 18:
==Plan for Reimplementation of GradesController==
==Plan for Reimplementation of GradesController==


==== Enhancing Code Clarity: ====
*Rename ambiguous methods: Identify and rename methods like `review_grades`, `penalties`, and `make_chart` to reflect their specific functionalities.
*Add comments: Document complex logic within methods like `action_allowed?`, `view_my_scores`, and `view_team` to improve understanding for future developers.
*Simplify loops: Optimize loops within methods like `populate_view_model` and `make_chart` for better readability and performance.


==== Removing Unused Methods: ====  
====Code Clarity:====
*Identify unused methods: Analyze the codebase to find methods like `instructor_review` and `assign_all_penalties` that are no longer being called.
*Remove redundant code: Eliminate redundant methods to reduce complexity, such as `list_questions` which duplicates functionality already present in `retrieve_questions`.
*Update dependencies: Ensure that any removed methods do not impact other parts of the application and update references accordingly.


==== Refactor Action Allowed Logic: ====
Existing methods such as <code>view</code>, <code>view_my_scores</code>, and <code>view_team</code> will undergo refinement to improve clarity and readability. This includes adding inline comments within complex methods to provide better understanding. Additionally, loops within <code>populate_view_model</code> and <code>make_chart</code> will be streamlined for improved performance, while conditional statements within <code>action_allowed?</code> will be simplified for easier comprehension.
*Simplify conditionals: Revisit the `action_allowed?` method and simplify conditionals by extracting complex checks into separate helper methods.
*Separate concerns: Extract logic related to authorization checks into separate methods, such as `student_privileges_allowed?`, `ta_privileges_allowed?`, etc.
*Improve error handling: Enhance error messages within the `action_allowed?` method to provide clear feedback to users when access is denied.


==== Consolidate Helper Modules: ====  
====Authorization Logic:====
*Identify common functionality: Identify helper modules like `PenaltyHelper` and `GradesHelper` with overlapping functionality.
*Merge similar modules: Consolidate related helper methods into a single module (e.g., `GradingHelper`) to reduce redundancy and improve organization.
*Update references: Update references to consolidated modules throughout the codebase to ensure consistency and maintainability.


==== Streamline View Methods: ====
Authorization logic within controller actions will be refined to simplify the process and improve error handling. This involves extracting authorization concerns into separate methods like <code>student_privileges_allowed?</code>, <code>ta_privileges_allowed?</code>, etc. Furthermore, error messages within <code>action_allowed?</code> will be enhanced to provide clearer feedback to users in case of access denial.
*Simplify view logic: Refactor view methods like `view`, `view_my_scores`, and `view_team` to remove unnecessary complexity and improve readability.
*Reduce dependencies: Minimize dependencies within view methods by extracting reusable logic into helper methods and partials.
*Optimize database queries: Review database queries within view methods and optimize them for performance where possible by eager loading associations and minimizing N+1 queries.


==== Update Edit and Update Actions: ====  
====View Method Optimization:====
*Adhere to RESTful conventions: Ensure that edit and update actions follow RESTful conventions by renaming them to `edit` and `update`.
*Simplify parameter handling: Streamline parameter handling within edit and update actions to reduce complexity and improve clarity, avoiding redundant checks.
*Implement error handling: Enhance error handling within edit and update actions to handle invalid input gracefully and provide informative error messages to users.


==== Optimize Chart Generation: ====
In view methods like <code>view</code>, <code>view_my_scores</code>, and <code>view_team</code>, efforts will be made to streamline code and reduce dependencies. This includes optimizing database queries to improve performance and removing redundant code to enhance maintainability.  
*Improve chart rendering: Optimize the generation of charts and bar charts within the `make_chart` method by caching precomputed data and utilizing efficient charting libraries.
*Cache chart data: Implement caching mechanisms to store precomputed chart data and minimize redundant calculations, improving performance and responsiveness.
*Utilize client-side rendering: Explore options for offloading chart rendering to the client side using JavaScript libraries like Chart.js to improve scalability and responsiveness.


==== Enhance Self-Review Logic: ====  
====Edit and Update Actions:====
*Review self-review workflow: Evaluate the current self-review logic for accuracy and reliability, ensuring that all edge cases are handled correctly.
*Address edge cases: Identify and address edge cases where self-review completion may not be accurately detected, updating the logic as necessary to ensure consistency.
*Improve user feedback: Enhance feedback messages within the `self_review_finished?` method to guide users through the self-review process more effectively and provide clear instructions.


==== Improve Redirect Logic: ====
Edit and update actions such as <code>edit</code> and <code>update</code> will be enhanced to adhere to RESTful conventions. Specifically, parameter handling will be simplified to ensure consistency and robust error handling will be implemented to gracefully handle invalid input.
*Refactor redirect logic: Simplify and consolidate logic within the `redirect_when_disallowed` method for better maintainability and readability.
*Enhance error handling: Improve error handling within the `redirect_when_disallowed` method to handle unexpected scenarios gracefully, providing informative feedback to users.
*Optimize redirection: Streamline redirection logic to minimize unnecessary redirects and improve user experience, ensuring that users are directed to the appropriate pages based on their permissions.


==== Comprehensive Testing with RSwag: ====  
====Chart Generation Optimization:====
*Write RSwag tests: Develop comprehensive RSwag tests for every controller method, covering both positive and negative test cases, including edge cases and boundary conditions.
 
*Automate testing: Integrate automated testing into the CI pipeline to execute RSwag tests automatically on each code commit, ensuring consistent and reliable test coverage.
Chart generation methods will be optimized to improve efficiency and scalability. This includes implementing caching mechanisms for precomputed data within <code>make_chart</code> to enhance responsiveness. Additionally, exploration of client-side rendering using JavaScript libraries like Chart.js will be considered to further improve performance.
*Test coverage: Ensure that all endpoints and functionalities are thoroughly tested using RSwag, verifying that the API behaves as expected and adheres to the specified requirements.
 
====Self-Review Logic Enhancement:====
 
Self-review logic within <code>self_review_finished?</code> will undergo validation to ensure accuracy and effectiveness. This includes refining edge cases where self-review completion may not be accurately detected and enhancing user guidance for a smoother experience.
 
====Redirection Logic Improvement:====
 
Redirection logic within <code>redirect_when_disallowed</code> will be improved to simplify and consolidate redirection processes. This involves enhancing error handling to provide clearer feedback to users and optimizing redirection logic to minimize unnecessary redirects.
 
====Comprehensive Testing with RSwag:====
 
Comprehensive testing with RSwag will be conducted to validate API endpoints and ensure thorough test coverage. This includes writing tests for each controller method, covering both positive and negative test cases, and integrating automated testing into the CI pipeline for consistency and reliability.


== Design Principles ==
== Design Principles ==

Revision as of 18:44, 8 April 2024

Expertiza

Expertiza is an open-source web application built on Ruby on Rails that enables instructors to create customized assignments with topic lists for students to choose from. It facilitates team formation, allowing students to collaborate on assignments and projects. Expertiza supports peer review processes where students can provide feedback on each other's submissions across various document formats, including URLs and wiki pages. This freely available platform provides a flexible and comprehensive solution for managing assignments, teamwork, and peer evaluations.

Introduction

We're refactoring the grades_controller.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes thorough rswag testing of the grades_controller method and demonstrating Swagger UI integration.

Problem Statement

The reimplementation project entails:

  1. Refactoring Grades Controller: Enhancing code clarity, optimizing loops, and adding comments for unclear lines of code to improve maintainability and readability.
  2. Removing Redundant Methods: Identifying and eliminating unused methods in the controller to reduce complexity and streamline functionality.
  3. CRUD Operations: Implementing CRUD operations (Create, Read, Update, Delete) in the controller for efficient data management.
  4. Adherence to DRY Principle: Ensuring that the reimplementation follows the Don't Repeat Yourself (DRY) principle to avoid duplication and improve code efficiency.
  5. Testing with RSwag: Writing comprehensive tests using RSwag for each controller method to ensure functionality and integration with Swagger UI, followed by a video demonstration showcasing the Swagger UI integration and functionality of the reimplemented controller.

Plan for Reimplementation of GradesController

Code Clarity:

Existing methods such as view, view_my_scores, and view_team will undergo refinement to improve clarity and readability. This includes adding inline comments within complex methods to provide better understanding. Additionally, loops within populate_view_model and make_chart will be streamlined for improved performance, while conditional statements within action_allowed? will be simplified for easier comprehension.

Authorization Logic:

Authorization logic within controller actions will be refined to simplify the process and improve error handling. This involves extracting authorization concerns into separate methods like student_privileges_allowed?, ta_privileges_allowed?, etc. Furthermore, error messages within action_allowed? will be enhanced to provide clearer feedback to users in case of access denial.

View Method Optimization:

In view methods like view, view_my_scores, and view_team, efforts will be made to streamline code and reduce dependencies. This includes optimizing database queries to improve performance and removing redundant code to enhance maintainability.

Edit and Update Actions:

Edit and update actions such as edit and update will be enhanced to adhere to RESTful conventions. Specifically, parameter handling will be simplified to ensure consistency and robust error handling will be implemented to gracefully handle invalid input.

Chart Generation Optimization:

Chart generation methods will be optimized to improve efficiency and scalability. This includes implementing caching mechanisms for precomputed data within make_chart to enhance responsiveness. Additionally, exploration of client-side rendering using JavaScript libraries like Chart.js will be considered to further improve performance.

Self-Review Logic Enhancement:

Self-review logic within self_review_finished? will undergo validation to ensure accuracy and effectiveness. This includes refining edge cases where self-review completion may not be accurately detected and enhancing user guidance for a smoother experience.

Redirection Logic Improvement:

Redirection logic within redirect_when_disallowed will be improved to simplify and consolidate redirection processes. This involves enhancing error handling to provide clearer feedback to users and optimizing redirection logic to minimize unnecessary redirects.

Comprehensive Testing with RSwag:

Comprehensive testing with RSwag will be conducted to validate API endpoints and ensure thorough test coverage. This includes writing tests for each controller method, covering both positive and negative test cases, and integrating automated testing into the CI pipeline for consistency and reliability.

Design Principles

Single Responsibility Principle (SRP):

  • Each action in the GradesController will be responsible for a specific task related to managing grades.
  • Actions will be refactored to separate concerns such as data retrieval, computation, and view rendering.
  • For example, the `view` action will focus solely on retrieving grading data and rendering the grading report.

Don't Repeat Yourself (DRY) Principle:

  • Code duplication in the GradesController will be eliminated by extracting common functionality into helper methods or modules.
  • Repetitive logic, such as retrieving questions or calculating penalties, will be refactored to promote code reusability and maintainability.

Encapsulation:

  • Data and behavior within the GradesController will be encapsulated within appropriate methods and classes to minimize dependencies.
  • Access to instance variables and controller actions will be limited, promoting encapsulation and separation of concerns.

Dependency Inversion Principle (DIP):

  • The GradesController will depend on abstractions, interfaces, or higher-level modules instead of concrete implementations.
  • Dependency injection or inversion of control will be used to decouple the controller from specific database or service implementations.

Testing with RSwag:

Integration Testing:

  • Integration tests using RSwag will be written to verify the behavior of each controller action, including `view`, `view_my_scores`, and `view_team`.
  • CRUD operations (Create, Read, Update, Delete) will be tested to ensure proper data management and interaction with the database.

Swagger UI Integration:

  • RSwag will be integrated with Swagger UI to provide a user-friendly interface for interacting with API endpoints.
  • Swagger UI will accurately reflect the API documentation and allow users to test endpoints interactively.

Parameter Validation:

  • Endpoint parameters, such as assignment IDs and participant IDs, will be tested with various input values to ensure proper handling and error reporting.
  • Input parameters such as IDs, query parameters, and request bodies will be validated to ensure data integrity.

Error Handling:

  • Error handling scenarios, including validation errors, resource not found, unauthorized access, and server errors, will be tested.
  • Error responses will contain appropriate status codes, error messages, and error details as per the API contract.

Security Testing:

  • API endpoints will be assessed for vulnerabilities such as SQL injection, cross-site scripting (XSS), and sensitive data exposure.
  • Authentication and authorization mechanisms will be evaluated for effectiveness to ensure secure access to grading functionalities.

Performance Testing:

  • Performance of API endpoints under various load conditions will be evaluated using tools like JMeter or Gatling.
  • Response times, throughput, and resource utilization will be measured to identify performance bottlenecks and optimize critical paths.

Documentation Verification:

  • API documentation generated by RSwag will be validated to accurately reflect implemented endpoints, parameters, and responses.
  • Documentation will be kept up-to-date and aligned with the behavior of API endpoints.

By following these design principles and testing strategies, the reimplementation of the GradesController will result in a well-designed, maintainable, and thoroughly tested component, meeting project requirements effectively.

Team

Mentor
  • Kashika Malick
Members
  • Sravya Yepuri (syepuri@ncsu.edu)
  • Hasini Chenchala (hchench@ncsu.edu)
  • Chirag Hegde (chegde@ncsu.edu)
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2443_Reimplement_grades_controller&oldid=155026"