Backend Checklist
This chapter defines the detailed checklist for the backend area of TQS-S/W certification. The backend checklist consists of 6 areas: development environment, Java code conventions, Spring Boot, database, build, and file upload. Each item is classified as mandatory (O), recommended (R), or optional (S), with the verification method specified.
32.2.1. Development Environment
The development environment checklist verifies that the project team has correctly configured the standard development environment defined in TQS specifications.
| No. | Item | Classification | Verification Method |
|---|---|---|---|
| 1 | VSCode is used as the standard IDE | O | Configuration file verification |
| 2 | .vscode/settings.json is included in the project for sharing | O | File existence verification |
| 3 | Required extensions are defined in .vscode/extensions.json | O | File existence and content verification |
| 4 | .editorconfig file is included in the project root | O | File existence verification |
| 5 | Java 21 is used as the runtime | O | Verify java.version in pom.xml |
| 6 | Node.js LTS version is used | O | Verify .nvmrc file |
Development environment items are elements that constitute the project's basic infrastructure. Configuration files must be included in the version control system so that all team members can work in an identical development environment.
32.2.2. Java Code Conventions
The Java code conventions checklist verifies the consistency and readability of source code.
| No. | Item | Classification | Verification Method |
|---|---|---|---|
| 7 | Google Java Format is applied via spotless-maven-plugin | O | Verify mvn spotless:check execution results |
| 8 | Formatter violation count is 0 | O | Build log verification |
| 9 | Class names use PascalCase | O | Code review |
| 10 | Method names and variable names use camelCase | O | Code review |
| 11 | Constant names use UPPER_SNAKE_CASE | O | Code review |
| 12 | Package names use only lowercase letters | O | Code review |
| 13 | Feature-based package structure is applied (layer-based package structure is not used) | O | Directory structure verification |
| 14 | Magic numbers are not used; constants are defined instead | R | Code review |
| 15 | The final keyword is used for immutable variables | R | Code review |
| 16 | Method line count is maintained at 30 lines or fewer | R | Code review |
| 17 | Unnecessary comments are avoided (self-explanatory code is prioritized) | R | Code review |
Code conventions directly impact project maintainability. Google Java Format must be integrated into the build process for automatic verification.
32.2.3. Spring Boot
The Spring Boot checklist verifies the correct usage of the framework and application of standard configurations.
| No. | Item | Classification | Verification Method |
|---|---|---|---|
| 18 | Spring Boot 3.x version is used | O | Verify spring-boot-starter-parent version in pom.xml |
| 19 | Configuration files are separated by profile (local / dev / staging / prod) | O | Verify existence of application-{profile}.yml files |
| 20 | @ConfigurationProperties is used for type-safe configuration management | R | Code review |
| 21 | @RestControllerAdvice is used to implement global exception handling | O | Code verification |
| 22 | Error codes are defined and managed as Enums | O | Code verification |
| 23 | SLF4J is used for logging (no System.out.println usage) | O | Code search (System.out search returns 0 results) |
| 24 | Log levels are appropriately configured per environment | O | Configuration file verification |
| 25 | @Transactional scope is limited to the service layer | R | Code review |
| 26 | Controllers do not contain business logic | O | Code review |
Spring Boot configuration and structure have a critical impact on project stability and operational convenience. Profile separation and global exception handling must be applied.
32.2.4. Database
The database checklist verifies the standard implementation of the data access layer and schema management system.
| No. | Item | Classification | Verification Method |
|---|---|---|---|
| 27 | PostgreSQL is used as the database | O | Verify datasource configuration in application.yml |
| 28 | jOOQ is used as the data access layer (JPA / Hibernate is not used) | O | Verify dependencies in pom.xml |
| 29 | Flyway is used to manage database migrations | O | Verify dependencies in pom.xml and migration files |
| 30 | jOOQ codegen is integrated into the Maven build | O | Verify jooq-codegen-maven plugin in pom.xml |
| 31 | HikariCP connection pool is configured | O | Verify HikariCP configuration in application.yml |
| 32 | Table names and column names use snake_case | O | DDL file verification |
| 33 | Flyway migration file naming conventions are followed (V{version}__{description}.sql) | O | Migration file name verification |
| 34 | Index naming conventions are followed (idx_{table}_{column}) | R | DDL file verification |
The database area verifies the correct application of the TQS specification's core technology stack: PostgreSQL + jOOQ + Flyway. Projects using JPA or Hibernate are judged as non-compliant for mandatory items.
32.2.5. Build
The build checklist verifies Maven build configuration standards compliance and quality tool integration.
| No. | Item | Classification | Verification Method |
|---|---|---|---|
| 35 | pom.xml follows the TQS standard structure | O | File structure verification |
| 36 | Java 21 configuration is specified in maven-compiler-plugin | O | Verify plugin configuration in pom.xml |
| 37 | JaCoCo plugin is configured to measure coverage | O | Verify jacoco-maven-plugin in pom.xml |
| 38 | JaCoCo line coverage threshold is set to 80% or above | O | JaCoCo report verification |
| 39 | JaCoCo branch coverage threshold is set to 70% or above | O | JaCoCo report verification |
| 40 | OWASP Dependency-Check plugin is configured | R | Verify plugin in pom.xml |
| 41 | OWASP scan results show 0 vulnerabilities with CVSS 7 or above | R | Scan report verification |
| 42 | maven-surefire-plugin is configured to integrate tests into the build | O | Verify plugin in pom.xml |
The build configuration serves as the project's quality gate. JaCoCo coverage thresholds and OWASP dependency scanning are essential tools for automatically verifying code quality and security.
32.2.6. File Upload
The file upload checklist verifies the security of file upload functionality and storage management practices.
| No. | Item | Classification | Verification Method |
|---|---|---|---|
| 43 | Upload file extensions are validated using a whitelist approach | R | Code review |
| 44 | Upload file MIME types are validated on the server side | R | Code review |
| 45 | Upload file size is restricted | R | Configuration file verification |
| 46 | Storage directory structure conforms to TQS standards | R | Configuration file and directory structure verification |
| 47 | Uploaded file names are converted to UUIDs or similar before storage | R | Code review |
File upload is an area where security vulnerabilities are prone to occur. It is recommended to apply a dual validation approach that verifies both extension and MIME type.
32.2.7. Item Summary
The total number of items and distribution by classification for the backend checklist are as follows.
| Area | Mandatory (O) | Recommended (R) | Optional (S) | Total |
|---|---|---|---|---|
| Development Environment | 6 | 0 | 0 | 6 |
| Java Code Conventions | 7 | 4 | 0 | 11 |
| Spring Boot | 7 | 2 | 0 | 9 |
| Database | 7 | 1 | 0 | 8 |
| Build | 6 | 2 | 0 | 8 |
| File Upload | 0 | 5 | 0 | 5 |
| Total | 33 | 14 | 0 | 47 |
The backend checklist consists of a total of 47 items. All 33 mandatory items must be met to obtain Basic certification, and the compliance rate of the 14 recommended items determines whether the Advanced or Premier certification grade is achieved.