도서

내가 주로 주석을 쓰던 때를 생각해보면 나쁜 디자인의 코드를 숨기고 설명을 하려고 주로 썼던 것 같다. 하지만 계속 업데이트가 되고 코드가 바뀌면서 주석의 신뢰성은 점점 낮아졌고 주석을 보지 않게 되었다. 결국 주석도 레거시가 되어 나쁜 코드를 더 나쁘게 만드는 상황이 된 것이다. 주석은 나쁜 코드를 막아주지 못한다. 나쁜 코드를 설명하기 위해 주석으로 설명하다 보면 점점 지저분해지는 코드를 볼 수 있다. 많은 개발자들이 가장 깔끔한 코드는 주석없이 의도를 잘 설명한 코드가 깨끗한 코드라고 한다. 그러니 우리는 주석에 시간을 투자하는 것보다 아래처럼 투자해보는 것은 어떨까? 주석을 달아야 코드를 이해할 수 있다면 다시 작성해보자 코드로 의도를 표현할 수 있게 고민하고 설계한다. 주석보단 좋은 네이밍을 통..

작게 만들기 주니어 개발자로써 가장 큰 실수를 하는 것이 하나의 함수에 너무 많은 책임과 기능을 넣음으로써 해당 로직이 무슨 기능을 하는지 모르게 되는 실수를 많이 하게 된다. 저도 그런 실수를 종종하고 후회를 합니다. 왜 작게 만들면 좋을까? 책에서도 작게 만들면 무엇이 좋은지 증거나 자료를 제시해주지는 않는다. 하지만 좋은 코드들을 보게 되면 대부분 아주 작은 부분까지 분리되어 있다. 이렇게 많이 분리 시켜놓으면 더 관리하기 어렵다고 생각 할 수 있다. 하지만 직접 프로그래밍하면서 설계하는 개발자라면 개발하면서 나누는 이유와 그로 가져오는 이익들을 느낄 수 있다. public class ValidationUtils { public boolean idCheck(String id) { String ema..

의도를 명확하게 클린 코드에서는 의도를 명확하게 하는 것을 매우 중요하게 생각한다. 코드에 대해 명확한 의도를 가지지 않고 코딩을 하게된다면 어떻게 될까 아래의 예제를 통해 알아보자 List dateTimes; 위의 변수를 보고 어떤 역활을 하는지 생각해보자. 코드에 아무런 의도가 없어서 추론이 불가능하다. 우리는 결국 이코드를 하나하나 추적해서 알아가는 수 밖에 없다. 하지만 이렇게 이름에 의도를 나타낸다면? List memberJoinedDateTimes; 아! 멤버(회원)가 가입한 시간을 모은 변수구나! 라고 바로 생각하게 된다. 코드에 의도를 명확하게 표현하는 것은 중요하고 이러한 네이밍 하나로 엄청난 시간을 절약하게 된다. 물론 조건문 반복문에도 의도를 나타내는 것은 매우 중요하다. List d..

스타트업에서 근무하면서 빠르게 아웃풋을 내야하는 환경에 일하다 보면 코드를 작성하는데 생각보다 손이 먼저 나가게 된다. 안된다는 것을 알면서도 습관적으로 손이 자꾸 먼저 나가게 된다. 결국 개발을 마치고 나중에 보게 된다면 나는 "왜 이렇게 짰을까...." 라고 후회를 하고 쌓인 부채로 인해 업보가 돌아오게 된다. 하드코딩으로 인한 생산성 저하는 생산성이 중요시하는 개발자에겐 치명적으로 다가오게 된다. 물론 부채를 포기하고 난 몰라하고 퇴사를 할 수 도 있다. 그렇게 무책임하게 떠나고 계속 전전하고 후퇴하게 된다면 연차는 계속 쌓이지만 실력은 주니어 수준에 머무르게 될 것이다. 결국 기업은 그런 개발자를 채용하지 않을 것이고 개발자로서의 가치는 점점 떨어지는 것이다. 나는 실제로 첫직장을 SI업체를 다니..

빨간 막대 패턴 한단계 테스트 우리들인 테스트를 할 때 어떠한 방법으로 하는지 API를 개발할 때 컨트롤러부터 테스트할 때 도 있고 DAO나 Repository 먼저 테스트하는 경우도 있습니다. 켄트백은 이러한 상향식 프로그래밍 하향식 프로그래밍은 TDD 프로세스에 대해 효과적으로 설명할 수 없다고 말을 합니다. 이와 같은 수직적 메타포는 시간에 따른 단순한 변화일 뿐이라고;; 메타포: 본래 표현되어야 할 내용을 간접적으로 명시하는 것이다. 예시: 인생은 여행이다. 켄트백은 TDD에 대해 성장이라는 키워드에 초점을 맞췄다. 우리는 TDD를 처음 접할 때는 더닝 크루거 효과처럼 TDD에 아주 얕은 부분만 알고 알고있는 테스트만 작성을 합니다. 그렇게 알고 있는 테스트만 작성하게 된다면 우리는 해당 테스트가..

켄트백의 테스트 주도 개발책을 읽으면서 "어떻게 테스트 할 것 인가?" 에 대해 아래와 같이 먼저 생각해보고 가장 기본적인 전략에 관한 질문에 답해야 한다고 말합니다. - 테스트 한다는 것은 무엇을 뜻하는가? - 테스트는 언제 해야 하는가? - 테스트할 로직을 어떻게 고를 것인가? - 테스트할 데이터는 어떻게 고를 것인가? 첫번째 질문을 답하는데 테스트 코드와 관련해서 여러 세미나 영상이나 개발 커뮤니티를 찾아보면서 생각했던 건 테스트는 켄트백이 말했던 것 처럼 위험한 리스크를 지루함으로 바꿔주는 것이라고 생각한다. 왜냐하면 테스트를 반복 할 수록 스트레스 받는 정도가 많아지고 더 많은 시간을 투자하면서 점점 지루해지지만 사전에 일어날 수 있는 오류를 발견하고 에러를 줄일 수 있어서 리스크를 줄일 수 있..