클린코드 (Clean Code)

노마드 개발자 북클럽 1기 (22/02/10)
수강생 Today I Learned 기록 모음

9장. 단위 테스트

• 기억하고 싶은 책의 내용

  • 개발을 하며 모든 소프트웨어를 전부 직접 개발하는 경우는 드물다. 패키지 또는 오픈소스 또한 이용하는데, 이러한 외부코드들을 우리코드에 깔끔하게 통합해야 한다.

  • 인터페이스 제공자와 인터페이스 사용자의 사이에는 각자의 이해관계가 있다. 제공자는 최대한 범용성 있는 인터페이스를 제공하길 원하고 사용자는 사용자의 입맛에 맞는 인터페이스를 제공받길 원한다.

    • Map클래스의 사용 문제1

      • Map클래스를 사용하는 사용자라면 인터페이스가 제공하는 수많은 기능을 사용할 수 있다. 예를 들어보자면 Map 을 여기저기 사용하다 보면 Map의 기능 중 clear()메서드를 누구든지 사용가능하다는 뜻이다. 또한 지네릭스 이후로 Map에는 특정 객체유형만 저장하지 않으며, 마음만 먹으면 어떤 객체 유형도 추가할 수 있게 돼있다.

      • 경계 인터페이스인 Map을 해당 객체 안에 숨김으로써 해당 객체에서 어떤 클래스를 지네릭스로 사용할지 숨김과 동시에 지네릭스의 사용 주도권을 우리가 정의한 클래스에서 가져가도록 결정함으로 Map 인터페이스가 변하더라도 나머지 프로그램에 영향을 미치지 않게 할 수 있다.

      • 추가적으로 위처럼 구현한다면 Map인터페이스에서 우리가 필요한 기능만 제공하도록 캡슐화할 수 있다.

  • 학습 테스트 - 외부코드를 사용하면 시간대비 더 많은 기능을 출시하기에 유리하다. 하지만 외부코드를 사용하면서 해당 외부코드를 학습함과 동시에 발생가능한 문제를 대비해 해당 코드들을 우리가 테스트하는 편이 바람직하다.

    • 테스트하고 학습하고 캡슐화하라!2

  • 경계테스트를 활용한다면 기존 버전의 패키지에서 새로운 버전의 패키지로의 이전이 쉬워진다!-우리가 필요한 모든 테스트는 이전버전 패키지를 사용할 때 작성했던 테스트를 모두 통과해야하기에-

  • 아직 존재하지 않는 코드에 대한 인터페이스를 먼저 정의해둔다면, 우리가 인터페이스를 전적으로 통제한다는 장점이 생기며, 코드 가독성과 의도도 분명해진다.3

  • 소프트웨어 설계가 우수하다면 경계에서 변경하는데 많은 투자와 재작업이 필요하지 않다.

  • 경계에 위치하는 코드는 깔끔히 분리해야 한다.

  • - 책 내용 정리 / @친슈

• 소감 및 생각

  • 하지만 이런 테스트 코드를 작성하면서 힘들었던 점도 있었는데, 깨끗한 테스트 코드를 작성하는 것이었다. 테스트 코드를 처음 작성할 땐 테스트를 해야 하는 부분이 많지 않아서 고려하지 않아도 됐었지만, 프로젝트가 커지고 테스트를 해야 하는 범위가 넓어질 수록 테스트 코드도 깔끔하고, 재사용이 용이해야 새로운 테스트 케이스를 작성하기도 편했다. - @flynn

  • 테스트 코드가 깔끔한 것도 중요하지만 실제 코드보다는 그럴 필요 없다는 것에 동의한다. 개인적으로 테스트 코드 작성 보다는 실제 구현이 더 중요하다고 생각한다. (그렇다고 테스트 코드를 짤 필요가 없다는 것은 아니다!) 의미만 파악하면 된다. 만약 의미가 잘 와닿지 않는다면 주석을 달아도 괜찮겠다. - @붕빵

  • In the FIRST rule, the last one “T(Timely)” was the most important message for me. I’m glad that I understand the importance of TDD better now. - @Alison

