여러분이 하시는 인su인계가 위1험하다는 사실을요(?)
퇴사/이직 해본 개발자라면 다들 인수인계를 해봤을겁니다.
안해봤다구요? 지금 당장 로1또를 구입하러 거시죠
“대부분 한 달 정도 인수인계를 해주고 떠납니다. 라고 할 뻔”
하지만, 퇴사 하고 나서도 연락이 오는 경우가 종종 있습니다.
연락을 해 본 분들도 계실겁니다.
사실 나도 해봄
나에게 연락하지 말란 말이다아ㅡ!!
서버나 클라우드 말고 ‘코드’ 만 두고 생각해보자면
이런 경우일 때 아직 파악이 되지 않았는데 전임자가 떠나버렸고,
답이 없으면 연락하게 됩니다.
먹어라
선대 개발자에게서 계승(?) 될 수록 코드는 점점 방대해집니다.
이런 상황땜에 MSA 처럼 관심사를 분리해서 작게 유지하는 방법도 있고
뭐, 이런저런 방법들이 있을겁니다.
하지만 결국 헬프콜을 받고나면 뭘 하든 다 똑같습니다.
프로젝트를 작게 여러개로 나누면 이건 어떤 프로젝트를 건드려야 하는지 찾게 되고
모노레포로 커지면 너무 방대해서 어디에 있는지 찾게 됩니다.
그리고 하나 고쳤더니 다 터졌어요
빌리버에서는 특정 영역에 대해서는 라이브러리나 프레임워크를 개발해서
그 부분은 아예 인수인계를 하지 않습니다.
그냥 그걸 쓰면 된다고 하죠.
@belivvr/aframe-react
@belivvr/aframe-react-stereoscopic
aframe-mirror
이런 식으로 라이브러리를 만들어서 전달합니다.
Public 으로 만들어서 이직할 때 자기 커리어로 들고 가기에도 좋음
라이브러리는 한 기능에 대해 관심사를 분리해서 가져가므로
라이브러리에서 버그가 생기지 않으면
심연(?)을 들여다 볼 필요가 없어집니다.
심영을 들여다보…
요즘은 WebRTC 라이브러리인
Mediasoup 를 쉽게 쓸 수 있게 해주는 프레임워크를 개발하고 있습니다.
WebRTC 개념 인수인계가 너무 어렵고
Mediasoup 라이브러리 사용법도 너무 복잡해서
단순하게 만들고 이 부분을 인수인계를 안하려는 목적이죠.
이렇게 했을 때의 장점은
비즈니스 로직만 집중해서 인수인계 하면 됩니다.
복잡한 부분을 인수인계를 할 필요가 없어지죠.
비즈니스로직과 복잡하게 엮이지 않게 된다는 장점도 있구요.
그리고 Public 으로 배포할 때의 장점은
‘우리’ 가 아닌 제3자가 버그를 제보 해 줄 가능성이 높습니다.
PR은 별로 기대 안 함 ㅠㅠ
Public 라이브러리니까 대충 코딩하지 않게 됩니다.
자신이 메인테이너로 참여한다는 자부심도 생기죠.
그 보단 동료들이 Accept 안눌러줌
인수인계가 편해질겁니다!
Public 라이브러리로 배포하고
대표님께 등짝스매싱을 맞으실 수 있습니다!
빌리버에산 안 맞음
한 수 배우고 갑니다!