의식적인 TDD, 리팩토링
4월 우아한 테크 세미나 “의식적인 TDD, 리팩토링” 세미나에 다녀왔습니다.
규칙 1: 한 메서드에 오직 한 단계의 들여쓰기만 한다.
규칙 2: else 예약어를 쓰지 않는다.
규칙 3: 모든 원시값과 문자열을 포장한다.
규칙 4: 한 줄에 점을 하나만 찍는다.
규칙 5: 줄여쓰지 않는다(축약 금지).
규칙 6: 모든 엔티티를 작게 유지한다.
규칙 7: 2개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
규칙 8: 일급 콜렉션을 쓴다.
규칙 9: 게터/세터/프로퍼티를 쓰지 않는다.
에서, 1번부터 7번까지에 대해 기초적인 부분부터 자세히 설명해주셨습니다.
평생동안 연습하겠다는 마음가짐으로 시작하고, 결혼하지 않은 사람이라면, 조금더 공부하는 마음가짐을 가졌으면 좋겠다고 하였습니다.
가장 공감이 가던 것은,
회사 소스에 바로 적용하지 말고, 장난감 프로젝트를 찾아서 만들라는 점이었습니다.
회사에 소스를 적용해보고, 리팩토링한 후에 롤백을 한 경험이 몇번 있었기에 더욱더 동감이 되었습니다.
주변 환경에 영향을 받지 않고 꾸준히 연습할 수 있는 환경이라는 것이 매우 중요한거 같습니다.
결론부터 이야기하자면 의식적인 TDD, 리팩토링 세미나에서 요구하고자한 내용은,
1. ELSE 를 쓰지 않는 조건에 대한 논리를 최소화하여 다형성 유도
2. 객체지향프로그램의 성배인 데이터의 캡슐화
로 축약할 수 있을 거 같습니다.
결론 : 코드나 아이디어의 중복이 없는 코드를 만들자!
마틴 파울러 형님은 컴퓨터가 이해하는 코드는 어느 바보나 짤 수 있다. 좋은 프로그래머는 사람이 이해하는 코드를 짠다
(Any fool can write code that a computer can understand. Good programmers write code that humans can understand.)고 하셨습니다.
일을 하다보면, 우선순위에 따라 타협을 하게 됩니다.
제가 개발하고 있는 광고솔류션은 모든 응답을 100ms 안에 맞춰야합니다. 시간으로 따지면 0.1초 안에 응답을 해야합니다.
100ms의 대다수의 시간은 nio 관련된 이슈입니다. 데이터베이스나, nosql 등에서 데이터를 가져오는데 걸리는 시간입니다. 그렇기 때문에 제가 어떤 소스를 짜든 속도의 이슈는 없다고 봐도 무방합니다.
그러나, 하드웨어의 발젼으로 제가 짠 소스만 JUNIT으로 검증할 경우 0.00000001ms 안에 응답이 처리되는 경우가 많고, Source 상에 로직에 의해 100ms 가 걸리는 경우는 없습니다.
그러나, 그 소스를 10만번, 100만번 돌렸을 경우에, 리팩토링한 소스와 기존 레거시 코드를 비교했을 때,
레거시 코드의 성능이 더 나은 경우가 더 많아 리팩토링을 할지 그냥 둘지 고민하게 됩니다.
새로운 기술이 오면, 야근을 하든 철야를 하든 시간을 내서 적용해봅니다.
람다를 적용해보기도 하고, 일정을 맞추기 위해 급하게 만든 소스들을 패턴화하여 간결하게 바꾸는 작업등을 해서 사람이 보기 편한 소스를 짜보기도 합니다.
그렇게 해서 테스트한 속도가 조금더 기계적인, 혹은 원시적인 소스를 짠 속도보다는 당연할지 모르겠지만 더 느리게 나옵니다.
그 타협점을 잘 찾아서 회사에 적용해야합니다.
그전에 세미나에서 들은 데로, 개인적인 장난감 프로젝트를 빨리 진행해서 리팩토링에 대한 즐거움을 조금더 재미있게 즐겨야할 거 같습니다.
여담으로 “규칙 9: 게터/세터/프로퍼티를 쓰지 않는다”는 건 좀 어렵지 않을까 싶습니다.
강한 캡슐화를 의미하는 것으로 보이는데요!
인스턴스 변수는 한번 사용했을 경우 해당 클래스에서 전부 사용(동작)한 후 코드를 만질 다른 프로그래머를 위해 단절시키는 것을 원하는 것으로 보입니다.
누군가 해당 인스턴스 변수를 재사용함으로써 중복 오류 등의 문제를 최소화 하고,
캡슐화로 인해 완전 독립적인 객체지향프로그램으로써의 좋은 점이 있을 수 있겠지만,
개발자들의 편의성(?)과 다시금 사용해야하는 중복되는 인스턴스 변수를 다시 생성해야하는 문제가 있을 것으로 보여, 이미 구현된 회사소스에서 적용하기는 어렵고,
장난감 프로젝트에서나 고민해봐야겠습니다.
정확한 세미나에 대한 내용은 참조 주소에서 확인할 수 있습니다. (잘정리되어있습니다.)