[개발자 책읽기] 클린 코드 - 애자일 소프트웨어 장인 정신 (1장 깨끗한 코드)

해당 글은 Robert C.Martin 클린 코드 라는 책을 읽고 학습한 내용을 정리 및 회고하는 글 입니다. 자세한 사항은 YES 24 클린 코드 에서 확인해주세요.

클린 코드 - 애자일 소프트웨어 장인 정신 (Uncle Bob)

• 위키북스
• 지은이: Robert C.Martin (Uncle Bob)
• 옮긴이: 박재호, 이해영

 

---

 

이번 장에서 이야기하고자 하는 것

 

코드는 요구사항을 상세하게 표현하는 수단.

• 우리의 코드에서 요구사항을 드러내야 한다.

 

나쁜 코드란?

• 나쁜 코드가 나오는 이유
  • 단지 돌아간다는 사실에 안도함
  • 쓰레기 코드가 보이면 나쁘다는 사실을 인지하고 언젠간 고치리라 하고 지나감
• 나쁜 코드는 나쁜 코드를 생성하게 됨
  • 나쁜 코드는 일정을 맞추기 위해 쫓겨 나쁜 코드를 양산
  • 모든 개발자는 나쁜 코드가 해가 된다는 것을 인지하고 있음
• 결국 나쁜 코드가 증가할 수록 생산성이 저하됨
  • 나쁜 코드를 고치기 위해 나쁜 코드를 생산
  • 깨진 유리창 이론과 마찬가지로 깨진 유리창이 더 깨져도 신경을 쓰지 않음

 

깨끗한 코드를 유지하기 위한 태도는?

 

• 일정 핑계, 비개발 팀의 압박 핑계 대지 말 것
  • 일정 조율을 실패한 것도 나쁜 코드를 생산하는 근본적 원인이 됨.
  • 결국 좋은 코드를 사수하는 것 역지 우리 개발자의 몫
    • ⇒ 일정은 불가항력이라 생각했었는데 생각해보니 이 역시 나의 결정
  • 전문성을 가질 것

 

깨끗한 코드는?

 

• 좋은 개발자들이 정의한 깨끗한 코드
  • 한 번에 한 가지에 집중한다.
  • 한 가지를 제대로 한다.
  • 논리가 간단해야 버그가 숨어 들지 못한다.
  • 설계자의 의도를 숨기지 않아야 한다.
  • 하나만 제공한다.
  • 문학적 이어야 한다.
  • 단순 명료해야 한다.

 

우리는 저자다.

 

• 우리는 코드를 짜고 누군가는 코드를 읽을 것이다.
• 독자와 잘 소통하는 것 역시 우리의 책임이다.

 

---

나의 해석과 회고

 

나 스스로가 클린한 코드를 짜내기 위해서 많은 노력을 하고 있다고 생각했다.

 

1장을 찬찬히 읽고 뒤를 돌이켜보면 클린한 척하려 노력하는 코드를 많이 짰던것 같다.

 

뒤에 주석과 관련된 이야기가 나오지만 의미없는 주석부터 시작해서 가장 큰 것은 한 번에 여러가지 일을 하려는 경향이 코드 곳곳에 숨어있기 때문에 한 가지를 명확히 하지 못했던것 같다.

 

언젠간 고치리라

 

 

위의 코드는 잘 돌아간다는 안도감으로 인해서 언젠간 고치리라 하며 절대 고치지 않았던 나의 과거를 볼 수 있다..

 

한 번에 여러가지를 그냥 한다.

 

/**
 * 사용자가 입력한 문제의 정답을 저장한다.
 *
 * @param userId : 요청을 보낸 사용자의 userId
 * @param quizId : 요청에 포함된 퀴즈의 quizId
 * @param request : 사용자의 정답 데이터
 * @param tokenUserId : 요청을 보낸 사용자의 userId
 */
public void solveEvaluationQuiz(Long userId,
                                Long evaluationId,
                                Long quizId,
                                SolveQuizRequestData request,
                                Long tokenUserId) {
    if(!userId.equals(tokenUserId)) { // 제출하는 userId 와 저장하려는 userId 가 다른 경우
        throw new AuthenticationFailedException();
    }

    boolean isMember = evaluationUserRepository.existsByEvaluationIdAndUserId(evaluationId, userId);

    if(!isMember) {
        throw new AuthenticationFailedException();
    }

    boolean evaluationExist = evaluationRepository.existsById(evaluationId);

    if(!evaluationExist) {
        throw new NotFoundException("테스트 " + evaluationId);
    }

    User user = userRepository.findById(tokenUserId).orElseThrow(
            () -> new NotFoundException("사용자 번호 " + tokenUserId));
    EvaluationQuiz evaluationQuiz = evaluationQuizRepository.findById(quizId).orElseThrow(
            () -> new NotFoundException("퀴즈 번호 " + quizId));

    Optional<QuizSubmit> submit = quizSubmitRepository.findByQuizIdAndUserId(quizId, userId);

    String answer = request.getAnswer();
    QuizSubmit quizSubmit;
    if(submit.isEmpty()) { // 기존에 제출한 정답이 없다면 새롭게 Submit 을 제출
         quizSubmit = QuizSubmit.builder()
                .answer(answer)
                .evaluationQuiz(evaluationQuiz)
                .user(user)
                .build();
    } else { // 기존에 제출한 정답이 있다면 그 정답을 업데이트
        quizSubmit = submit.get();
        quizSubmit.updateAnswer(answer);
    }

    quizSubmitRepository.save(quizSubmit);
}

 

이는 이전에 했던 프로젝트의 서비스 코드를 잠시 가져온 것이다.

 

solveEvaluationQuiz 라는 메서드는 도대체가 무슨 일을 하려는 것인지 알 수 없어보인다.

 

한 번에 여러가지 일을 하려고 했기 때문에 실질적인 비즈니스 로직이 감추어져 있었다.

 

코드를 보면 코드의 2/3 이 validation 하는데 진행되고 있고 실질적인 비즈니스 로직은 제일 아래에 6 ~ 8 줄 뿐이 되지 않는 것을 알 수 있다.