한칸짜리책상서랍

어깨 넓이로 나란히 걷기혼자 했다면 하지 않았을 고민이라는 생각을 했습니다. 물론 코드 정리와 동작 변경이 섞여 있는 PR 에 대해 무례함을 느끼는 부분에 대해서 입니다.개인적으로 잡화점을 여러바퀴 돌며 구경하는 것을 좋아 합니다. 분명 방금 보고 지나갔는데, 다시 보니 처음 보는 것들이 생기는 것이 꽤나 재미있기 때문입니다. 애플리케이션을 개발할 때도 잘 알고 있다고 생각한 코드임에도 변경 과정 (또는 디버깅 과정)에서 보다 깊이 있는 이해를 할 수 있고, 본문에서 말하는 새로운 발견을 하게 되는 경우가 많이 있었습니다. 문제는 ‘세 번째 선택지를 자유롭게 선택할 수 있는 여유가 주어지느냐’ 라고 생각 했습니다.고민 끝에 확실하다고 생각하는 큰 걸음을 내딛을 것인지, 당장 눈에 보이는 확신의 종종 걸음..

코드 정리와 동작 변경의 리듬 설계소프트웨어 설계를 프랙탈이라고 정의 내린 것이 인상 깊었습니다. 그 대상이 프랙탈인 것도 있지만, 명확하게 정의를 내렸다는 것이 인상 깊었습니다.리듬이라는 것이 사전적으로 일정한 규칙에 따라 반복되는 움직임을 뜻하는데, 하나의 동작 변경에 대한 사이클 내에서의 패턴으로 받아 들였습니다. 왜냐하면 그 크기와 처한 상황이 매번 다르고 변경에 대한 욕망이 생겼을 때 코드 정리와 동작 변경에 대한 패턴 즉, 리듬이 유효하게 작용 하겠다고 생각했기 때문입니다. 그래서 한편으로 변경에 대한 욕망이 없는 곳에 코드 정리는 건물 사이에 수많은 통행로를 만드는 일이라는 생각이 들었습니다.마지막으로 건물 사이에 잔디를 심은 사례를 통해, 실무 관점에서 실 사용자에 대한 데이터 분석이 중요..

비용 관리코드 변경과 통합은 애플리케이션 개발에서 피할 수 없고, 이 과정에서 적지 않은 비용이 발생합니다. 특히 코드 정리에 대한 검토 비용에 대해 생각해 보았습니다. 경우에 따라 다르겠지만, 변경 된 코드를 리뷰하고 통합하는 데 들어가는 시간과 노력은 결코 무시할 수 없습니다. 이러한 비용을 관리하지 못하면 작업 속도는 의미 없이 느려지고, 불필요한 곳에 에너지를 써서 결국 생산성을 떨어뜨립니다.이 문제를 조금이라도 해소하려면 코드 작업 단위를 작게 나누고, 자동화 도구 도입으로 프로세스를 최적화하는 것이 필요합니다. 작은 작업 단위는 검토 부담을 줄이고 충돌 가능성을 낮추는 데 효과적이고, 자동화 도구는 반복적이지만 실수할 수 있는 작업을 대신 처리함으로 불필요한 에너지 소모를 줄일 수 있습니다. ..

코드 정리는 인간적으로 챕터 16 ‘코드 정리 구분’ 에서 ‘변경은 변경을 낳는다.’ 라고 언급한 부분이 있었습니다. 여기서는 변경의 결과로 새롭게 변경 할 부분이 도출 된 상황이었다면, 이번에는 개인의 욕망에 의한 연쇄적인 변경을 얘기 하며 충동을 억제할 수 있어야 한다고 얘기 합니다.이번 챕터에서는 앞서 다룬 구체적인 코드 정리 실천 방법들에 대해 다시 한 번 언급하고 있습니다. 각각의 구체적인 방법에 대해서도 되뇌는 시간을 가질 수 있었는데, ‘그래서 이런 것들을 왜 해야하는가?’ 의문을 가지게 되었습니다.  코드를 정리하는 이유 중에는 ‘미래의 변화에 유연하게 대응하기 위함’ 이라는 것을 부정할 수 없을 것입니다. 변화에 유연하게 대응할 수 있다는 것은, 작성 된 코드를 어렵지 않게 이해할 수 있..

코드 변경의 복잡성과 인간적 요소자가 언급한 ‘볼썽사나운 모습’에서 기술적인 관점과 인간적인 관점을 동시에 다루고 있다고 느꼈습니다. 동작 변경과 코드 정리가 뒤섞인 상황은 기술적인 혼란스러움을, 그 속에서 팀원 간 부족한 신뢰로 인해 불평을 늘어놓는 인간적인 혼란스러움을 전달하고 있습니다. 특히 인간적인 면에서의 혼란스러움을 느꼈던 것은, 저자의 다른 저서인 XP(익스트림 프로그래밍)에서 다룬 인간성이 떠올랐기 때문입니다. 소프트웨어는 사람이 만드는 것이고, 보통의 경우 혼자 만드는 것이 아니기 때문에 인간성에 기반한 협업을 해야 겠다는 생각을 했습니다.  변경의 연쇄 반응과 테스트 코드의 중요성변경은 변경을 낳는다는 말에 공감 했습니다. 그리고 이런 연쇄 변경에 대해 두 가지 생각을 했습니다. 하나는..

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

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

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

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

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