서론
구름에서 주관하는 Commit 오프라인 참석에 당첨되어 세션에 참여하였습니다. 오후 7시~8시 반까지 진행되었으며 처음 입장할 때 주스, 샌드위치와 같은 간단한 음식을 준비해 주셔서 퇴근하고 바로 온 저로선 허기를 달래며 들을 수 있었습니다.
세션 내용은 책 내용보다는 클린 코드의 오해와 진실 그리고 설계 히스토리 위주로 진행되었습니다. 클린 코드 책을 읽은 저로서 굉장히 흥미로운 내용들이라 1시간 반 동안 집중해서 들었습니다. 그리고 성철님께서 발표 또한 재밌게 해주셔서 지루할 틈이 없었습니다!
아래는 제가 기억에 남는 부분을 추려서 순서대로 정리해놓은 내용입니다.
<클린 코드>를 어떻게 봐야하나?
클린코드의 논란과 오해
- 클린 코드를 추구해서 주석을 작성하지 않는다.
- 클린 코드는 클린하기 때문에 리팩토링할 이유가 없다.
- 클린 코드는 버그가 적어서 테스트코드가 없어도 된다.
- 클린 코드는 엄격하게 규칙을 준수해야한다.
- 클린 코드는 레거시 코드를 무시한다.
실제 클린 코드가 아니면 손을 안댄다는 분들이 존재한다.
이는 과연 올바른 생각일까요?
문제가 생기는 이유
애초에 클린이라는 잘못된 언어 선택때문에 이와같은 문제들이 야기됩니다.
- 클린을 통해 어떤 깨끗한 상태가 있다는 착각을 불러일으킨다.
- 클린/Not클린이라는 이분법적인 생각을 갖게 된다.
- 이로써 개발자는 클린하지 않은 코드를 작성한다는 죄책감을 갖는다.
켄트벡과 엉클밥의 차이
켄트벡과 로버트C마틴(엉클밥)은 우리가 아는 책들의 굉장히 유명한 저자들입니다.
- 켄트벡 : 테스트 주도 개발, 익스트림 프로그래밍, 켄트벡의 구현패턴 등등
- 엉클밥 : 클린 코드, 클린 아키텍처, 클린 소프트웨어 등등
이 둘은 코드를 대하는 태도의 차이가 있습니다.
- 켄트백 : 좋은 코드도 중요하지만, 안좋은 코드를 가지고 성공하는 사업들도 분명 존재한다. 이를 어떻게 설명할 것인가?라는 태도 (신중파)
이 책은 좋은 코드가 중요하다는 다소 미약한 전제에 기반한다. by 켄트벡의 구현패턴
- 엉클밥 : 클린 코드를 작성하면 개발자들이 코드를 건들기 쉬워지기 때문에 사업이 빠르게 성장할 것이라는 태도 (선동파)
살짝 약을 판 느낌이 없지 않아 있습니다.. 그래서 <클린 코드>에는 여러 논쟁이 있는데,
이를 인지하고 <클린 코드>의 선동적, 극단적 표현을 걷어낸 후 이 내용을 한 문파(오브젝트 멘토)의 교훈 또는 기법의 권고로 볼 필요가 있습니다.
추가: 논쟁을 더 알아보고싶다면? 코딩애플 - 코딩 책 한권만 읽으면 이렇게 됩니다.
코드와 코딩이란 무엇인가?
분리된 사전 설계(일반적인 설계)
일반적으로 여러가지 표현법(UML 등)으로 요구사항을 표현한 것을 설계라합니다. 그리고 설계단계가 끝나면 개발자들이 투입되어 설계된대로 코드로 표현합니다.
- 이때 일명 코더, 코드 원숭이와 같은 비약적 단어가 생겨났습니다.
- 왜? 이들은 생각할 필요 없이 설계된 대로 짜기만 하면 되니까요.
- 그저 단순 언어만 학습해도 가능하니까요.
설계로서 코딩(패러다임 전환)
1992년 Jack W Reeves가 소프트웨어 설계란 무엇인가?라는 아티클에 아래와 같이 기고했습니다.
- 프로그래밍은 소프트웨어를 만드는 것이 아니라 소프트웨어를 설계하는 것이다
- 소프트웨어 구축은 컴파일러와 링커에 의해 이루어지는 것이다.
- 소스코드는 그저 문서일 뿐이며, 이를 컴파일러와 링커가 이진파일로 전환을 시켜준다.
- 즉, 개발자는 소프트웨어를 설계하는 사람들이다.
- 소프트웨어 설계는 타 분야(건축, 선박 등)에 비해 비교적 쉽다.
- 따라서 굳이 타 분야 처럼 절차적으로 수행할 필요가 없다.
결론적으로 Jack W Reeves는 코딩, 디버깅, 테스트도 설계의 일부이며, 설계의 결과가 코드라고 주장합니다.
그리고 로버트C마틴은 클린 시리즈의 원전인
클린 소프트웨어부록 D에 위를 인용하며, 소스 코드는 곧 설계다 라고 주장했습니다.
설계 재료
코드를 잘짜고 싶은데 어떻게 해야하나요? ➡️ "객체지향을 공부하세요"
과연 이는 맞는 대답일까요? (저 또한 의문을 가졌던 내용이기도 했습니다.)
OOP를 바라보는 성철님 관점
<클린 코드>의 OOP
- 로버트C마틴은 메시지(동사) 중심으로 프로그램 자체를 객체로 바라봅니다.
- 그리고 OOP와 다른 패러다임(ex 절차적 프로그래밍, FP 등)의 적절한 혼용을 제안합니다.
- 즉, 너무 객체로만 표현하지 말라는 것입니다.
- <클린 코드> 3장 : 함수로 절차 메서드까지 포함
- <클린 코드> 6장 : 객체 vs 자료구조(구조체)
- <클린 코드> 17장 : 휴리스틱과 커피
분별 있는 프로그래머는 모든 것이 객체라는 생각이 미신임을 잘 안다 - 엉클밥
설계
"처음부터 클린 코드를 작성하면 리팩토링이 필요없을까?"
절대 아니죠..🙅♀️ 리팩토링은 클린코드의 핵심
리팩토링(설계 개선)
사전적의미 : 소프트웨어의 겉보기 동작은 그대로 유지한채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변
경하는 기법
- 대부분의 한국사람은 공장을 떠올립니다. 하지만 factory와 상관없습니다.
- 팩토링은 분해라는 의미를 내포하고있습니다.
팩토링(factoring) = 인수 분해 = 분해(decomposition) = 설계 - 즉, 코드를 나누고 해결하고 합치면서 재설계를 하는 것 입니다.
기회주의 리팩토링 :
리팩토링의 저자 마틴 파울러는 리팩토링을 언제든 어디서든 누구든 코드를 정리해야할 때 할 수 있는 기회주의 활동으로 장려하고 싶다 라고 말합니다.
(참고 https://youtu.be/vqEg37e4Mkw)
왜 리팩토링을 안할까?
불안불안한 뉴욕의 엠파이어스테이트 빌딩 공사장. 하지만 이시대엔 이게 위험한줄 모르고 광고로 사용했다.
대부분의 사람들이 리팩토링을 하지않는 이유는 안전망 즉, 테스트 코드가 없어서입니다.
- 내가 변경하는 코드가 어디서 뻑나지 않을지 노심초사하며 개발하게 된다.
- 만약 리팩토링하다 에러가 났다면? 일단은 답을 바로 찾지 못하고 코드를 전부 까보게 된다. (스트레스🤯)
하지만 테스트코드가 있다면?
- 코드를 변경했을 때 의도대로 동작하는지 빠르게 파악할 수 있기 때문에 변경이 쉬워진다.
- 즉, 최소한의 안전망이 있기 때문에 리팩토링이 쉬워진다.
적극적인 리팩토링(상시 설계)
TDD의 리팩토링
TDD는 리팩토링을 설계의 일종으로 바라보며 이 관점에서 가장중요한 것은 리팩토링입니다.
참고로 TDD는 아래의 구조를 계속 반복합니다.
- 테스트 코드 먼저 작성 (안전망 설치)
- 테스트 실패
- 통과를 위한 최소한의 코드 작성 (더티해도 괜찮음)
- 공격적으로 리팩토링
DDD의 리팩토링
DDD는 지속적인 리팩토링 과정에서 어느 순간 암시적 개념을 인식하면 도약을 하게되며, 도약 후에도 지속적 리팩토링을 수행하도록 합니다. (광범위한 대규모 리팩토링)
도약 : 생물 세계의 급작스러운 진화를 말하며, 소프트웨어의 진화도 일정하지 않다는 것을 의미
창발적 설계
켄트벡의 4가지 규칙을 적용하여 리팩토링 하다보면 어느순간 좋은 설계가 만들어진다. - 마이클 페더스
마이클 페더스 : 우리가 익히아는 SOLID 원칙 이름을 붙인 사람
그는 좋은 설계란 의도된게 아닌 창발된 것이라 주장합니다. (자세한 내용은 <클린 코드> 12장)
켄트벡의 단순한 설계 규칙은 아래와 같습니다.
- 모든 테스트를 실행한다.
- 중복을 없앤다.
- 프로그래머의 의도를 표현한다.
- 클래스와 메서드 수를 최소로 줄인다.
⭐️설계 변천사⭐️
아키텍처
아키텍처는 시스템에 오랫동안 큰 영향을 미치므로 초기에 심사숙고해서 결정해야한다?
- 소프트웨어 시스템은 물리적 시스템과 다릅니다. 관심사를 적절히 분리해 관리한다면 소프트웨어 아키텍처는 점진적으로 발전할 수 있습니다. (자세한 내용은 <클린 코드> 11장)
- 시간에 따라 운영환경, 요구사항 등 모든 것은 계속 바뀔 수 있으므로 생물이 환경에 적응하면서 진화하듯 소프트웨어 아키텍처도 변화해야 합니다.
스프링이 인기있는 이유가 바로 이것
- 스프링은 관심사에 따라 모듈화가 잘되어 있어 유연하게 아키텍처 개선이 가능하도록 프레임워크가 만들어져 있기 때문에 많은 사랑을 받고 있습니다.
- 가장 유명한 스프링 삼각형
DI,AOP,PSA
결론
위 내용을 정리하자면
- <클린 코드>는 생각보다 클린이나 코드와 상관없다.
- 무엇이든 있는 그대로 교조적으로 따르지 말자.
- 코드는 최종 설계 산출물이다.
- 객체지향 패러다임에 매몰되지 말자.
- 다양한 프로그래밍 스타일의 가능성을 열어두자. (golang 참고)
- 꾸준히 성장하고 분화하는 소프트웨어를 만들자.
- 생물이 자가 증식 & 포식하듯이
- 좋은 코더는 만든 코드보다 삭제하는 코드가 많을 수 있다.
- 테스트 코드를 중심으로 변화 주기를 만들자.
- 테스트 코드는 안전망이다.
- 나와 우리를 위해서 테스트 코드를 작성하자.
느낀점
<클린 코드>책 내용을 바탕으로 SW 설계 패러다임 변화를 전체적으로 훑어주셨는데 아무래도 시간이 짧다 보니 더 자세히 듣고 싶다는 생각이 들었습니다. (그래서 그런지 QnA 시간도 정말 핫했습니다. 🙌) 설명에 언급된 책들을 전부 읽어보고 싶다는 욕심도 들었고 중간중간 나오는 Topic들을 더 깊게 공부해야겠다는 의지도 생겼답니다.
또한 개인적으로 '대부분의 사람들이 안전망=테스트 코드가 없어서 리팩토링을 하지 않는다.' 라는 문구가 가장 공감이 되었습니다. 실제 저희 회사 시스템만 봐도 오래된 레거시라 테스트 코드는 커녕 비즈니스 로직이 DB 패키지 군데군데 숨어있기 때문에 다들(저포함) 무서워서 변경 자체를 꺼리게 됩니다. 그래서 리팩토링보단 돈을 투자해서 아예 새롭게 시스템을 만들기를 원하더라고요.
그래서 성철님께 QnA시간에 아래와 같이 질문을 드렸습니다!
질문 : 테스트 코드(안전망)가 없는 시스템을 리팩토링할 수 있는 가장 이상적인 방법은 무엇일까요?
답변 : 마틴파울러 - 리팩토링 책에 딱 해당 방법이 나와있으니 읽어보고 적용해보시는걸 추천드립니다.
정답을 알려주시기보단 저에게 찾아보고 공부할 기회를 주시는 게 굉장히 감사했고, 다음날 바로 책을 구매하였습니다. 앞으로 이 책을 나침반 삼아 더 좋은 개발자가 되는 길로 한걸음 나아가고 싶네요.
결론적으로 퇴근 후 1시간 반이라는 시간이 전혀 아깝지 않았고 너무 유익했으며, 다시 한번 의지와 방향성을 다잡을 수 있는 시간이었습니다. 또 좋은 Commit 세션이 있다면 신청해야겠습니다! 😊
