Comprehensive Guide to Development Process and Review Practices

Overview

Readers of the previous article "What Do Front‑line Technical Managers Actually Manage?" wanted more concrete guidance, so this piece shares a complete development‑process specification aimed at improving product quality and optimizing workflow.

1. Requirement Review

Common problems in requirement meetings include passive participants, heated debates, and divergent discussions that stray from the goal. To avoid these, participants should prepare by asking three key questions before the review:

What problem does this solve?

Which metrics will it improve?

What is the business value?

After the product manager releases the prototype and PRD drafts, developers should spend 1‑2 days familiarising themselves with the documents and raise any questions through the development manager.

Developers and the development manager then confirm technical choices (frameworks, middleware, databases), architecture, potential technical difficulties, performance bottlenecks, upstream/downstream interactions, and module breakdown.

The agreed technical solution is documented in a design package that includes overall design , summary design , detailed design , and interface design .

During the Review

Developers must attend, raise unclear requirements on the spot, and may suggest product improvements. Typically at least two rounds of review (draft and final) are held.

After the Review

Any needed updates to technical documents should be made promptly. The development manager evaluates team capacity and project priority, then schedules work based on the design documents.

2. Technical Review

Technical design is critical; developers must treat it seriously.

The technical review focuses on:

System relationship diagram , module relationship diagram , and process flow diagram (drawn with any preferred tool).

Interface design – ensure compatibility, extensibility, and naming conventions.

Database design – follow database design standards and maintain a change‑log document.

Detailed design – adhere to project directory conventions for shared classes and methods.

During the Review

Developers and the development manager must attend; architects join for overall/summary design discussions, and DBAs join when database changes are involved.

After the Review

Update scheduling documents as needed and reply to the schedule via a standardized email template.

3. Requirement Development

Coding

Developers follow team coding standards and the approved design, paying attention to encapsulation, maintainability, and extensibility. Any required changes to the technical solution must be approved by the development manager.

Code Review

Code should be submitted in small, frequent increments; reviewers must provide feedback within 24 hours. Review focuses on conformity to coding standards, robustness, security (SQL injection, XSS, SSRF, CSRF, privilege escalation, file upload), and performance (caching, connection pooling).

Integration Testing

Developers proactively drive integration testing and notify the technical manager when obstacles arise.

Self‑Testing

After integration, developers complete self‑testing and send a standardized self‑test report to the QA team; performance‑critical projects also produce a performance test report.

Test Submission

Once self‑testing passes, developers request testing via a standard email template and deploy to the test environment using the operations team’s release procedure.

4. Follow‑up Testing

Test Case Review

Developers attend to ensure alignment between test and development interpretations of requirements.

Bug Fixing

Developers monitor the bug list, fix issues promptly, and inform the development manager of any schedule risks.

5. Follow‑up Deployment

Developers confirm all bugs are closed, product owners approve the test‑environment release, then coordinate dependencies, rollout order, and rollback plans before deploying to production using the operations team’s release method.

After production deployment, a standardized “deployment complete” email is sent to product and test teams, and developers monitor for post‑release issues, notifying the development manager immediately.

6. Post‑Production Incident Review

If bugs surface after a period in production, a structured retrospective template should be used to analyse root causes and enforce corrective measures.

Conclusion

While developers value creativity, most routine work benefits from disciplined processes and strict adherence to standards to ensure quality and collaboration across teams.