오봉이와 함께하는 개발 블로그

컬렉션 : 중첩을 제거하는 구조화 테크닉 내 코드가 그렇게 이상한가요? 라는 책을 보고 내가 공부한 내용이나 생각한 내용에 대해 작성하는 글이다. 7장 컬렉션 : 중첩을 제거하는 구조화 테크닉을 읽고 생각하는 내용에 대해 적어보겠다. 단, 책 내용 중 별 내용 아니라 판단하면 생략하도록 하겠다. 컬렉션 처리를 캡슐화하기 위 내용을 공부하기 위해서는 선행으로 이전 내용을 알아야 좋을 거 같다. 컬렉션 객체에 대하여 특정 기능을 하는 메서드가 있고, 해당 메서드가 서로 다른 클래스에 중복으로 구현됐을 때 문제를 해결하는 방법에 대해 설명한다. 컬렉션과 관련하여 응집도가 낮아지면 일급 컬렉션 패턴을 사용해 해결할 수 있다. 일급 컬렉션은 컬렉션 관련된 로직을 캡슐화하는 디자인 패턴이다. 클래스에는 아래 두 가..

형식 맞추기 코드 형식을 맞추는 행위는 중요하다. 코드 형식은 가독성을 높이는데 있어 매우 중요하다 생각한다. 우리는 대부분 팀으로 일하기 때문에 팀 내부에서 약속을 정하고 모두 그 규칙에 따르는 등 형식을 맞춰야 같이 일하는데 잡음이 발생할 확률이 적다. 형식을 맞추는 목적 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 원래 코드는 사라질지라도 개발자의 스타일과 규율은 사라지지 않는다. 책에서 저자는 위와 같이 말한다. 내가 아무리 설명하는 것 보다 위 세 문장으로 정리하는 것이 더 효과적이라 판단..

주석 먼저 내 개인적은 생각을 말하면 주석 자체는 나쁘다는 생각을 하지 않는다. 단, 주석을 작성한다는 것은 어딘가 불친절하거나 코드로 설명하기 어려운 무언가가 있다는 것이고 그게 로직이라면 조금 문제의 여지가 있을 수 있다 생각한다. 혹은 잘못된 정보를 제공하는 주석 또한 문제가 있다고 생각한다. 언뜻 보기로는 책에서 주석은 나쁘다고 규정하는 듯 보이지만 특정 조건에서의 주석이 나쁘다고 보는듯 하다. 내가 이렇듯 주석을 무시하는 이유가 무엇이냐고? 거짓말을 하니까. 항상도 아니고 고의도 아니지만 너무 자주 거짓말을 하니까. 주석은 오래될수록 코드에서 멀어진다. 오래될수록 완전히 그릇될 가능성도 커진다. 이유는 단순하다. 프로그래머들이 주석을 유지하고 보수하기란 현실적으로 불가능하니까. 처음 주석은 좋은..

함수 이번 챕터는 함수를 어떻게 하면 가독성 좋게 잘 만들 수 있는지 알려준다. 이론적으로 무엇이 좋더라 에서 멈추는 것이 아니라 무작정 따라해보면 좋은 지침들을 통해 어떻게 좋은 함수를 만들 수 있는지 알려준다. 단, 무작정 따라하는 것은 좋지만 맹신하고 맹목적으로 추종하진 말자. 분명 예외 케이스도 있을 것이다. (https://www.youtube.com/watch?v=th7n1rmlO4I&ab_channel=%EC%BD%94%EB%94%A9%EC%95%A0%ED%94%8C) 작게 만들어라 책에서 첫 번째 규칙은 작게 만들라 한다. 구체적인 증거는 없지만 저자의 수십년간 경험을 통해 쌓인 빅데이터를 활용해 세운 규칙으로 보인다. 우테코 프리코스에서 주는 과제를 할 때는 함수의 길이가 15 줄을 넘지..

의미있는 이름 Robert C. Martin - Clean Code의 의미있는 이름 에 관한 내용을 보고 생각하는 내용을 적는다. 책을 보면서 적기 때문에 책을 같이 보고 있지 않다면 다소 불친절한 글이 될 수 있을 거 같다. 의도를 분명히 밝혀라 public class Member { int a; } int a 가 뭔지 알 수 있는 사람이 있을까? 코드 작성자도 한 달이 지난 후 보면 저 a를 사용하는 곳을 모두 찾아야 어떤 값인지 알 것이다. 변수명에서 어떠한 힌트도 얻을 수 없다. 혹시 저렇게 변수를 만들고 있는 사람이 이 글을 본다면 아래와 같이 명확한 이름을 사용하는 것이 어떤기? public class Member { int age; } 조금 더 복잡한 예제를 보자. public List ge..