클린 코드 #10 클래스코드 레벨, 함수 레벨까지 제대로 작성하는 것도 중요하지만, 더 차원 높은 단계까지 신경써야 한다.이 챕터에서는 깨끗한 클래스에 대해 다룬다.클래스 체계표준 자바 컨벤션에 따르면변수 목록이 가장 먼저 나온다.그 중 상수( = 정적 공개 상수)가 맨 처음에 나온다.그 다음으로 정적 비공개 변수가 나온다.그 다음에 비공개 인스턴스 변수가 나온다.공개 변수가 필요한 경우는 거의 없다.변수 목록 다음에는 공개 함수가 나온다.비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 추상화 단계가 순차적으로 내려가기 위함이다.캡슐화변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 할 필요는 없다. protected로 만들고 테스트 코드에서 접근을 허용하기도 한다.같은 패..

클린 코드 #9 단위 테스트과거에 비하면 테스트 분야가 엄청난 성장을 이뤘고, 단위 테스트를 자동화하는 프로그래머가 많아지고 있다.하지만, 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는 미묘하면서 중요한 사실을 놓치고 있다.TDD 법칙 세 가지TDD는 실제 코드를 짜기 전에 단위 테스트부터 짜라고 요구한다. 하지만 이 규칙 외에도 많은 규칙들이 있다.실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.컴파일은 실패하지 않으면서 실행 시 실패하는 정도로만 단위 테스트를 작성한다.현재 실패하는 테스트를 통과할 정도로만 테스트를 작성한다.이렇게 일하면, 매일 수 십개의 테스트 케이스가 나온다. (1달이면 수 백개…) 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문..

클린 코드 #8 경계SW 개발을 할 때 모든 SW를 직접 개발하지 않는다. Reuse도 많이한다. 오픈소스를 사용하거나, 패키지를 사거나, 사내 팀이 제공하는 컴포넌트를 쓰거나….이러한 외부 코드를 우리 코드에 깔끔하게 통합하는 것이 중요하다. 이 경계를 깔끔하게 처리하는 기법을 살펴보자.외부 코드 사용하기인터페이스 제공자와 사용자는 원하는 바가 다르다.인터페이스 제공자(ex. 패키지 제공자, 프레임워크 제공자)적용성을 최대한 넓히려고 한다. (더 많은 고객 구매를 위해)인터페이스 사용자자신의 요구에 집중하는 인터페이스를 바란다.이렇기에 시스템 경계에서 문제가 생길 소지가 많아진다.ex) 대표적인 예시: java.util.MapMap은 다양한 인터페이스로 다양한 기능을 제공한다. 하지만 그만큼 위험도 크..

클린코드 #7 오류 처리왜 클린 코드 책에 오류 처리가 나왔을까? 깨끗한 코드와 오류 처리는 확실한 연관성이 있기 때문이다. 실제로, 많은 코드들이 전적으로 오류 처리 코드에 좌우된다. 오류 코드가 막 흩어져있어, 실제 코드의 로직을 파악하는게 불가능하다.오류 처리는 프로그램에서 반드시 필요한 요소 중 하나이다. 입력이 이상하거나 디바이스가 실패할 지도 모르기 때문이다. 다만, 오류 처리로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다.오류 코드보다 예외를 사용하라과거에는 예외 처리를 지원하지 않는 프로그래밍 언어가 많았다. 예외를 지원하지 않으면 오류 처리 및 보고 방법이 제한적이다.if (handle != DeviceHandle.INVALID) { retrieveDeviceR..

#6 객체와 자료구조 변수를 private로 정의하는 이유는, 남들이 변수에 의존하지 않도록 하게 만들고, 변수 타입과 구현을 맘대로 바꾸기 위해서다.그런데, 왜 Getter와 Setter를 남발해서 private 변수를 외부에 노출하는 것일까?자료 추상화변수를 private으로 선언하더라도 값마다 Getter, Setter를 제공하면 사실상 구현을 외부로 노출하는 것과 같다.변수 사이에 함수라는 계층을 넣는다고, 구현이 저절로 감춰지는게 아니다. 구현을 감추려면 추상화가 필요하다.추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 클래스이다.자료를 세세하게 공개하기보다는, 추상적인 개념으로 표현하는 편이 좋다.인터페이스만으로, 또는 Getter/Setter만으로 추..

