육각형 개발자

육각형 개발자 - 예스24

읽으며 든 생각을 나불나불..

 

나는 신기술에 목매는 개발자가 아니다. 신입 때는 신기술 사용이 잘하는 개발자의 척도라고 생각했던 적도 있다. 물론 다양한 경험을 해야 개발능력이 향상된다는 것은 아직도 같은 생각이다. 다만 회사 일로 봤을 때는 신기술에 목을 매는 것은 독이 될 수 있다. 내가 도입하고 나갔을 때 유지보수가 되는가?

현재 쓰고 있는 도구에 깊이 있는 지식을 가추고 있는가? 다가올 문제해결에 필요한 개발 도구를 공부하는 게 더 이득이다.

 

메서드 이름은 적당한 추상화 수준을 지켜야 한다. 모든 구현 내용을 메서드 이름에 넣으면 읽기 싫어진다. 메서드 내에서의 일관성이 있어야 하며 1번 메서드는 구체적인데 2번 메서드는 너무 추상적이면 또 코드를 이해하는데 도움이 되지 않는다. 추상화 수준을 맞추자.

 

메서드를 나누는 기준이 참 모호할 때가 있다. 메서드 분리를 하게 되면 구현을 다 숨겨서 추상화 수준만 보고 이해할 수 있다. 다만 컨텍스트 이동이 많아져 세세한 구현 흐름을 잃을 때도 있다. 

모든 구현을 하나의 메서드에서 하는 경우도 있다. 단순 메서드의 경우는 이렇게 하면 한눈에 보기 편하고 오히려 코드가 줄어든다.

 

여러 메서드에 파라미터 DTO 하나를 돌려쓰면 읽기가 힘들다. 물리적인 객체량은 줄겠지만 update, register, delete에 사용되는 변수가 다 다른데 같은 DTO를 쓰면 의미 파악하기 힘들어진다.

그렇다면 객체를 전달하지 않고 모든 필드를 파라미터로 전달하면 어떨까? 코드 줄 수가 너무 길어져 보기 힘들어진다는 단점이 있지만 나름 불필요한 객체 생성등을 예방할 수 있다.

모든 상황에 맞게 써야 하며 타인, 타회사의 경험을 경청하되 과정을 살펴보고 맹신하지 말자. 우리 상황에 대입해서 생각해야 한다.

 

예전에는 무슨 개발자가 되고 싶냐고 물었을 때 나의 대답은 모든 문제를 해결하는 개발자였다.

그걸 물어본 면접관이 웃던 게 기억이 난다. 지금도 그런 개발자가 되면 좋겠지만 그렇수 없다는 것을 알고 있다. 지식은 너무 방대하고 나는 그걸 다 소화하지 못한다.

지금은 무슨 개발자가 되고 싶냐면 안정감을 주는 개발자가 되고 싶다. 일적으로나 동료로서.

일로 본다면 이 사람에게는 일을 주면 잘 진행되겠지가 되겠고 동료로서는 오래 있어주는 개발자가 되고싶다. 갑자기 다음날 사라지는 개발자가 되고 싶지는 않다. 요즘 심리적 안정감이 중요하다고 느낀다.