한칸짜리책상서랍

명시적인 매개변수와 인지 능력  흔히 함수(또는 메소드)의 시그니처라고 하면, 이름과 매개변수 리스트를 뜻합니다. 그리고 시그니처는 일반적으로 그것을 대표하는 특징이라고 할 수 있습니다. 다시 말해서 그 함수가 무엇을 하는지 한줄로 표현한 것으로 이해할 수 있습니다. 그렇기 때문에 더욱 명시적인 매개변수를 사용하는 것이 중요하다고 생각 했습니다. 함수(또는 메소드)의 시그니처는 이름과 매개변수 리스트를 의미하며, 이것은 그 함수의 대표적인 특징을 나타냅니다. 즉, 함수가 무엇을 하는지를 한 줄로 설명하기 때문에, 매개변수를 명시적으로 사용하는 것이 무엇을 하는 함수인지 전달하는 데 중요한 역할을 합니다. 명시적인 매개변수의 중요성에 대해 고민하다가, "얼마나 많은 매개변수를 나열해도 괜찮은가?"라는 현실..

ONE = 1 이라는 예시를 보고 '내가 만약 그런 코드를 마주했다면' 을 가정하고 생각 해봤습니다. 1. 이 코드를 작성한 사람이 표현력이 부족하더라도 상수화를 통해 무엇인가를 표현하려 했다. 2. 미래의 독자를 염두에 두고 코드를 작성하려는 사람일 수 있겠다. 3. 애플리케이션 전반에 걸쳐 코드 스타일을 일관성 있게 유지하려 노력한다. 4. 용어는 모르더라도 '매직 넘버' 가 무엇인지 개념적으로 알고 있다. 물론 각각의 생각에 부정적인 꼬리가 달리기도 합니다. 1. 표현력이 부족하여 이 사람이 작성한 코드 문맥을 이해하는데 어려움이 있을 수 있겠다. 2. 오버 엔지니어링이 습관이 되어있을 수 있겠다. 3. 융통성이 없을 수 있겠다. 4. 경험은 있지만 이론적으로 정립이 되어있지 않아 작성한 코드마다 ..

잊지 않으려고 노력하는 말이 있습니다. 그 자체로 설명이 가능하다는 것을 뜻하는 'self-descriptive' 와 '코드 자체가 문서가 되게 하라' 는 말 입니다. 말 자체에 대한 이해는 어렵지 않게 할 수 있지만, 보통 현실은 이론과 다른 경우가 많아 실무에 적용하는 것을 또 다른 문제라고 생각 합니다. 항상 같은 텐션을 유지하기란 쉽지 않고, 변경 사항에 대해 동기화를 유지하는 것도 쉬운 일은 아니라고 생각 합니다. 지금까지 그래왔던걸 봐왔기 때문이기도 합니다. 다양한 이유로 의미 없이 남게 된 주석들과 사용하지 않는 코드들이 가득한 레거시가 되고, 이것들은 가독성을 해치고 더 나아가 단순히 읽어 내려가기 어려운 수준을 넘어 오개념을 심어주기도 합니다. 그래서 특히, 2장 '안 쓰는 코드' 에서 ..