Five Lines of Code - 13. 나쁜 코드를 식별 가능하게 만들기
주제: 좋은 코드와 나쁜 코드를 분리해야 하는 이유, 코드를 나쁘게 표시하기 위한 규칙들
🔖 13.1 나쁜 코드에 대처하는 자세
책의 내용
이번 장에서는 나쁜 코드를 딱 봐도 안 좋게 보이게 만들어서 품질의 수준을 명확히 표시하는 방법을 논의합니다. 이것을 '안티-리팩토링' 이라고 합니다.
나쁜 코드를 남겨두면 두 가지 장점이 있습니다. 다시 찾기가 쉽고 통제가 지속가능하지 않다는 신호를 줍니다. 문제를 알리기 위해 나쁜 코드를 전달하려면 상당한 심리적 안정이 필요합니다. 우리가 비난받지 않을거라는 믿음이 있어야 합니다.
(중략) 잘 만들 수 없다면 눈에 띄게 만들어야 합니다. 나쁘지 않은 코드보다는 나쁜 코드가 더 낫다고 생각합니다. '아주 좋은'의 기준을 넘을 수 있는 시간이나 기술이 없다면 그냥 '나쁘게' 두어야 합니다. 이 활동은 코드를 깨끗한 코드와 레거시 코드로 분리합니다.
코드가 깨끗한 코드인지 레거시 코드인지 한눈에 알아볼 수 있으면 좋으 코드와 나쁜 코드 사이의 파일 비율을 쉽게 추정할 수 있습니다. 이 정보는 리팩토링 노력을 쏟을 곳을 안내하는 데 사용할 수 있는 정보입니다.
나의 생각 1: 저자 의견에 대한 반박
약간 도발적인 내용이다. 현실과 맞닿아 있지 않은 부분이 있거나 갑론을박이 있을 것 같다. 현업에서 과연 '딱 봐도 나쁜 코드'를 마음 놓고 PR을 올릴 수 있는 분위기의 팀이 제한적일듯 하다. 대다수의 사람들은 정말 시간이 없다면 몰라도 최대한 시간이 닿는대로 코드를 수정할 것 같다.
물론 리팩토링의 우선순위를 높이고 코드의 재작성을 촉진하는 순기능이 있을 수 있으나, 잠재적인 단점도 있다. 나쁜 코드를 남겨둔다면 오류의 위험이 증가할 뿐만 아니라, 유지보수가 오히려 더 어려워질 수도 있다. 더불어, 픽스해야할 것들이 많아지면 해야 할 일이 많게 느껴져 부담이 생길 수 있고, 개발 문화에 부정적인 영향도 줄 수 있을 것 같다. 따라서 이 전략을 사용한다면 내부적으로 매우 신중해야 할듯 하다.
나의 생각 2: 안전한 조직 문화에 대하여
책 <최고의 팀은 무엇이 다른가>의 작가 대니얼 코일은 ‘나는 안전한가'와 ‘우리는 연결되어 있는가'가 성공하는 집단의 기본이라고 말한다. 우리의 뇌가 여전히 원시 시대의 공포에 가장 민감하게 반응하기 때문이다.
그의 책 ‘최고의 팀은 무엇이 다른가'에서는 이 지점을 더 과학적으로 다루고 있다. 대니얼 코일은 3년간 프로스포츠팀, 특수부대, 영화사, 코미디 극단, 보석 도둑단 등 전 세계적으로 성공한 집단을 찾아다녔다고 한다. 성공한 집단은 일정한 행동 양식이 있었다. 리더가 미세한 신호로 ‘우리는 이어져 있다’는 안정적인 결속을 만들어냈고, 그에 따라 구성원은 서로의 약점조차도 두려움 없이 토로했다고 한다. 즉, 어떤 집단이 훌륭한 성과를 냈다면 이유는 그 팀이 똑똑해서가 아니라 안전했기 때문이라고 진단했다.
대니얼 코일이 말한 조직의 안전감은 직접 경험해 보면 그 중요성을 더욱 체감하는 것 같다. (물론 적당한 선을 지킨다는 전제 하에) 조직에서 의견을 편안하게 눈치보지 않고 말할 수 있다는 것, 쉬어야 할 때 마음 놓고 쉴 수 있다는 것이 얼마나 중요한지. 더 나아가 힘들어도 이 회사를 계속 다닐 수 있게 해주는 원동력이 되기도 한다. 반대로, 그러지 않은 조직에 있을 때 얼마나 두렵고 스트레스를 받는지도 (...)
어쨌든 이야기가 딴 곳으로 샜지만, 저자가 말하는 '나쁜 코드를 남겨두어도 비난받지 않을 거라는 믿음', 그리고 좋은 개발 문화도 조직의 안전감으로부터 비롯되지 않을까 라는 생각이다.
🔖 13.4 코드를 안전하게 나쁜 코드로 보이기 위한 규칙과 방법
책의 내용
나쁜 코드를 나쁘게 보이게 할 때(즉, 나쁜 코드를 눈에 띄게 만들 때)는 세 가지 규칙을 따라야 합니다.
올바른 정보를 절대 훼손하지 말 것
향후 리팩토링을 어렵게 만들지 말 것
결과를 한눈에 알 수 있을 것
나쁜 코드를 눈에 띄게 만드는데 사용하는 몇 가지 일반적인 방법을 살펴보겠습니다.
열거형 사용: boolean과 같은 타입 코드 대신 열거형을 사용 (+ 찾기 쉬운 장점)
정수형 및 문자열을 타입 코드로 사용: 문자열 사용 시 텍스트가 상수 이름과 동일한 목적을 수행
코드에 매직 넘버 넣기: 일반적으로 상수를 인라인으로 사용 시 사용 (하지만 정보 파괴의 위험이 있어 주의)
코드에 주석 넣기: 주석을 사용해 정보를 보존 및 이목을 끌게 됨
코드에 공백 넣기: 코드문을 그룹화 및 필드를 그룹화
이름을 기준으로 항목을 그룹화: 그룹화할 항목에 공통접사를 붙이기
이름에 컨텍스트 추가: 향후 데이터 캡슐화를 쉽게 하기 위해 공통접사를 이름에 추가
긴 메서드 만들기: 대부분의 개발자에게는 경고의 신호
메서드에 많은 매개변수 넘기기: 메서드를 정의하는 쪽과 호출하는 쪽 둘 다 명확히 식별됨
getter와 setter 사용: 결과적으로 캡슐화 클래스 보강 시 사라져야 함
나의 생각
경험상 긴 메서드를 만들었을 때 리팩토링의 필요성을 느꼈다. 예를 들어 calculateAndValidate 라는 메서드가 있다면 하나의 메서드는 하나의 일만 해야 한다는 원칙을 지키기 위해 분리 작업을 하곤 했다.
혹은 매직 넘버가 있을 때도 '아 여긴 아직 리팩토링을 안한 부분인가보네' 하면서 상수화를 하고, 이외의 부분도 함께 리팩토링을 한 적이 있었다.
이렇게 원칙들을 보며 경험을 떠올리니, 필자가 제안한 원칙과 방법이 어느정도 수긍이 되었다.
하지만, 코드에 공백을 넣는 것은 다른 작업자가 보았을 때 리팩토링이 필요한 부분이라 알아채기 쉽지 않을 것 같다. 또한 주석을 넣는 것은 정보를 보존하는 장점과 함께 리팩토링 할 위치를 빠르게 찾을 수 있는 방법이기는 하나, 취향에 따라 이슈로 올리는 등 다르게 표현해도 좋겠다.
어쨌든 필자가 제안한 의도는 지금까지 책에서 말한 리팩토링 방법을 그대로 반대로 하되, 세 가지 원칙만큼은 지키면서 하라는 것 같다.
📚 참고 자료
Last updated