10장. 클래스

• 기억하고 싶은 책의 내용

  • 클래스를 정의하는 표준 자바 관례에 따르면, 가장 먼저 변수 목록이 나온다.

    • 정적 static 공개 public 상수가 있다면 맨 처음에 나온다.

    • 정적 비공개 private 변수가 나오며,

      이어서 비공개 인스턴스 변수가 나온다

    • 공개 변수가 필요한 경우는 거의 없다. (??? 왜죠 ???)

    • 변수 목록 다음에는

      공개 함수가 나온다.

      비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다.

    • 즉 추상화 단계가 순차적으로 내려간다. (p. 172)

  • 클래스를 만들 때 첫 번째 규칙은 크기다. 클래스는 작아야 한다. 두 번째 규칙도 크기다. 더 작아야 한다. (p. 172)

  • 단일 책임 원칙은 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다. (p. 175)

  • 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다. 작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.(p. 177) ... 중략 ... 새로운 SQL문을 지원하려면 반드시 Sql 클래스에 손대야 한다. 기존 SQl문 하나를 수정할 때도 반드시 Sql 클래스에 손대야 한다. 이렇듯 변경할 이유가 두가지 이므로 Sql 클래스는 SRP를 위반한다. (p. 186)

  • OCP란 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다는 원칙이다.

  • 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다. (p.188)

  • - 책 내용 정리 / @이민호

• 소감 및 생각

  • 객체지향 5대원칙만 잘 지켜도 유지보수 하기 좋은 코드, 가독성 좋은 코드, OOP 코드를 만들수 있겠구나 다시 한 번 느꼈다. 읽을 때 마다 새롭고 깨닫게 되는 원칙인데 몇 번이고 곱씹어 내것으로 만들어야 겠다. - @빛의예술가

  • 핵심은 '돌아가는 소프트웨어'를 개발한 후 관심사를 '깨끗하고 체계적인 소프트웨어'로 돌리는 것이다. 이 두 단계를 거치면서 개발하지 않는다면 마지막에 남는 건 스파게티 코드이다. - @강민주

  • 어제와 오늘은 객체 지향의 핵심이라고 볼 수 있는 클래스에 대한 내용을 공부했다. 어제 읽은 부분은 하나의 책임만 맡을 수 있도록 함수/클래스를 쪼개는 방법에 대해 배웠다면, 오늘은 추상화를 통해 구현에 의존하지 않는 재사용성이 높은 클래스를 만드는 방법에 대해 배웠다. 특히 오늘 읽은 추상화 부분은 이름처럼 추상적이라 아직 100% 완벽하게 적용할 수 있겠다는 자신은 없다. 하지만 앞으로 내가 구현할 수많은 코드를 통해 더욱 잘 이해하고 활용할 수 있지 않을까 기대해본다! - @JIN

  • '요구사항이 변하면 코드도 변한다'이 말이 와닿는다. SI회사에서 일하는 친구가 한명있는데 그 친구가 항상 하는 말이 '시간이 부족해서 코드가 누더기가 된다'였다 자기도 원인을 알지만 그 원인을 원초적으로 수정할 시간이 없다는 말이다. 그 얘기를 들을 때에는 회사가 충분한 시간을 부여해주지 않았다고 생각했다 하지만 프로그래머들이 충분히 깨끗한 코드를 짜지 못했기 때문이기도 하다. 지금 그 굴레에서 벗어나지 못한다면 아마 영원히 더 복잡한 코드를 짜게 되는 날이 언젠간 올 것이다. 책의 초반부에서 말했든 의외로 책임자들은 불편한 진실을 좋아한다 이를 유념하도록 하자. - @Ayaan

노마드 개발자 북클럽이란?

한달에 1권! 개발자 필독서를 (니꼬쌤이랑) 다같이! 함께 읽는 북클럽 입니다. (심지어, 무료!)
곧 2기가 시작할터이니~ 대기자 리스트에 미리 신청해보세요!

• 📚https://nomadcoders.co/book-club