개발 방법론

불필요한 주석과 불필요해진 주석가치가 낮은 주석을 크게 두 가지로 나눌 수 있다고 생각 했습니다.불필요한 주석코드만으로 충분히 이해할 수 있는 내용을 중복 설명하는 주석불필요해진 주석복사, 붙여 넣기 또는 코드 변경으로 인해 더 이상 유효하지 않게 된 주석오해의 소지가 있어 코드 이해를 방해주석이 애플리케이션 코드 동작에 직접적인 영향을 주지 않지만, 가독성과 유지보수에 큰 영향을 미칠 수 있기 때문에 엄격하게 관리 될 필요가 있다고 생각 했습니다. 도메인에 대한 이해주석의 가치를 올바르게 판단하기 위해서는 서비스 도메인에 대한 깊은 이해가 선행되어야 합니다. 이것은 단순히 기술적인 관점에서 코드를 이해하는 것을 넘어, 그 코드가 왜 필요한지 안다는 것을 의미합니다.서비스 도메인에 대해 깊이 이해하면 다..

주석의 예상 독자컴퓨터 과학자로 구성된 팀 내 단 한 명의 생물학자라면 어떨까요?그렇다면 당연해 보이는 내용이더라도 코드를 생물학적 맥락으로 설명하는 것이 좋습니다.요점은 다른 사람의 관점에서 생각하고 예상되는 질문을 선제적으로 언급하려고 노력하는 것입니다.다른 사람의 관점에서 생각하고 예상하는 질문을 선제적으로 언급 해야 한다는 말에 깊이 공감하지만, 한편으로 켄트 벡은 주석의 예상 독자를 매우 광범위하게 설정하고 있다고 느꼈습니다. 실무에서 주석의 예상 독자는 동료 개발자로 한정하는 것이 보다 현실적이라고 생각 했습니다. 테스트 코드의 display name테스트 코드의 diaplay name 을 설명하는 주석의 한 형태로 볼 수 있다고 생각 했습니다. 코드를 직접 작성하지 않는 사람에게도 서비스에 ..

Monolithic 와 MSA‘여러 개의 작은 코드 조각’ 을 보고 ‘여러 개의 작은 서버’ 가 떠올랐습니다. ‘유지보수’ 관점에서 생각해 봤을 때, ‘유지’ 는 대체로 수월하지만, ‘보수’ 는 가끔 복잡할 때가 있었습니다. 특정 도메인의 트래픽 증가로 서버를 갑자기 증설해야 하는 경우 유연하게 대처할 수 있지만(=유지), 여러 도메인이 관여하는 기능 개선 및 확장 시(=보수)에는 제공하고자 하는 가치에 비해 작업 범위와 양이 많을 수 있습니다.그렇다고 해서 MSA 가 부적절하다는 것은 아니지만, 서비스 규모에 따라 서버를 어떻게 설계할지(=위치시킴, 배치) 고민이 필요하며, MSA 를 맹신하지(=작은 코드 조각으로 분리하는 일) 않도록 조심 해야겠습니다. 과도가 예리하다고 해서 소를 잡는데 사용하지 않..

과도한 메서드 추출메서드 추출을 과도하게 사용하면, 코드가 잘게 나뉘고 참조해 들어가는 메서드가 많아지기 때문에 오히려 코드를 이해하기 어려워질 수 있습니다. 지난번 인간이 단기적으로 기억할 수 있는 청크(chunk)가 4개 정도인 것으로 미루어 보았을 때, 과도한 메서드 추출은 지양해야 겠습니다. 그래서 적절한 수준에서 메서드를 추출해야 하고, 추상화 수준이 일관되게 유지되도록 하는 것이 중요하다고 생각했습니다. 추출한 메서드 이름 짓기메서드를 추출할 때, 그 메서드의 이름을 짓는 것도 매우 중요하다고 생각 했습니다. 그 메서드가 '어떻게' 동작하는지가 아닌, '왜 필요한지' 표현할 수 있어야 합니다. 예를 들어, 할인 금액을 계산하는 메서드를 추출했다고 가정 해보겠습니다.// '어떻게' 관점에서 지은..

전달하고 싶은 것설계를 바라보는 관점시스템 동작 변경과 구조 변경의 차이점군더더기를 없애자개요설계란 무엇인가?부적절한 가치 판단에 의한 낭비동작 변경과 구조 변경: 코드 정리와 작은 리팩토링군더더기 없는 코드를 위한 아기 발걸음코드 정리는 언제 해야 하는가?  설계란 무엇인가?설계란 소프트웨어의 구조를 정리하고 코드를 어디에 배치할지 결정하는 과정을 의미합니다. 이는 코드가 수행할 역할을 명확히 하여 코드를 특정 위치에 작성하는 행위 입니다.효율적이고 명확한 코드를 작성하기 위해서는 코드를 어떤 구조 안에서 배치할지 미리 계획하는 작업이 필요합니다. 부적절한 가치 판단에 의한 낭비켄트 벡은 XP(익스트림 프로그래밍)에서 “내가 가치 있게 생각하는 것과 정말로 가치 있는 것 사이의 차이에서 낭비가 생긴다”..

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

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

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