클린코드 #5 형식 맞추기 프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다.이를 위해 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다. 팀에 속했다면 팀의 규칙을 따라야 한다.(요즘은 코드 스타일을 xml 등의 문서로 작성해 IDE에 등록해주면 코드 스타일을 자동으로 적용해준다)형식을 맞추는 목적코드 형식은 너무 중요하다. 코드 형식은 의사소통의 일환이다. 너무 중요하니, 코드 형식을 맹목적으로 따르면 안 된다.오늘 구현한 기능은 언젠간 바뀔꺼고, 오늘 구현한 코드는 앞으로 바뀔 코드 품질에 큰 영향을 미친다.맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다.그러면 대체 원활한 소통을 장려하는 코드 형식은 무어일까?적절한 행 길이를 유지하라.소스 코드의..

클린 코드 #4 주석#클린코드잘 달린 주석은 정말 유용하지만, 잘못 달린 주석은 독이다.우리가 코드를 잘 짰다면 사실 주석은 거의 필요가 없다. 코드로 의도를 표현하지 못해서 주석을 사용하는 것이다.주석은 오래될 수록 코드에서 점점 멀어진다. 코드를 유지보수하면서 주석까지 유지 보수하기는 현실적으로 불가능하다. 점점 더 주석과 코드가 분리되버린다.주석을 엄격하게 관리해야 하지만, 코드를 깔끔하게 정리하는 대에 더 많은 신경을 쓰는게 좋다.코드만이 진실을 이야기한다.주석은 나쁜 코드를 보완하지 못한다.난장판을 주석으로 표현하지 말고, 난장판을 치우는데에 시간을 써라.코드로 의도를 표현하라.조금만 더 생각하면 코드로 대다수 의도를 표현할 수 있다. 주석으로 달려는 설명을 차라리 함수로 만들어서 표현해도 충분..

클린 코드 #3 함수#클린코드40줄이 넘는 FitNesse 함수 코드를 9줄로 리팩터링 했더니 이해하기 매우 쉬워졌다. 이해가 쉬운 이유가 무엇일까? 의도를 분명히 표현하는 함수를 어떻게 구현할 수 있을까? 어떤 속성을 부여애햐 처음 읽는 사람이 프로그램 내부를 직관적으로 파악할 수 있을까?작게 만들어라함수 코드 라인 20줄도 길다. 함수의 의도가 명백하게 드러나도록 최대한 작게 만들어라.블록과 들여쓰기if/else/while 문 등에 들어가는 블록은..

클린 코드 #2 의미 있는 이름#클린코드이름을 잘 붙이는 규칙에 대해 알아보자.의도를 분명히 밝히자좋은 이름을 지으는데 오래 걸리더라도, 좋은 이름으로 절약하는 시간이 훨씬 더 많다.이름을 지을 때는 다음과 같은 질문에 모두 답할 수 있어야 한다.변수/함수/클래스의 존재 이유는?수행 기능은?사용 방법은?만약 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.ex) 경과 시간, 경과 날짜int elapsedTimeInDays측정하려는 값과 단위를 표현하는 이름이 필요하다.코드 맥락이 들어나게끔 이름을 작성하자.함축적이고 명시적이지 않은 정보를 드러냄으로써 코드가 명확해질 수 있다.그릇된 정보를 피하자그릇된 단서를 코드에 남기면 안 된다.널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다...

클린 코드 #1 깨끗한 코드#클린코드나쁜 코드나쁜 코드가 쌓일 수록 팀의 생산성은 떨어진다. 결국 언젠간 재설계하게 된다.(생성형 AI가 던저준 코드를 그대로 복붙해서 프로젝트를 진행하면 이런 상황을 겪게 될 가능성이 높다)개발자는 나쁜 코드의 위험성을 인지하고 상사의 무지한 요구를 거절해야 한다.기한을 맞추기 위해 나쁜 코드를 양산한다고 변명하다면 이는 틀린 말이다. 나쁜 코드를 가지고 개발하면 기한을 맞출 수 없다. 가장 빠른 개발 방법은 코드를 최대한 깨끗하게 유지하는 것이다.깨끗한 코드깨끗한 코드를 작성하려면 깨끗한 코드가 뭔지 부터 알아야 한다.논리가 간단해야 한다.의존성은 최소화하고 각 의존성을 명확히 정의한다.오류를 명시적인 전략으로 철저히 처리한다.보기에도 즐거워야 한다.효율적이여야 한다...