tidy first 11장 '비슷한 코드끼리' 를 읽고

여백에서 얻은 통찰을 바탕으로 시작하는 설계 최근 '설계란 무엇인가’에 대해 고민을 한 적이 있었습니다. ‘전체적인 시스템을 구상하는 것’, ‘애플리케이션이 동작하기 위해 어떤 개념을 차용하고 각 개념들이 어떻게 상호작용 할지 정의하는 것’ 등 다양한 관점에서 생각해 보았는데, 생각을 할수록 가장 낮은 수준에서 '이 코드를 어디에 위치할 것인가'에 대한 활동이라고 정의하게 되었습니다. 이 관점에서 비슷한 코드끼리 뭉쳐두는 행위 자체를 설계 활동이라고 할 수 있고, 그래서 설계라는 것이 큰 일이 아니라고 생각할 수 있었습니다. 빈 줄을 넣는 행위조차 코드의 위치가 바뀌는 것이기 때문에 (스스로 내린 정의 범위 안에서) 설계 활동이라 할 수 있기 때문입니다. 코드 사이에 빈 줄을 넣는 행위를 우리가 문장을 ..

• format_list_bulleted 독서/tidy first
• · 2024. 10. 21.
• textsms

tidy first 10장 '명시적인 매개변수' 를 읽고

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

• format_list_bulleted 독서/tidy first
• · 2024. 10. 18.
• textsms

tidy first 9장 '설명하는 상수' 를 읽고

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

• format_list_bulleted 독서/tidy first
• · 2024. 10. 14.
• textsms

tidy first 8장 '설명하는 변수' 를 읽고

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

• format_list_bulleted 독서/tidy first
• · 2024. 10. 14.
• textsms

나는 지금 XP 를 하고 있을까?

소프트웨어 개발을 하다 보면 특정 방법론을 선택하는 경우가 보통이다. 최근 접한 익스트림 프로그래밍(extreme programming, 이하 XP)은 애자일 방법론의 한 갈래로, 빠르게 변하는 요구사항에 대응하면서 높은 품질의 소프트웨어를 개발하기 위한 접근 방법이다. 특정한 하나의 방법론이 소프트웨어 개발의 만능 열쇠가 될 수 없겠지만, 최근 XP 책을 읽으면서 '그래서 뭐가 XP이고, 무엇을 기준으로 하고 있다고 할 수 있는 거지?' 라는 생각이 맴돌기 시작했다. 부분은 이해 했지만 전체를 이해하지 못한 느낌이다. (물론 책을 다 읽기 전이다.)  의사소통과 협업.XP 의 핵심 중 하나는 원활한 의사소통과 협업이다. 프로젝트가 진행 되는 동안 동료와 끊임없는 대화가 이루어져야 한다. 단순히 정보를 ..

• format_list_bulleted 독서/extreme programming
• · 2024. 7. 9.
• textsms