좋은 코드 개발 문화 (클린 코드, 코드 리뷰, TDD)

소프트웨어 개발을 할 때 좋은 개발 문화는 무엇 일지에 대해서 개인적으로 고민해 보았습니다.

 

 

좋은 코드 개발 문화 (클린 코드, 코드 리뷰, TDD)

 

 

 

 

 

 개발하면서 어려운 점

 

개인적으로 개발하면서 어려운 점을 생각해 보았습니다. 제가 겪었던 안 좋았던 상황들을 조금 정리해 보았습니다.

 

• 처음부터 요구사항이나 리소스, 테스트 등 모호한 것이 많다.
• 그래도 처음에는 나름 고민하여 만든 코드가 동작한다.
• 개발자 단계에서 하는 테스트가 많지 않고 최종 엔드투엔드 테스트에 의존한다.
• 특정 모듈, 특정 파트에 업무 로드가 집중된다.
• 문제가 발생했을 때 디버깅에 오래 걸리고 해결책은 최소 수정사항으로 해결하려고 한다.
• 수정했을 때 테스트가 잘 없고 테스트해 볼 수 있는 환경 제약이 많다.
• 결국 사이드 이펙트가 발생하여 다시 수정해야 한다.
• 어느 순간 히스토리가 쌓인 코드가 되어 이해하기 어렵고 신규 인력들의 진입장벽이 크게 생긴다.

 

 

 

 개선하려면..

 

결국 이러한 문화나 개발 환경을 개선하려면 여러 가지를 바꾸어야 합니다. 정답은 없지만 일반적이면서 제가 생각해 왔고 제가 일할 때 고민하고 노력하고 있는 부분들을 공유해보려고 합니다.

 

 

 

 클린 코드

 

클린 코드는 코드를 작성할 때의 합리적인 원칙을 세우고 이를 기준으로 팀원들이 소통하면서 개발해야 한다는 관점에서 나온 용어이자 생각할 거리입니다. 코드를 깔끔하게 작성한다는 것은 개발자의 역량에 어느 정도는 의존되는 항목이지만 일반적인 원리나 규율을 공유하면서 어느 정도 개인기량에 의존하는 것을 완화할 수 있다고 생각합니다.

 

클린 코드에 관련된 내용은 로버트 C 마틴의 유명한 책인 "클린 코드"가 있습니다.

 

 

 

클린 코드 책 정보

 

 

 

 

깨끗한 코드는 단순하고 직접적이며 잘 쓴 문장처럼 읽힙니다. 의도를 명시적으로 잘 표현하고 명쾌한 추상화를 통해 이해하기 쉽습니다.

세부적인 내용에 대해서는 나중에 다루어 보도록 하겠습니다.

 

물론 개발자마다 다를 수 있습니다. 하지만 서로 소통하고, 좋은 코드를 만들어야 한다는 내용에는 공감할 것이며 이를 수행하고 보완할 수 있는 문화가 바로 코드 리뷰 문화입니다. 좋은 코드 리뷰 문화를 통해 지속적으로 코드가 깨끗하게 유지되거나 점점 개선되는 것이 좋은 문화라고 할 수 있겠습니다.

 

 

 

 

 코드 리뷰

 

코드 리뷰 문화는 이제는 소프트웨어 업계에서는 당연하게 자리 잡았다고 할 수 있습니다. 하지만 과연 코드 리뷰를 제대로 하고 있다고 할 수 있을까요? 자신 있게 답할 수 있는 사람들은 그렇게 많지 않을 것 같습니다. 기계적인 리뷰, 서로 간에 날 선 리뷰와 의견 충돌로 인해 감정이 상하고 제대로 긍정적인 리뷰가 되지 않는 것은 흔히 볼 수 있는 안 좋은 사례입니다.

 

 

아래 카카오 테크에서 작성한 코드 리뷰에 대한 좋은 글을 하나 소개해봅니다.

 

 

코드 리뷰에 대한 좋은 글

 

 

리뷰를 할 때 제가 중요하게 생각하는 것은 바로 긍정적이고 학습적인 피드백입니다. 일단 리뷰를 요청한 다는 것이 다소 부담스러울 수 있습니다. 따라서 처음에는 수고를 인정하고 시도하는 자세에 대한 칭찬이 필수적입니다. 그다음 수정한 내용에 대해 많이 고민해 보았다고 가정해야 합니다. 왜 이렇게 했나? 다르게 할 수도 있는데 이런 것을 생각조차 하지 않았나?라고 생각하고 리뷰를 달면, 리뷰를 받는 사람 입장에서는 많이 고민했고 그래도 이것이 최선이라고 판단한 것인데 그런 과정에 대해서 무시를 한다는 느낌을 받을 수 있습니다. 

 

