후기

[후기] '클린코드가 코드에 대한 책이 아닌 사실에 대해' 세미나

IT록흐 2023. 12. 23. 11:26
반응형

 

'클린코드가 코드에 대한 책이 아닌 사실에 대해' 세미나

 

강사 : 박성철 ( 현 컬리 물류 프로덕트 본부장 )
일시: 2023. 11. 22.(수) 오후 7:00 ~ 8:30
장소: 판교디지털센터(PDC) A동 901호 구름스퀘어

 

 

[ 후기 ]

 

'클린코드' 책의 저자인 로버트 C 마틴이 선동가적 기질이 있음을 처음 알았다. 책에서 '르블랑의 법칙'을 소개하는데, 나 또한 책을 읽으며 의미있게 본 법칙이지만... 사실 그런 법칙은 없다고 한다. 로버트 C 마틴이 친구들이랑 주고 받은 농담을 법칙처럼 소개한 것이라고 한다...개인적으로 대학시절에 클린코드를 읽고 프로젝트의 유지보수성이 확 올라간 경험을 한 적이 있어 한때는 클린코드를 맹신한 적이 있다. 이렇듯, 클린코드가 유명세를 타며 '클린(Clean)'에 집착하다 보니 오히려 생산성이 떨어지는 현상을 많은 회사에서 경험하고 있는 것 같다. 

 

'클린코드' 책의 내용이 모두 틀렸다는 것은 아니지만 선동적 표현과 실무와 맞지 않은 내용이 있음을 인지하고 책을 읽어보아야 겠다.

 

 

[ 세미나 요약 ] 


켄트 벡의 저서, '구현 패턴'은 "이 책은 좋은 코드가 중요하다는 다소 미약한 전제에 기반한다." 라는 말로 시작한다. 신중한 자세를 취하는 켄트 벡과는 달리, 로버트 C 마틴은 좋은 코드의 중요성을 강조하며 '르블랑의 법칙'( 나중은 결코 오지 않는다 )을 언급한다. 그러나 '르블랑의 법칙'은 실제로 존재하는 법칙이 아니다. 친구들끼리 한 농담을 법칙으로 소개하면서까지 자신의 주장을 선동하고 있다. 클린코드의 목차에 '휴리스틱'이 있다는 것부터 좋은 코드에 대한 원칙적 적용이 이루어 지지 않음을 의미한다. 

 

...

 

설계된 대로 코드를 구현하는 사람을 코더(Coder)라 부른다. 설계할지 모르고 분석할지도 모르는데, 언어와 프레임워크 기술만 배운다면 단순 노동자에 불과하다. 그렇다면 소프트웨어 설계란 무엇일까?

"코드는 요구사항을 상세히 표현하는 수단이니 종말되지 않는다."
- 로버트 C 마틴

"소스 코드는 곧 설계다."
- 클린 소프트웨어 ( 애자일 원칙, 패턴, 실천법 ) 클린 시리즈의 원전 

설계는 반드시 OOP가 정답일까? 코드를 잘 짜고 싶다면 객체지향이 정답일까?

 

OOP를 바라보는 관점은 하나가 아니다.

- 데이터 중심 (명사, 도메인 모델링)
- 기능 중심 ( 동사, 메시지를 중요하게 생각함, 인터페이스-역할부여 )
- 객체 중심 ( 프로그램의 기본구조를 객체로 보는 사상 )
- 객체 보조 ( 겍체는 필요할때만 쓰이는 보조, 토니호어의 레코드처리 )

'클린코드'에서 OOP는 기능 중심(동사, 메시지 중심)으로 바라본다. 그래서 메소드와 함수를 딱히 구별하지 않는다. 


그러나 요즘 자바에서도 데이터 지향 프로그래밍이 되도록 권고한다. JAVA도 메소드만 가지고 통신하거나 값기반 클래스 같은 변화가 발생한다. 객체지향은 Visitor Pattern 같이 다양한 타입이 서로 다르게 행동 할 때 깔끔하게 처리하기 힘들다. 이렇듯 객체지향 설계에만 몰입하는 행위는 좋지 못하다. 여러 패러다임을 이해하고 접목했으면 좋겠다. 

...

'리팩터링(Refactoring)'이란, 겉보기 동작은 유지한 채 코드를 이해하고 수정하기 쉽도록 내부구조를 변경하는 기법을 의미한다. 고로 리팩토링이란 '재설계'를 의미한다.

 

그렇다면 리팩토링은 언제가 좋을까?
마틴 파울러는 기회주의 리팩토링을 말한다. 리팩토링은 알아서 기회를 찾아서 하는 것이다. 그런데 많은 개발자들이 기회를 찾아서 리팩토링을 하지 못하는 경우가 있다. 왜 리팩터링을 하지 못하는 것일까?

 

리팩토링을 못하는 이유는 '안전망(테스트케이스)'이 없어서이다.

 

테스트 케이스가 있으면 변경이 쉬워진다. TDD에는 코드가 성공하기 위한 최소 코드를 작성한다. 그 다음 리팩터링을 진행한다. 흔히들 TDD를 할때 테스트에만 집중한다. 그러나 테스트는 설계 자체를 창발 할 수 있다. 설계라는 것은 반복해서 수정하다보면 자연스럽게 창발되는 것이기 때문이다. 이렇듯 아키텍처는 고정되어 있지 않고 지속적으로 변화할 수 있다.  관심사에 따라서 분리하여 관리한다면 소프트웨어 아키텍처도 점진적으로 발전할 수 있다. 소프트웨어는 만드는 것이 아니라 키우는 것이다.  개발자의 삶을 조금 더 편하게 하자고 10년 이상의 하드웨어의 성능을 기꺼이 포기할 수 없다. 소프트웨어는 시간축에 따라서 계속 변해야 한다. 소프트웨어는 탄생하고 나서 계속 살아가야 한다. 

 

[ 정리 ]

 

- 클린 코드는 클린이나 코드와 상관없다.
- 코드는 최종 설계 산출물이다.
- OOP에만 집중하지 말고 관점을 다양하게 하자.
- 꾸준히 성장하고 분화하는 소프트웨어
- 테스트 코드를 중심으로 변화주기를 만들자 ( 테스트 = 안정망 )

 

 

 "클린 코드를 신경 쓴 사람이 쓴 코드가 클린 코드다."

- 마이클 페더스

 



 

 

클린 코드가 ‘단지’ 코드에 대한 책이 아닌 사실에 대해, 11월 COMMIT 현장 스케치

2023년 11월 22일 열린 COMMIT에서는 컬리 물류 프로덕트 본부장 박성철 님이  《클린 코드》에 대한 이야기를 풀었습니다. 클린 코드를 둘러싼 논란은 어떤 것이 있고, 우리가 놓치고 있는 이야기

blog.goorm.io

 

 

반응형