일기 형식으로 실무에서 협업을 하며 아쉬웠던 부분에 대해서 한 풀이 느낌으로
평소에 생각했던 내용을 정리해서 적어보려고 합니다.
글에 두서가 없을 수 있습니다. 미리 죄송합니다
저는 1년차 주니어가 되었고 더 나은 개발자가 되기 위해 끊임 없이 레퍼런스를 찾아보고 공부합니다.
특히 저는 Java&Spring 개발자로써 객체지향을 공부하고 클린코드를 짜기 위해 고민합니다.
좋은 코드와 좋은 설계는 무엇일까? 라는 고민을 위주로 하며 그 고민을 코드에 녹여내기 위해 끊임 없이 고민합니다.
그래서 요즘은 '[객체지향의 사실과 오해, 오브젝트, 클린 코드]' 위 책을 읽고 있습니다.
위 책들을 읽으면서 이해가 되는 부분과 이해가 안돼는 부분이 있었고 실무 코드와 책을 내용을 비교했습니다.
위 책들을 저자는 뛰어나고 대단한 개발자닌까 위 저자들을 경험을 실무에 적용하여 어플리케이션에 적용하기 위해 노력하고
고민을 항상 있었을 찰나에 첫번 째 고민이 생겼습니다.
바로 읽는 사람이 '내 코드가 불편하다고 하는 리뷰' 를 들었습니다.
나는 책들을 내용을 토대로 어플리케이션에 적용해보았고, 내가 보기에 나름 코드가 객체지향 철학을 지키며 작성되고 있다고 판단했습니다.
하지만 리뷰 했던 사람이 처음으로 했던 말이 '왜케 코드를 다 쪼개놨냐? 계속 코드를 타고 타고 들어가야 해서 별로 좋지않다' 였습니다.
그리고서는 아무리 좋은 설계를 해도 읽는 사람이 불편하고 어려우면 말짱 도루묵이다 라는 의견이 였습니다.
위 리뷰는 나랑 비슷한 연차의 사람도 아니었고 경력 거의 20년을 가진 분을 리뷰였습니다.
처음에 이야기를 듣고 살짝 벙쪘고, 납득이 되지 않았습니다.
그래서 질문을 드렸습니다. "그럼 실무에서는 어떤게 좋은 코드인가요?"
위 질문에 대한 답변은 '읽기 편한 코드가 좋은 코드 다' 라는 답변을 받았습니다.'
그래서 저는 제 코드를 계속 점검했습니다.
1) 변수 및 메소드 네이밍이 적절했나?
2) 적절하게 메소드를 분리했나?
3) 객체지향 SOLID 원칙을 준수했나?
4) 어느 부분이 가독성이 저하가 되었을까?
5) 나중에 읽는 사람의 생각하면서 코드를 작성했나?
처음에 생각났던 포인트가 위 5가지 였습니다.
위 5가지는 어떻게 보면 내가 판단하에 어떠한 철학적인 개념을 내가 고민해서 내 코드에 녹여낸 부분이기에
작성한 스스로가 잘 작성했는지에 대한 판단을 하기 어렵다고 느꼈습니다.
그리고 좋은 피드백을 받고 싶었지만, 그렇지 못했기에 개인적으로 많이 아쉬웠습니다.
하지만 아쉽게도 같이 일하는 동료들 입장에서 제 코드는 딱히 달갑지 않은 코드였다고 생각을하니.. 조금 기분이 좋지는 않았습니다.
과연 내가 읽은 책에서 배운 OOP 랑 클린 코드는 누구를 위한 철학일까??
왜 이런 고민을 했냐면 내가 아무리 SOLID 원칙을 지키고 객체지향적으로 코드를 작성하고 클린 코드에 위배되지 않게 코드를 짜도
협업하는 사람이 별론대? 라는 평가를 하면 그냥 끝이다.
추가적으로 내 경험에서 빗대어 이야기를 꺼내보면
경험1)
질문: 뭐하러 서비스를 다 분리해두냐, 하나로 통합해서 관리하면 되지?
답변: 기능을 책임에 맞게 서비스를 분리해뒀다.
질문: 걍 AService 만들고 여기다가 다 통합해서 보관하자. 그래야지 보기 편하다.
답변: 네...
경험2)
질문: 왜 상수들을 Enum 으로 빼서 관리해요?
답변: 공통으로 사용해야 하고 + 하드 코딩하기 싫어서 입니다.
질문: 이러면 한번 클릭해서 뭐 타고타고 들어가서 봐야하고 클래스가 많아지면 어지럽고 귀찮으니 담부턴 분리하지말고 그냥 값에 박아둬
답변: 네..
요즘 개발을 하면서 나를 의심하게 됩니다.
과연 좋은 설계란 무엇일까? 좋은 코드를 짜고 있는걸까?
사람들 입맛에 맞게 설계하는게 좋은 설계일까?
경력이 있던 분들은 본인이 해온 개발 스타일을 계속 하길 원하는 부분이 있다고 생각한다.
그럼에도 불구하고 개발자라고 하면은 바꿀건 바꾸고 새로운것을 도입할건 도입을 해야한다고 생각한다.
요즘 따라 동료들과 대화를 하면 예전에는 경험이 없었으니 아 그렇구나~ 했는대 이제는 모든 부분을 의심하게 된다.
내가 아무리 OOP 장인이고 개발 장인이여도 같이 협업 하는 사람들이 받아들이지 않는다면
그건..그냥 이상과 실무를 구별못하는 바보가 되는 것이라고 생각한다.
왜 어른들이 공부 열심히해서 좋은 대학교가고, 취준 열심히해서 좋은 회사 가라는 이유가 조금씩 납득이 된다.
비슷한 사람들끼리 모여있는 곳이여야 비슷한 고민도 공유를하고 대화가 잘통해서 일까?
뭔가 글을 쓰다보니 나는 똑똑한대 나말고 다른 개발자 들은 멍청해! 라는 느낌이 들 수 있다.
나는 대단한 사람도 아니고 재능있는 개발자도 아니다.
나는 내가봐도 재능은없고 노력으로 메꿔야 간신히 매꿔지는 그런 개발자이다.
과연 이상적인 개발은 무엇이고 협업은 무엇일까?
네카라쿠배 에 가면 위 같은 생각을 안가지게 될까?
흠. 그것또한 잘모르겠다. 그래서 네카라쿠배 형님들께 리뷰도 받아보고 싶고 같이 대화도 나눠보고 싶다.
위 부분은 내가 방법을 찾을 수 있을 것 같다.
아니면 내가 주니어라서 새로 해보고 싶은게 많아서 신기술 도입 및 새로운 도전을 좋아해서 그런건가?
구기술이 나쁘건 아니다. 기술적 선택에 그 당시 최고의 선택을 한것일 것이다.
아래는 예전에 봤던 웃긴 짤이다ㅋㅋ
신기술이 필요한대는 이유가 있고 poc 과정이 꼭 필요하다고 생각한다.
jdk 새로운 문법 공부하기 싫어서 jdk 업그레이드를 안해?
위 이유가 아니고 회사의 입장에서 안정성을 원하는 것 이라면 언제든 납득할 수 있다.
뭐가 됐든 합당한 이유가 있고 납득이 되야 하는대 위 중간 과정이 생략된 것 같아 협업 상황에서 항상 아쉬울 뿐이다.
우아한형제들 포비 대장님이 하신 말씀이 기억이 난다.
나는 맨처음 반란군이 되고 싶었다. 하지만 현실은 그럴 수 없는것 같다.
반란군이 되기 위해서는 반란을 원하는 팀원들이 필요하다.
혼자 하는 반란은 그냥 1인 시위지 반란이 아니다..
사회 생활 원래 다 이런거 아니겠나?
나만 스트레스 받는게 아니라 다른 누군가는 나보다 더욱더 많이 스트레스 받을 것 이라고 생각한다.
나를 위로해 달라는 글도 아니고 공감해달라는 것이 아니다.
결국에는 회사를 다녀야하기에 이 또한 헤쳐나가야할 산이라고 생각한다.
어떻게 보면 위 글은 한풀이 이자 사회생활 선배들을 조언이 필요해서 한탄을 해봤다.
이상 주니어의 개소리를 봐주셔서 감사합니다.
