잉여개발자

[리팩토링] (3) early-return 적용하기

배경 복잡한 if-else  중첩 구조에 대한 수정  과정👉 리팩토링 전 - api.py 의 함수에 다음과 같은 조건문이 적혀있었고, 유지보수와 이해(가독성)에 매우 어려움이 존재# 리팩 전if a: if b: if c: return '성공' else: raise ApiError(에러c) else: raise ApiError(에러b)else: raise ApiError(에러a) 👉 리팩토링 후- 부정 문으로 상위 조건인 경우 return(raise)를 진행함 . early-return 을 통해 가독성 개선# 리팩 후if not a: raise ApiError(에러a)if not b: raise ApiError(에러b)if n..

배경몇달간의 프로젝트를 진행 후에,서로 다른 코드 스타일, 모듈들의 역할에 대해 상이하게 생각한 부분 등의 문제점들이 발견되었고,2주 간의 리팩토링을 진행하는 시간을 가지게 되었다. 다음 글에서는 리팩토링을 진행 하면서, '가독성 높이기 - 함수명 개선' 에 대한 경험을 공유 하려 한다. 가장 큰 목적은 여럿이서 작성한 다양한 함수명 틀을, 조금이나마 비슷하게 맞춰 가독성을 높이는데 중점을 두었다. 함수명 개선 간 나름 정한 규칙은 다음과 같다- Service Class 명도 해당 함수에 같이 의미 해석 된다.- check, validate, in 등의 비슷한 결의 함수명을 가지게 함 사례 1 - 함수명 개선 하기👉 변경 전 코드## 변경 전 코드# main.pyUserService.update_use..

배경몇달간의 프로젝트를 진행 후에,서로 다른 코드 스타일, 모듈들의 역할에 대해 상이하게 생각한 부분 등의 문제점들이 발견되었고,2주 간의 리팩토링을 진행하는 시간을 가지게 되었다. 다음 글에서는 리팩토링을 진행 하면서, '공통 코드를 줄이는 것' 에 대한 경험을 공유 하려 한다. 과정👉 리팩토링 전 프로젝트 구조router/ : api 및 service/ return 값에 따른 error handling 수행service/ : 비즈니스 로직 작성 및 결과에 따른 return 성공 여부 반환즉 router에서 service 로직을 호출하여 수행하다가, 성공 여부를 router로 반환해, 핸들링 된 에러로 유저에게 응답하는 방식초기에 이렇게 작성했던 이유는 api 별로 error 흐름을 파악하기 쉽다. ..