Refactoring Poor Spring MVC Code: Lessons on Clean Backend Development

The author presents what they consider the worst Spring MVC code they have seen, starting with a convoluted

@PostMapping("/add") public void addConfig(HttpServletRequest request, HttpServletResponse response) { ... }

controller that mixes HTTP handling, JSON serialization, and business logic in a single method.

Next, the accompanying service method

public String add(HttpServletRequest request) { Map<String,Object> data = new HashMap<>(); try { String name = request.getParameter("name"); String value = request.getParameter("value"); long newID = add(name, value); data.put("code",0); data.put("newID",newID); } catch (CheckException e) { data.put("code",-1); data.put("msg",e.getMessage()); } catch (Exception e) { logger.error("add config error",e); data.put("code",99); data.put("msg",e.toString()); } return JSONObject.toJSONString(data); }

illustrates several anti‑patterns: direct request parsing, manual error‑code handling, and excessive try‑catch blocks.

The author argues that such code stems from bad coding habits and a lack of clear project‑wide standards, leading to duplicated logic, difficult debugging, and frequent regressions. They emphasize that coding style and conventions are often more important than the specific technologies used.

To address these issues, the author proposes establishing a shared code framework and coding guidelines. After adopting the new framework, a simplified delete endpoint is shown:

@PostMapping("/delete") public ResultBean<Boolean> delete(long id) { return new ResultBean<>(configService.delete(id)); }

This version relies on AOP and a generic ResultBean wrapper, eliminating boilerplate response handling and centralizing cross‑cutting concerns.

The article concludes that even simple techniques like AOP and consistent response objects can dramatically reduce code volume, improve maintainability, and free developers to focus on learning new technologies rather than rewriting repetitive CRUD logic.