본문 바로가기
📔개발자 일기 | | TIL

[20220314] 개발자 일기& TIL

by 캔 2022. 3. 14.

몇 주간 나를 괴롭혔던 유지 보수 건이 어느 정도 마무리된 것 같다. 물론, 추가 수정사항이 있긴 했지만, 코드가 많이 깔끔해졌다. 이제는 개발 건에 전념할 수 있을 것 같아서 다행이라고 생각하고 있다.


코드 개선을 해보면서, 효율적인 작업 순서를 고민해보았다. 그리고 그것을 한번 정리해 보려고 한다.

 

웹사이트 리팩터링 혹은 코드 개선을 위한 프로세스를 생각해보았을 때, 사용자 화면(뷰, JSP, HTML 등) → 프론트엔드 코드(자바스크립트)→자바 코드 순이 되는 것이 좋을 것 같다. 물론 백엔드 개발자로서 사용자 화면의 디자인이나 퍼블리싱 요소를 직접 건드린다는 것이 아니다. 웹 사이트의 HTML이나 JSP를 다루기 위해서는 요소들의 id나 class, 태그 이름 등을 사용한다. 이런 요소들의 이름이 되는 id나 class명을 알기 쉽게 작명하거나 네이밍 컨벤션에 맞게 수정하는 게 우선이다. 결국 프론트엔드 개발에서 웹 화면을 다루기 위해서는 이런 이름들이 직관적이고 규칙성이 있어야 내가 코드를 작성할 때도 다른 사람과 함께 작업을 할 때도 편해진다. 그렇기 때문에 퍼블리셔나 디자이너가 따로 작업을 하고 있다면 그분들도 네이밍 컨벤션에 대해 숙지하고 있으면 부담이 줄어들 수 있다.

 

뷰에서 요소 이름들이 정리되고 나면 프론트엔드로 넘어갈 수 있다. 프론트엔드에서는 중복되는 코드들을 함수로 만들어서 중복 사용을 최대한 줄이는 작업을 하고 재사용성을 높일 수 있도록 로직을 짜면 코드도 줄어들고 공통된 기능을 사용하는 다른 페이지에서도 기능을 가져다가 쓸 수 있을 것이다.

 

그리고 마지막으로 자바 코드를 작성하면 된다. 내가 지난 몇 주 간 맡았던 프로젝트는 사실 백엔드에서 수행해야 할 부분들이 프론트엔드로 개발이 되어 있어서 보안적으로나 기능적으로나 불안정했던 게 사실이다. (프론트엔드를 넘어서 아예 뷰에 가격을 숨겨 놓은 정도였으니...) 특히나 결제 금액 계산과 같이 보안이나 무결성 요구되는 기능의 경우 프론트엔드에서 이뤄지면 코드가 노출될 수밖에 없으니 권장하지는 않는 것 같다. 프론트엔드에서는 시각적인 효과를 위해서나 입력 검증, 이벤트 발생 시 효과 정도로만 사용하고 비즈니스 로직은 자바 코드로 넘기자. 페이지 요청 끝난 후에 작업이 필요하다면 Ajax도 적극적으로 사용하자.

 

결국, 나는 백엔드 개발자니까 백엔드 개발에 맞도록 코드들이 정리되어야 한다고 생각한다. 뷰와 프론트엔드는 위에서 말했듯이 시각적 효과, 입력 검증, 이벤트 발생 시 처리 등 제한적으로만 사용하고 중요 비즈니스 로직은 자바 코드로 위임하는 게 중요하다.

 

마지막으로 한 번 더, 코드 개선 시 순서를 정리를 하면,

1. 특정 기능이 수정되었을 때 영향을 받는 "모든" 뷰, js, 자바 코드(컨트롤러나 서비스 등)를 조사한다.
2. 해당 뷰에서 id나 class 이름을 직관적이고 네이밍 컨벤션에 맞게 수정한다.
3. 프론트엔드에서 공통된 부분은 함수로 처리하고 로직을 효율적으로 작동하도록 수정한다.
4. 핵심적인 비즈니스 로직은 뷰나 프론트엔드가 아닌 자바 코드로 이관해준다. 그러고 나서 자바 코드를 개선한다.

'📔개발자 일기 | | TIL' 카테고리의 다른 글

[20220317] 개발자 일기&TIL  (0) 2022.03.17
[20220316] 개발자 일기 & TIL  (0) 2022.03.16
[20220311] 개발자일기 & TIL  (0) 2022.03.11
[20220310] 개발자 일기 & TIL  (0) 2022.03.10
[20220309] TIL  (0) 2022.03.09