[회고] OOP, TDD 이용한 계산기 프로젝트 회고

 

코드리뷰 피드백

멘토님과 서브멘토님께 계산기 프로젝트에 대한 코드리뷰를 받았는데 그 피드백을 정리해보려한다.

• 변수, 메서드, 클래스 등 네이밍이 명확하지 않다.
  • 이 부분이 진짜 어렵다고 느꼈는데 멘토님의 코드를 보니까 알 것 같았다. 명확하지 않다는 말은 네이밍만 보고 어떤 역할일지 유추하기 어렵다는 것이다. 네이밍을 잘하고 책임이 명확히 나눠진 코드를 봤을 땐 좀 가볍게 훑어보는 것만으로도 코드에 대한 이해를 할 수 있었다. 
    ▶ 코드를 단순하고 명확하게 짜자.
• 접근지정자를 바꿔야할 것 같다.
  • 자바를 코테하면서 손에 익혔었는데 코테에서는 접근지정자가 아무 상관이 없다 보니까 큰 생각을 못하고 짰던 것 같다. 최근 팀원들이랑 피어 프로그래밍할 때도 접근지정자에 대한 지적을 되게 많이 당했었다. 
    ▶ 접근지정자를 잘 붙이면 협업에서 타인의 실수를 예방할수도 있고 캡슐화를 이룰 수 있으니까 많이 고민하자.
•  enum을 사용하면 더 좋을 것 같다.
  
  • 필자는 switch-case와 같은 부분에서 1, 2처럼 상수를 이용해서 표현을 했었는데 그렇게 하니까 해당 숫자를 보아선 어떤 역할을 하는지를 알 수 없었다. 이런 경우 enum을 사용하면 좋을 것 같았고 이뿐만아니라 사칙연산을 구현할 때도 enum을 이용해서 간결하게 구현한 분들도 많았다.
    ▶ Enum에 대한 블로그 글을 한번 써보자. (이해를 위해서)
• 클래스의 역할이 너무 많다 혹은 명확하지 않다.
  • 필자의 팀 멘토님께선 SOLID 5원칙 중 SRP를 가장 중요하게 생각하셨다. SRP가 잘 구현되어 있으면 인터페이스를 사용하지 않아도 유지보수할 때 비용이 적게 든다고 얘기하셨다.
    ▶ 클래스에서 if-else가 커지거나 출력, 계산, 입력 등 많은 역할을 가진다면 나누는 것을 생각해보자.
• MVC 패턴은 계산기에서 과하다.
  • 만약 계산기를 만들라는 요구가 왔을 때 MVC 패턴을 적용해서 만드는 것은 웹 애플리케이션을 생각하고 있다는 것이다. 하지만 그렇지 않을 수 있기에 오버엔지니어링 하지 않고 단순하고 명확하게 만들어놓으면 나중에 어떤 종류의 애플리케이션으로든 보수할 때 비용이 많이 안든다.
    ▶ 오버엔지니어링 하지 않고 SRP 잘 지키고 단순하고 명확하게 요구사항에 맞춰서 프로그래밍하자.
• 패키지명이 맞지 않는 것 같다.
  • 이는 확실하다. 패키지명에 대한 이해도가 없어서 그랬다. 해당 패키지명이 Model이었는데 Calculator와 같은 클래스가 들어가서 로직을 수행하고 있었다.
    ▶ MVC 패턴에 대한 공부가 필요하다.
• 검증하는 로직이 조금 더 숨는 것이 좋을 것 같다.
  • 필자의 코드가 숫자를 검증하는 메서드와 오퍼레이터를 검증하는 메서드가 나눠져있어서 이 부분을 따로 검증을 했는데 서브멘토님의 개인적인 생각으로는 그냥 '검증해줘'라는 느낌으로 하나의 메서드로 넣으면 그 내부적으로 메서드를 나눠서 처리하는 것이 더 좋을 것 같다고 말씀하셨다.
    ▶ 외부로 드러나는 public한 메서드를 하나로 두고 외부에선 모르게 내부적으로 알아서 처리한다는 느낌의 설계가 더 좋을 것 같다.
