카테고리 없음

개발 일기 - 좋게 바꾼게 모두에게 좋을까?

bemaru 2022. 1. 14. 23:09
반응형

 

 

웹에 있는 소프트웨어 버전정보를 수집하는 간단한 스크래핑 python 스크립트가 있다.

 

이 스크립트는 몇 가지 소프트웨어 목록에 대해 스크래핑을 수행하는데

 

개발하다보니 각 소프트웨어 목록들의 정보 수집을 위해 공통된 요소를 갖게 됨을 볼 수 있었다.

 

  • 고정된 URL 주소
  • 스크래핑 파서의 selector path
  • 파싱된 내용에서 원하는 내용만 추출하기 위한 regex(정규식)

이 데이터는 DB 테이블에 저장해서 사용하는 방식으로 개선되었다.

 

이전에는 파싱 규칙들이 소스코드에 하드코딩되어 있어 난잡해보였던것에 비해

DB에 저장되니 소스코드도 깔끔해지고 DB를 통해 구조적으로 확인하고 수정할 수 있어서 좋았다.

 

 

하지만, 당장 소스코드는 깔끔해질지 몰라도 형상 관리 측면에서 좋진 않았다.

 

웹페이지 내용이 변경되면 스크래퍼의 파싱 규칙을 수정해야한다.

 

즉, DB테이블에 저장된 파싱 규칙 (주로 selector path) 를 수정해야하는데

 

DB를 수정하고 커밋하게 되면
(여기서 말하는 DB는 PC로컬에 저장되는 sqlite db이며 해당 DB file을 commit하는 구조, 일반적으로 RDBMS를 사용하는 방식과 도메인 특성상 다른 부분이긴함...)

 

git revision에서 변경 사항에 대해 확인할 수 없게 되는 단점이 있다.

 

 

요약해보면, 소스코드의 개선을 위해 특정 데이터를 DB에 저장했지만, 결국 유지보수 측면에서 손해보는 부분이 생긴것이다. 이렇듯 시점별 작업자 ( 굳이 따지자면 초기 개발자와 유지보수하는 개발자 )의 관점 과 입장에 따라 좋은게 좋은게 아니게 되는 상황이 발생하기도한다.

 

처음엔 항상 모든걸 간결하게 만드는게 답인줄 알았지만, 현실을 그렇지 않다. 답답해이고 이해가 안되는 방식이라도 나름의 이유가 있는 것들이 있기도하다. ( 하지만, 대부분 구린내가 나면 문제가 있는게 맞긴하다..ㅎㅎ )

 

 

 

 

반응형