백엔드 로직 중복 제거와 엣지 케이스 처리로 시스템 안정성 강화
목차
전체 시스템 최종 검증 결과
이번 작업의 핵심은 기존 기능 안정화와 코드 일관성 확보였음. 변경 범위가 여러 레이어에 걸쳐있어서 영향 범위를 꼼꼼히 체크했음.
변경 영역
| 레이어 | 파일 수 | 주요 변경 |
|---|---|---|
| 백엔드 로직 | 6개 | 핵심 처리 로직 개선 |
| 화면 (JSP) | 0개 | UI/UX 개선 |
| 쿼리 (XML) | 0개 | SQL 최적화 |
| 스타일 | 0개 | CSS 정리 |
작업 포인트
- 중복 코드 제거 및 공통화
- 엣지 케이스 처리 보강
- 로그 및 에러 메시지 개선
- 불필요한 주석/코드 정리
코드 변경 원칙
운영 중인 서비스 변경 시 가장 중요한 건 기존 동작을 깨지 않는 것임. 변경 전후 동작을 직접 확인하고, 배포 후 모니터링을 잊지 말아야 함.
개발 원칙 정리
이 작업을 진행하면서 재확인한 원칙들:
작은 커밋: 변경 단위를 작게 유지해서 코드 리뷰와 롤백이 쉽게.
테스트 먼저: 변경 전 현재 동작을 파악하고, 변경 후 동일하게 동작하는지 확인.
문서 동기화: 코드가 바뀌면 관련 주석과 문서도 같이 업데이트.
| 원칙 | 이유 |
|---|---|
| 단일 책임 | 하나의 함수/클래스는 하나의 역할만 |
| 명시적 코드 | 영리한 코드보다 읽기 쉬운 코드 |
| 실패 우선 처리 | happy path보다 에러 케이스 먼저 설계 |
작업 회고
이런 작업들이 쌓이면서 시스템이 점점 견고해진다는 걸 느낌. 당장 티가 안 나는 작업이지만 나중에 디버깅 시간을 크게 줄여줌.
코드를 작성할 때 항상 생각하는 것들:
- 미래의 나: 6개월 후에 이 코드를 다시 봤을 때 이해할 수 있는가
- 다음 개발자: 나 말고 다른 사람이 이 코드를 보면 어떻게 느낄까
- 운영 상황: 새벽 3시에 장애가 났을 때 이 코드가 문제를 빨리 파악하게 해주는가
| 좋은 코드의 기준 | 나쁜 코드의 신호 |
|---|---|
| 읽으면 의도가 바로 보임 | 주석 없으면 이해 불가 |
| 변경이 한 곳에만 영향 | 한 곳 바꾸면 여러 곳 수정 필요 |
| 테스트 작성이 자연스러움 | 테스트하려면 구조 바꿔야 함 |
끝
댓글 0
첫 댓글 달아줘.