따라서 긍정적이고 인정하는 베이스를 바탕으로 실수할 수 있는 부분이나 내가 알고 있는 지식들을 공유하고 필요하다면 예제 코드나 추가적인 PR을 통해 적극적으로 리뷰를 해 줄 필요가 있습니다.

 

물론 현실적으로 이렇게 제대로 리뷰를 해주기에는 시간이 부족하거나 내가 잘 모르는 수정사항일 때가 많습니다. 이럴 때는 단순히 LGTM 이 아니라 구체적으로 노력이나 도메인과 상관없는 코드 수정사항에 대해 간단히 코멘트라도 해준다면 서로 긍정적이고 발전적인 리뷰 문화가 정립될 수 있다고 생각합니다.

 

 

 

 

 리팩토링

 

리팩토링은 기존의 코드를 개선하려는 행위입니다. 단순히 가독성을 위하거나 클린 코드를 위한 수정이 될 수도 있고 이슈 수정사항이 발생했을 때 수정을 하면서 함께 개선할 수도 있고 코드 사이즈를 최적화하거나 성능을 개선하거나 하는 비기능 요구사항들을 개선할 때 수행할 수 도 있습니다.

 

하지만 리팩토링을 자주 한다는 것은 너무 위험하고, 또 그렇게 하는 곳을 많이 보지 못했습니다. 왜 그럴까요? 

바로 이런 행위들이 결국 사람이 하는 것이고 수정에 대한 위험부담이 있다는 것 때문입니다.

극단적으로 ROM에 들어가는 부트로더 같은 코드나 하드웨어와 가까운 펌웨어 등과 같은 코드는 한번 릴리스한 이후 수정을 할 수 없거나 수정이 되면 안 되는 코드들도 있습니다. 또 실제로 잘 동작하는 코드를 괜히 수정해서 굳이 문제를 만들 수도 있고 불안정성을 감수하기에는 넘어야 할 산이 굉장히 많습니다.

 

하지만 이렇게 개선하려는 노력 없이는 결국 큰 문제가 발생하거나 더 이상 손쓸 수 없는 죽어가는 코드가 될 수 있습니다. 이렇게 극단적인 상황이 아니더라도 신규 인력이나 몇 달 후의 내가 코드를 보았을 때 이해가 안 되거나 수정했을 때 문제가 발생하여 품질에 크게 영향을 줄 수 있습니다.

 

이렇게 리팩토링은 지속적으로 개선하려는 노력이고 꼭 필요합니다. 어떻게 하면 리팩토링을 안전하게 할 수 있을까요? 바로 개발자 테스트입니다. 기본적으로는 유닛테스팅을 통해 개발자 단계에서 테스트가 될 수 있다면 보다 안전하게 리팩토링을 해볼 수 있습니다.

 

 

 

 

 유닛테스팅

 

개발자 테스트의 대표적인 테스트 방식인 유닛테스팅, 단위테스트에 대한 내용입니다. 앞서 제 포스팅 들에서 다룬 TDD에 관련된 내용입니다. 개발자 단계에서 단위 테스트를 통해 빠르게 검증이 가능하다면 

단위 테스트는 단순히 빠르게 검증이 가능하다는 측면뿐만 아니라 Documentation 효과가 있고 API를 고려해서 설계를 할 수 있다는 장점이 있으며 결국 자동화로 가능 과정에 필수적인 테스트입니다.

 

 

[개발 방법] 테스트 주도 개발(Test-Driven Development)에 대해서

 

 

 

[Python] TDD를 활용한 파이썬 unittest 사용 방법과 예제

 

 

 

 

 결론

 

 

좋은 개발 문화에 대해서 고민해왔던 것을 조금 정리해 보았습니다. 어찌 보면 너무 당연한 내용일 수도 있지만 항상 지키기에는 귀찮거나 현실에 타협하는 경우가 많습니다. 저 또한 매번 제대로 지킨다고 할 수 없지만 최소한 프로세스는 지키고 이런 마인드는 항상 갖고 습관화하려고 노력하고 있습니다.

문화는 혼자만의 노력으로 되지는 않습니다. 하지만 개개인이 노력하고 모범을 보인다면 생각보다 자연스럽게 형성되는 것도 보았습니다. 나부터 솔선수범하여 지키려고 노력한다면 언젠가는 일하기 좋고 성장할 수 있는 환경이 될 것이라고 생각합니다.