작게 만들어라: 중첩 구조가 생길만큼 함수가 커져서는 안되며, 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서는 안된다. -> 읽고 이해하기 쉬워지는 첫걸음.
한가지만 해라: 함수의 역할을 한가지로 제한하라.
함수 당 추상화 수준은 하나로 하라: 한 함수 내 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈릴 수 있다.(특정 표현이 근본 개념인지, 세부 사항인지 구분하기 어렵다-> 이를 섞으면 사람들이 함수에 세부사항을 점점 추가한다.😱so true)
switch문의 사용을 주의하기
서술적인 이름을 사용하기
함수 인수는 적을 수록 좋다. 많다면 많은 만큼의 적절한 이유가 필요하다.

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

학교 과제 컨벤션에서 한 함수를 만들때 가로 90자, 세로 25줄을 넘어가면 안되는 규정이 있었다. 이번 챕터를 읽으면서 그런 비슷한 규정이 어디서 왔는지 알게 된 것 같다!
Sparkle함수가 어떻게 짜였는지 정말 궁금한데 오리지널을 볼 수 없어 아쉽다…ㅠㅠ
이전에 코드 리뷰를 하면서 이런 리뷰를 받은 적이 있었다. ‘이 함수는 이 자료 업데이트도 하고, 이 변수가 undefined인지 아닌지도 체크하잖아. 그러니 함수 이름이 이게 맞지 않아’라고. 변수가 undefined인지 여부는 protection으로 넣어둔 것이라 그렇게까지 생각해보지 않았는데, 함수 이름을 봤더니 오해를 살만한 것이라고 느꼈다. (함수 이름만 봤을때 함수가 어떤 일을 하는지 정확히 알 수가 없음) 그래서 리팩토링을 하면서 변수 undefined여부는 바깥으로 빼고 자료 업데이트를 하는 함수로만 만든 뒤 이름을 바꿨다. 훨씬 이해하기 쉽고 함수 이해에 혼선이 없어졌다. 이전까지는 함수를 여러가지 인자들을 넣어 마지막에 짠하고 결과물만 만들어내는 정도로만 생각했었다. 어떻게 보면 멜팅 팟안에 재료를 다 넣고 그냥 섞기만 한다고 생각했다. 하지만 함수는 그것보다 더 투명하고 단순해야했다. 한번에 완벽한 함수를 만들지 못할지라도, 함수를 만들면서 항상 ‘이 함수가 하는 역할이 뭘까?’를 생각해보고 그 역할에 가까워지려고 하면 좀 더 깔끔한 함수를 만드는데 가까워질 거라고 생각한다.
‘이름이 길어도 괜찮다’, 제 마음을 읽으셨나요? ㅋㅋㅋㅋㅋ 진짜 딱 원하는 이름만 짓고자 하면 가끔 함수 이름이 어디로 가는 지 알 수 없게 길어지고 있다… 그러다가 머뭇머뭇 거리고 다시 지우고 하지만 한 번 쓴 이름은 뇌리에 박혀 떠나지 않는다… 사실 혼자 코드를 하면 괜찮은데 같이 코드를 하는 다른 사람들은 ‘이름이 길어도 괜찮다’에 대해서 어떻게 생각할지 궁금하다…
Try/Catch 블록이 뭔가 꺼림칙하게 싫고 안이뻤는데, 직접적으로 ’try/catch 블록은 원래 추하다’라고 말해줘서 마음이 편해졌다. (속이 편해지는 짤이 생각난다…)

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

SRP(Single Responsibility Principle): 컴퓨터 프로그래밍 원칙. 한 클래스는 하나의 책임, 하나의 목적만을 가지고 있어야한다.
OCP(Open Closed Principle): OOP에서, 소프트웨어 엔티티는 확장을 위해 열려 있어야 하지만, 수정에 있어서는 닫혀있어야 한다.

오늘 읽은 다른사람의 TIL

Jung5712057님의 TIL

글쓰기

노마드코더 이벤트노마드 코더, 강의 1:1 상담 해드려요~️⭐️📚 노마드코더 신간 안내 📚 IT 5분 잡학사전

# interview