System design and technology selection notes — Unit 3

Implementation is the translation of the Low-Level Design (LLD) into executable code. In an academic project, this is where the theoretical architecture faces the reality of language constraints and library bugs.

⇒1.1 Technology Stack Selection

The choice of language and framework should be justified in the project report. It should not be arbitrary, but based on the project's non-functional requirements (e.g., choosing Python for machine learning due to the ecosystem, or Go for high-concurrency microservices).

Code is read far more often than it is written. Following industry-standard coding guidelines ensures that the codebase is readable, maintainable, and verifiable by the project examiner.

• Naming Conventions: Use clear, descriptive names. (e.g., `calculateTotalRevenue()` instead of `calcTr()`). Follow the language's standard (camelCase for Java/JS, snake_case for Python).
• Modularity: Functions should do exactly one thing. If a function is 200 lines long, it needs to be refactored into smaller, testable units.
• Magic Numbers: Avoid using hardcoded numbers in code. Define them as constants with descriptive names (e.g., `MAX_RETRIES = 3`).

Good code is mostly self-documenting through clear naming conventions, but comments are still essential for explaining why something is done.

⇒3.1 Commenting Rules

• Don't explain *what* the code does: If you have to write `// increments i by 1` next to `i++`, the comment is useless.
• Explain *why* the code does it: `// Using a slow bubble sort here because the array is guaranteed to be < 10 elements and memory is constrained`.
• Docstrings: Use formal documentation strings (like Javadoc or Python docstrings) for every public class and method to describe inputs, outputs, and side effects.

Academic projects often work perfectly on the 'happy path' but crash violently when given unexpected input. Industrial training teaches defensive programming.

⇒4.1 Defensive Programming

• Input Validation: Never trust user input. Validate all data at the boundaries of your system before processing it.
• Exception Handling: Use `try-catch` blocks gracefully. Do not use empty catch blocks (`catch (e) {}`) which swallow errors and make debugging impossible.
• Fail Safely: If the database connection fails, the application should return a graceful 'Service Unavailable' error to the user, not a raw stack trace containing internal IP addresses.

In industrial settings, no code reaches production without being reviewed.

⇒5.1 Linters and Formatters

Automated tools (like ESLint for JS, Pylint for Python, or Prettier) enforce coding standards automatically, ensuring the codebase looks like it was written by a single person regardless of team size.

⇒5.2 Code Reviews

Team members review each other's code to catch logical bugs, suggest architectural improvements, and share domain knowledge before the code is merged into the main branch.

• Implementation: Translating design into modular, maintainable code using an appropriate tech stack.
• Standards: Enforcing descriptive naming, avoiding magic numbers, and keeping functions small and focused.
• Commenting: Explaining the why, not the what, and utilizing formal docstrings.
• Defensive Programming: Validating inputs and handling exceptions gracefully to prevent crashes.
• Quality Assurance: Utilizing Linters and Peer Reviews to maintain high code quality across the team.