Community

개발자 99% 커뮤니티에서 수다 떨어요!

← Go back
Assignment #02
#clean_code
2년 전
443

TIL (Today I Learned)

2022.02.19 토

오늘 읽은 범위

추천사 ~ 1장. 깨끗한 코드

책에서 기억하고 싶은 내용을 써보세요.

  • 추천사 - 덴마크 속담 [사소한 곳에서 발휘하는 정직은 사소하지 않다.] (p.xxii)

  • 회사가 망한 원인은 바로 나쁜 코드 탓이었다. (p.4)

  • 우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. (p.4)

  • 각 전문가들의 깨끗한 코드 정의(p.9 ~ )

    • 비야네 스트롭스트룹 - 우하하고 효율적인 보기에 즐거운 코드, 철저한 오류 처리

    • 데이브 토마스, 앤디 헌트 - 깨진 창문에 비유

    • 그래디 부치 - 가독성

    • 큰 데이브 토마스 - 다른 사람이 고치기 쉽다

    • 마이클 페더스 - 주의 깊게 작성한 코드

    • 론 제프리스

      • 모든 테스트를 통과한다.

      • 중복이 없다.

      • 시스템 내 모든 설계 아이디어를 표현한다.

      • 클래스, 메서드, 함수 등을 최대한 줄인다.

    • 워드 커닝햄 - 짐작한 기능을 수행하는 코드, 읽으면서 놀랄일이 없다.

  • 중복을 피하라. 한 기능만 수행하라. 제대로 표현하라. 작게 추상화하라. (p.14)

  • 우리는 저자다. 저자에게는 독자가 있다. 그리고 저자에게는 독자와 잘 소통할 책임도 있다. (p.17)

  • 코드를 읽는 시간 대 코드를 짜는 시간 비율이 10 대 1을 훌쩍 넘는다. (p.18)

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

  • 컴퓨터공학 전공을 하면서 운영체제를 강의하셨던 교수님의 과제가 생각났다. 항상 과제 리포트에 코드를 짠 후 각 함수에 대한 input과 output 그리고 간단한 설명을 적는 것이 기본이었다. 그 과제가 좋은 코드를 작성하는 방법 중 일부였다는 생각이 들었다.

  • 최근 신입사원 교육과정에서 Spring을 배웠다. 스프링의 주요 문법과 목적이 중복을 피하고 객체 생성을 줄여주는 방향이었다. 코드의 효율과 좋은 방향으로 가는 최신 기술의 목적성과 그 교육 시간이 떠올랐다.

  • 앞으로 회사에서 주요하게 생각하는 부분인 MSA 에 관한 것도 생각이 났다. MSA를 하려면 깨끗한 코드, 좋은 코드가 분명히 필요하다. Java를 사용하고 있기 때문에 이 책이 도움이 많이 될 것이라 본다.

  • 개발자로 일을 시작하면서 지난 프로젝트 등에서 내가 짜왔던 코드들이 최근에 생각이 많이 났다. 분명히 그때는 좋은 코드를 작성했다고 생각했던 것들도 있었고, 짜면서도 아니라고 생각했던 것들도 있었다. 하지만 지금 생각해보면 전부 다 Clean Code는 아니였던 것 같다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

  • TDD(Test-driven Development) - 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스

    • 위키 피디아 링크 - https://en.wikipedia.org/wiki/Test-driven_development

    • 순서

      • 1. Add a test

      • 2. Run all tests. The new test should fail for expected reasons

      • 3. Write the simplest code that passes the new test

      • 4. All tests should now pass

      • 5. Refactor as needed, using tests after each refactor to ensure that functionality is preserved

  • TPM(Total Productive Management)의 5s 원칙

    • 정리 또는 조직(정렬)

    • 정돈 또는 단정함(체계화)

    • 청소 또는 정리(광내기)

    • 청결 또는 표준화

    • 생활화 또는 규율

  • Lean - 감기약???

  • 르블랑의 법칙? (LeBlanc's Law states) - "Later equals never" is used in the context of software development, but may be applied more broadly to other areas. The law is attributed to Dave LeBlanc.

  • 프리퀼 (prequel) - 전편(이전편)

나중에 읽을 책

소프트웨어 개발의 지혜 (2004 야스미디어, 이용원 외 옮김)