포스팅 하고 싶은 주제들은 많은데 아직 마무리를 못하여 여러개의 토막글만 남아있다.. 그래서 바람같이 흘러갔던 1월에 느꼈던 점들을 짤막하게 정리해본다.
점점 회고 블로그가 되고있다. 😂
목적에 집중
개발 방향에 대해 논의를 하는데 의견차가 잘 좁혀지지 않을 때가 있다. 각자의 주장에 타당함이 있을 때 어떻게 해야할까?
내가 요즘 가장 많이 하는 말은 ‘목적을 다시 한번 생각해보자.’ 라는 말이다.
아직 팀의 특정 기술 성숙도가 낮을 때 위와 같은 상황이 자주 벌어지곤한다. 일반적인 구현은 크게 문제가 되지 않는데, 점점 규모가 커지고 복잡해질수록 예외상황이 생기면서 방향성이 흐려지기 시작한다. 나같은 경우에는 MVVM 을 처음 공부하고 도입할 때 자주 겪었다. 아키텍처가 이미 정해준 틀이 있는데, 예외를 처리하기는 어렵고. 그리고 흑마술과 같은 방법으로 때우고자 하는 유혹이 강렬하게 찾아온다..
그럴때 우리가 이 기술을 왜 선택했는지, 이 기술은 무슨 목적으로 나온 것인지 살펴보면 의외로 쉽게 해결방법이 나오곤 했다. 용어와 형식이 주는 느낌에 메이지 말고 항상 그 목적성을 상기하는 것이 중요하다고 느낀다.
(기술을 넘어 아키택처, 패러다임 등을 대입해도 동일하게 적용될 수 있다.)
개선이냐, 협업이냐
비교적 오래된 프로젝트를 개발하다보면, 거의 프레임워크화 되어 자주 쓰이는 패턴들이 보이곤 한다. 그리고 새로운 코드를 짤 때 고민에 빠진다.
개선의 관점에서는 고치고 싶은 부분들이 군데군데 보인다. 당시에는 최선의 접근방법이었을 것이지만 지금은 너무 신경써야할 리소스가 많이 드는 방식이다. 개선을 건의할까?
협업의 관점에서는 그동안 팀원들이 쌓아온 팀내의 룰과 같다. 이를 바꾼다는 것은 팀원들의 새로운 학습 리소스 + 예외 케이스에 대한 추가 협의 등 새로운 리소스가 소모될 수 있다. 그냥 사용할까?
두 가지 모두 중요한 측면이라고 생각하기에, 항상 긴 내적갈등을 겪는다.
현재 내 방침은 이슈가 되는 부분이 퍼포먼스 혹은 지속적인 관리 이슈를 유발하는 경우에는 1) 타당한 이유와 2) As-Is 와 To-Be 의 확실한 차이점을 내새워 팀원들을 설득하고, 그외에는 패턴을 그대로 사용하기로 했다. 그리고 팀원들이 모두 동의했을 경우 개선 작업은 반드시 내가 주도하여 마무리 할 것. 뒤에서 불평만 하는 사람이 되기 싫다.
간결한 것이 최선의 설명일 수 있다
최근에 이메일을 작성할 때 받은 피드백이었다.
- 두괄식 작성
- 전달하고자 하는 내용은 짧게. 전문 용어나 자세한 히스토리 X.
안드로이드에서만 추가한 내용을 다른 플랫폼에 공유하는 메일이었는데, 나는 개발자의 마인드로 추가된 내용과 히스토리를 엄청 디테일하게 적었다. 그리고 위와 같은 피드백을 받았는데, 그 이유로는
- 사람들은 하루에도 수십개의 참조메일을 받기 때문에 길면 잘 안읽을 수 있다(!) 읽어도 당사자가 아니면 이해하기 어렵다. 결국 내가 전달하고자 하는 내용조차 묻힐 수 있음.
- 상세한 히스토리는 추가 요청때 전달해줘도 충분하다.
명쾌했다! 아직도 메일로 전달하는 것은 좀 더 숙달되어야 함을 느낀다.