전체

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

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

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

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

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

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

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

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