2024.01.30

기억하고 싶은 내용

• 작게 만들어라!
  • 함수를 만드는 규칙
    1. 작게
    2. 더 작게
  • 그만큼 작은 함수가 좋다는 의미로 적혀있다.
    • 코드를 최대한 작게 해서 가독성을 올리면 물론 좋은점이 훨씬 많다, 하지만 함수에 너무 많은 추상화가 되어있거나, 너무 잘게 쪼개진 함수를 일일히 찾아가면서, 확인하는건 조금 어려울 수도 있다.
    • 무조건적으로 나누기보다는 최소한의 코드의 흐름을 파악 할 수 있을 정도로 분리하거나, 재사용 할 부분을 생각해서 나누면 앞으로 코드 짜는게 훨씬 재밌어 질 것이다.
• 한 가지만 해라!
  • 함수는 한가지만 해야 한다 ( 전적으로 동의한다. )
    • 한 함수에 여러가지 일이 생기면 오히려 유지보수가 힘들다, 이건 추상화의 문제가 아니라, 무조건 분리를 해야 한다.
  • 한 함수 내에 추상화 수준이 섞이면 코드를 읽는 사람이 헷갈린다.
• 위에서 아래로 코드 읽기: 내려가기 규칙
  • 코드는 위에서 아래로 이야기처럼 읽혀야 좋다, 이는 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 오게끔 프로그램을 설계 해야한다.
    • 위에 내가 실무에서 느꼈던 바와 같이, 너무 많은 추상화를 하게 될 시 오히려 코드가 안읽히는 현상을 얘기 하는거 같다.
• 서술적인 이름을 사용하라!
  • 길고 서술적인 이름이 짧고 어려운 이름보다 좋다.
• 가급적 인자는 적은게 좋다.
  • 인자를 적을때, 객체를 사용해서 이름( 책에서는 class )을 알려주면, 그 함수에서 어떠한 표현을 하고 있는지 추론하기 더 쉽다.
• 반복하지 마라! ( DRY )
  • 반복되는 코드는 유심히 지켜봐야 한다.
  • 사실 그 반복이 현재에서만 반복이 되는지에 대한 판단도 필요하다.
  • 앞으로 이 함수에 방향성이 달라질수도 있기 때문 ( 우연한 중복 )

소감

• ‘글짓기’
  • 소프트웨어를 짜는 행위는 글짓기와 비슷하다라는 생각은 요즘 많이 해보고 있다.
  • 이 코드의 추상화, 클린코드, 리팩토링에 문제가 아닌, 이 코드를 잘 읽고 해석 할 수 있는지, 중간 중간 주석은 글에 대한 각주라고 생각하여 가이드 라인을 제공 해주는것도 꼭 나쁘지 않다고 생각한다.
  • 우리를 좀 더 풍부하고 표현력이 강한 이야기를 풀어가야 하는 프로그래머가 되어야 하니까 말이다.
  • 규칙에 따르면, 길이가 짧고, 이름이 좋고, 체계가 잡힌 함수로 정의 되어 있지만, 마케팅 언어에서도 있듯이, 내가 작성한 함수(코드)를 ‘초등학생에 말하듯 하라’ 에서와 같이 사실 진짜 목표를 더 편하게 읽고 쓰임이지 않을까 생각한다.