[개발생각] 시스템의 정리 - 코드 컨벤션과 분류

요즘은 좀 집착하는게 있다, 컨벤션과 분류라고 해야할까?

 

현재 진행하는 프로젝트가 아무래도 오래된 년차가 있는 시스템을 신규로 개발을 해야하는 프로젝트다보니,

기존의 레거시 시스템을 우선적으로 파악해야하는 경우가 많다.

(레거시를 파악하고 이해해야, 신규 시스템도 만들수있으니)

 

여기서 어려운점이 무엇이었냐하면 (아직 프로젝트는 끝나지 않았지만..ㅎ)

기존의 시스템,서버들, 즉 인스턴스들의 분류가 명확하지 않고, 관리가 잘안되는 느낌이었다.

인스턴스들이 동작하고 있는 정보를 한눈에 볼수가 없고, 파편화되여, 여러서버들에 인스턴스가 떠있는 느낌이 들었다.

따라서 명시적으로 어떤 기능이 어떤 서버에 몇개의 인스턴스로 동작하는지를 파악하는게 어려웠고,

파악을 하더라도, 이게 정확한것인지를 확신하기가 어렵다는 것이였다.

 

이부분을 개선하기위해서,

인스턴스서버들을 한곳에서 볼수있도록 구성을 해야겠다고 생각했다.

특히, 배치서버들이 너무 베일에 감춰진 느낌이 컸기때문에, 해당 배치서버들을 Airflow 스케줄러쪽으로 모았다.

모음과 동시에, 해당 인스턴스들의 기능과 역할에 따라 분류를 다시 했고,

비슷한 일, 역할을 하는 놈들끼리를 그룹핑하여 관리하도록 구성했다.

(이런 정리된 내용을 위키등에 정리하는것과는 별개로, 시스템내에 명기하는 방법을 생각함으로써, 좀더 최신의 데이터라는 느낌을 주도록 고민했다)

개인적인 편견일수도있지만, 위키내용은 뭔가 믿음이 안간다...

이거 관리가 되는 페이지인가??를 매번 생각하게 되서...ㅎㅎ

 

이런 고민은 아래와 같이 해결했다.

Airflow에는 스케줄을 등록할때는 (DAG등록) 한글로 Job타이틀을 등록하여 관리하도록 룰을 정했고,

해당 잡의 성격을 알수있는 표준화된 태그를 추가하여,

어떤 성격의 기능인지를 더 명시적으로 파악할수있도록 하였다.

 

예)

 

[배치] 유저탈퇴시 배치처리_#1
#exe_crontab, #src_kafka 

 

 

위의 의미는 '유저탈퇴시 배치처리하는 잡으로 #1 첫번째 잡이라는 뜻'

#을 통해 첫번째잡, 두번째잡으로 표시한것은 배치를 샤딩해서 여러개를 구동할수있기에,

해당 샤딩 인스턴스를 표시하기 위한 룰로 정했다.

그리고 태그의 exe_crontab는 실행방법은 크론탭 스케줄링으로 동작한다는 의미이며,

src_kafka 태그는 해당 트리거는 kafka큐를 통해 트리거된다는 의미이다.

이렇게 표준화된 태그들을 여러개 정의하고 만들어, 태그를 추가하여 해당 잡의 성격을 태그로 파악할수있게 했다.

 

이렇게 잡의 한글 타이틀명과 태그를 잘정리해서 잡을 등록해두면,

처음 접하는 신입 개발자라도 충분히 해당잡의 특성과 역할등을 쉽게 알수있을것이다.

 

 

두번째 개선 포인트는 아래와 같다.

 

레거시 시스템에서는 필연적으로 많은 개발자들이 거쳐가며 개발을 하고,

오랜시간동안의 코드의 수정과 추가가 있음으로 해서, 코드 컨벤션을 엄격하게 관리하지 않으면,

각양각색의 코드 컨벤션들이 존재하게 된다.

이부분은 가장 경계해야하는 부분이다.

 

나하나쯤이야, 이렇게 한다고 크게 문제가 없을듯한데? 라는 생각을 가진다면, 그 생각은 큰 문제를 야기한다.

코드 컨벤션은 모두가 꼭 지켜야하는 팀내의 룰이다.

이 룰을 지키지 않는다면, 저마다의 방식과 표현이 프로젝트에 녹아들게 되고, 이런 균열들은 결국은 컨벤션에서 끝나지않고,

설계의 레이어에 대한 룰을 지키지 않게 되고, 코드의 역할과 경계에 대해서도 개인적인 생각이 녹아들어가게 된다.

 

큰댐에 금이 가기 시작하는 느낌이랄까? 작은 실금에서 균열은 시작되니...

 

따라서 팀원들은 약속된 코드 컨벤션을 꼭 지키도록 해야하고, 지켜야하는것을 책임이라고 생각하여야 한다.

코드 컨벤션은 이런 의미에서 정말 중요하다.

팀원들의 멘탈의 수준을 다잡아주는 역할로써 매우 중요하다고 생각하기 때문이다. (헤이해지는건 순식간이다!!)

 

코드 컨벤션 안지키는 팀치고 잘굴러가는 팀 못봤다..쩝

(이전 직장에서는 api url 표기법을 _로 룰을 정했었는데, 신입 개발자가 - 하이픈으로 표기법을 작성해서 난리가 난적이 있었지..ㅎㅎ)

긴급 개발자 회의가 소집이 될정도였어서, 정말 큰 이슈로 바라보긴했다.

(뭐 그당시에는 누가 이렇게 했냐!!! 정도였긴했지만, 위 내용처럼 훨씬 큰 빙산의 일각이 있다고 생각한다.)

 

이부분은 룰을 지속적으로 모니터링하며, 잘못된 부분은 팀원들끼리 인지하도록 하는 방법이 가장 효율적인것같다...

자동화가 안되는 느낌 ㅠ

하지만, 잘못됨을 팀원들이 잘 받아들이고, 능동적으로 개선하면 최첨단 수동이 되는 가장 좋은 방법이기도 하다!!