[토막글] 생산성에 대한 이야기

개발자의 애질리티 (toss.tech)

개발자의 애질리티

위의 글을 읽고 느낀 점이 좀 있어서 간략하게 글로 남기고자 했다.

 

waterfall vs agile

최근에 진행한 프로젝트의 경우 waterfall 방식으로 진행되었다. 초기의 설계를 잡고 이에 대한 보고를 하고 피드백을 받고 설계를 고치고 요구사항을 정리하는 등의 사전 작업을 했다. 그리고 개발을 들어가며 이에 대한 구현을 시작했는데, 이를 진행하며 설계가 잘못되었다는 것을 느끼는 포인트가 많았다.

내가 도메인에 대한 이해가 부족했든, 설계에 대한 경험이 부족했든 결과적으로 설계가 잘못되어 발생하는 수정사항들이 발견되는 경험을 했다.

그래서 든 생각은 내가 미숙해서 그런 것이라고 하기에는 누가하든 수정사항이 나오지 않는 완벽한 설계는 불가능하지 않지 않나 싶었다. 요구사항이 바뀌는 등의 외부 요인들도 존재하기 때문이다.

그렇기에 애자일 방법론이 현재 개발론의 표준이 된 것 같다.

품질과 생산성

개인의 품질 역량을 10이라고 가정했을 때 평균적으로 8정도의 품질을 보여줄 확률이 높으며, 상당한 노력을 투입해야 10의 품질을 만들어 낸다고 생각할 수 있습니다. 따라서 11의 품질을 추구하게 된다면 생산성이 극적으로 저하될 수 있습니다

위의 말에 매우 공감을 했는데

요즘에 내가 경험하고 느끼는 내용이기 때문이다.

프로젝트 초기에 시간에 쫓기지 않을 때는 역량 초과인 품질을 지향하여 생산성이 너무 떨어지는 경험을 하였고, 요즘에는 마감을 지키기 위해 생산성을 높이기 위해 눈에 밟히는 부분이 있지만 우선은 무시하고 있는 중이기 때문이다.

이전에 클린코드 책에서 나왔던 내용이 인상깊어서 기억에 남아있는데

마감기한을 지키는 것은 디폴트이기 때문에 마감에 쫓겨서 나쁜 코드를 생산해내는 것이 어쩔 수 없었다는 것은 프로그래머의 역량 부족에 대한 변명이다. 주어진 시간내에서 좋은 코드를 생산하여 마감을 지키는 것이 프로그래머의 소양이다.

내 뇌에서 여러번 곱씹으면서 표현이나 내용이 변질되었을 수 있다만 나는 이것이 맞다고 생각하고 지키고자 한다.

이러한 포인트에서 나는 현재 내 역량 부족을 느끼고 있다.

코드 리딩

대부분의 회사에는 다른 개발자들이 생산한 코드가 항상 산적해 있습니다. 어떤 기능을 개선하고 싶다면 다른 사람이 작성한 코드를 읽어야 하죠. 그래서 보통은 코드를 읽는 시간이 작성하는 시간보다 훨씬 깁니다. 따라서 읽기 좋은 코드를 만드는 것은 개발자의 삶에 굉장히 중요합니다. 기존 코드를 읽는 것에 과도한 시간을 써야 한다면 기능 개선을 위한 준비 작업에만 상당한 시간을 소비하게 되어 생산성이 떨어지게 됩니다.읽기 좋은 코드를 만들어서 코드 리딩의 생산성을 향상시키는 것이 중요한 이유입니다.

회사에 들어가 이미 개발된 시스템을 맡기 전까지는 항상 내가 새로운 것을 만드는 일의 연속이였다. 그렇기에 다른 사람들의 코드를 읽는 경우보다는 내 코드에 집중하는 일이 많았다. 하지만 내가 현재 처한 상황은 내가 내 코드를 치는 일보다는 기존의 시스템의 코드들을 읽고 동작을 이해하는 일이 더 많다. 그리고 내가 보고 있는 시스템은 꽤나 연식이 되었고 내 생각에 나쁜 코드들도 많다. 그래서 그런지 코드를 읽는 데에도 리소스가 많이 투입되고, 이를 제대로 이해하고 기억하는 것에는 더 많은 리소스가 투입되고 있었다. 읽기 나쁜 코드들로 인해 코드 리딩의 생산성이 떨어지면 향후의 유지보수에 큰 악영향을 준다는 점을 체감 중이다.

 

가능하다면 코드를 읽을 때 리팩토링 기술(Rename Method, Extract Method 등)을 활용하는 것이 좋습니다. 이러한 리팩토링을 Michael Feathers는 ‘탐색적 리팩토링(Exploratory Refactoring)’ 이라고 부르며, 이 과정에서 수정된 코드가 최종적으로 코드 저장소에 반영되지 않는다고 하더라도 충분히 가치있는 일입니다. 제가 느끼기에 Exploratory Refactoring은 정말로 효과적인 학습 프로세스이기 때문입니다.Exploratory Refactoring을 수행하게 되면 코드를 읽은 즉시 나의 해설을 표시하기 때문에 굉장히 적극적으로 코드 리딩이 되며, 코드 리딩의 주도권을 자연스럽게 리더(reader)가 가져가게 됩니다. 책을 읽었는데도 이해가 안되서 다시 읽어야 하는 것과 같은 수동적인 상태에서 벗어날 수 있게 됩니다. 따라서 Exploratory Refactoring은 탁월한 개발자가 탁월해지게 만들어주는 진정한 OP 기술입니다

그래서 제시되는 방법으로 위처럼 코드를 리펙토링 하는 작업을 제시하고 있는데, 사실 이 방법은 초기에 코드를 읽기 시작할 때 회사 선배가 추천한 방법이였는데 당시 나의 생각으로는 어차피 리펙토링해도 이것이 실제로 반영되지 않을 것이고 그냥 읽는 것으로 내용을 이해하는데 충충분하다고 생각했었다. 하지만 실제로 해보니 읽고 까먹고 다시 읽고 다시 이해가 안되는 생산성이 너무나 떨어지는 일의 반복을 하고 있는 나를 발견할 수 있었다. 이번에 리펙토링하는 방식의 코드 리딩이 리마인드되었을 때 시도해봐야겠다고 강하게 느꼈다.