• break하는 구문이 명확하지 않다.
  • 이번에도 명확하지 않다인데 이전 계산 결과를 출력하다가 받아온 결과가 null 값이면 전부 다 출력한 것이기에 break를 통해서 멈췄는데 서브멘토님께서 코드를 보셨을 때 위험하게 느껴졌다고 말씀하셨다. 그래서 마지막 출력결과 입니다와 같이 사람이 이해할 수 있게 코드를 짜는 것이 중요하다고 말씀하셨다.
    ▶ 명확하게가 굉장히 어려운 것 같다. 사람이 쉽게 이해할 수 있는 코드를 짜자.
    
    
• 메서드로 구분하는 것이 좋을 것 같다.
  • 계산을 하는 로직을 하나의 메서드로 굉장히 크게 만들었는데 그 부분을 메서드로 나누면 좋을 것 같다고 하셨다. 거대한 로직을 이해하는 것은 힘들고 이를 메서드로 명확하게 나누고 네이밍도 적절하다면 이해에 훨씬 도움이 될 것이다.
    ▶ 메서드 또한 역할 단위로 나누자.

 

느낀 점

일단 정말 어려웠다. OOP가 뭔지도 몰랐고 SOLID 5원칙도 그런게 있다 정도만 알았지 그 5원칙이 무엇을 위한 건지도 모르는 상태에서 시작을 했다.

그러다 보니까 처음 시작은 팀원들이나 다른 분들의 얘기를 듣는 걸로 시작했다. 그래서 팀원들이 얘기했던 뭔지도 모르는 MVC 패턴으로 구현해보려고 했다. 여기서부터 잘못된 것이 뭔지 모르면 찾아보고 이해한 후에 만들어야 하는데 빨리 해야한다는 생각이 가득하니까 무작정 코드를 작성했던 것 같다. 프로그래밍을 하다가 모르는 점이 생기면 그 부분에 대해서 이해하고 진행하는 것이 오히려 더 빠르다라고 느꼈다. 그리고 요구사항을 받았을 때 물론 회사에선 팀원들간의 회의를 통해서 결정하겠지만 혼자서 진행을 하면 예외인 것과 예외가 아닌 것에 대한 명확한 구분이 필요하다고 느꼈다. 그 기준은 이 행위가 애플리케이션이 동작하는데 있어서 진짜 치명적인지를 확실히 생각해보는 것이 좋을 것 같다고 느꼈다.

멘토님과 서브멘토님의 코드리뷰를 받으면서 확실하게 느꼈던 것은 내 코드가 이해하기 어렵구나였다. 사실 개발자는 타인과의 협업이 필수적인데 그렇다면 코드를 단순하고 명확하게 짜는 것이 정말 코드를 잘짜는 것이라고 생각한다. 그래서 코드를 짤 때 이런 부분에 대해서 생각을 많이 하고 시간을 많이 투자해야겠구나를 느꼈다. 그리고 코드 상에 주석을 많이 달았는데 서브멘토님께서 주석이 없어도 이해되는 코드를 만들어야 한다고 말해주셔서 다시 한번 생각해봤던 것 같다.

이번 프로젝트는 많이 아쉬웠다. 처음하다 보니까 갈피를 제대로 잡지 못했다고 느꼈고 그냥 내 생각대로 코드를 짠 것보다 타인의 영향을 받았던 것 같아서 완전 나에게 향하는 피드백보단 외부적인 요소가 있었다고 느꼈다. 다음 프로젝트도 다 처음 경험해보는 것들이지만 요구사항을 명확히 파악해서 방향을 제대로 잡고 시작해야할 것 같고 나의 생각이 많이 섞인 프로젝트를 통해서 온전히 내가 받는 피드백이란 느낌을 받으면 좋을 것 같다.

앞으로 더 힘들어지겠지만 열심히 하면 언젠간 빛을 발할 수 있을 것이라 생각한다 파이팅!!