📅 TIL (Today I Learned): 2024.02.03
📋 오늘 읽은 범위: 5. 형식 맞추기
이틀 째는 과제를 내는 날이었다.
회사에서 월루를 하면서 풀려고 했는데 무슨... 뭘 어떻게 클린하게 짜라는 건지 감이 오지 않았다.
그래서 미루다가 약속을 가게 되었고, 결국 과제 제출을 못 하게 되었다.
오늘 책 읽기 전에 정답(예상 답안) url을 확인했는데 생각보다 리팩토링을 쉽게 하셨는데 나는 생각하지도 못 했다.
내가 책을 제대로 읽지 않았던 것인가? 약간의 의구심이 들었다.
😎 책에서 기억하고 싶은 내용을 써보세요.
코드 형식은 중요하다!
너무나도 중요하므로 융통성 없이 맹목적으로 따르면 안 된다.
코드 형식은 의사소통의 일환이다.
적절한 행 길이를 유지하라
- 개념은 빈 행으로 분리하라
- 세로 밀집도
- 서로 밀접한 코드 행은 세로로 가까이 놓아야 한다는 뜻
- 변수 선언: 변수는 사용하는 위치에 최대한 가까이 선언한다
- 인스턴스 변수: 인스턴스 변수는 클래스 맨 처음에 선언한다
- 종속 함수: 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다
- 개념적 유사성: 비슷한 동작을 수행하는 일군의 함수는 붙여놓는다
가로 형식, 들여쓰기 등은 크게 새로운 내용이 없어 보여서 정리하지 않았다
🥺 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.
요즘 새 프로젝트를 진행하면서 AA님께서 정해주신 코드 규칙이 존재한다.
그걸 문서화 하여 개발할 때마다 문서를 확인하고, 또 추가로 pmd 규칙도 체크 중이다.
가끔 개발을 할 때 이해되지 않는 규칙이 있는데 일단 정해진 규칙이니 지켜서 개발을 진행한다.
그러나 의구심은 버릴 수가 없다... 그래서 자괴감이 든다. 의구심을 갖고 있는 것 자체가 건방지다는 느낌을 지울 수가 없었다. 아직 몇 년 되지도 않은 개발자가 감히 AA님께서 설계하신 아키텍처와 개발 규칙에 반문을 제기한다는 것이...
그런데 오늘 '코드 형식은 의사소통의 일환이다.'라는 말을 들으니 내 의구심이 그렇게 나쁜 생각이 아닐 수도 있다는 생각이 들었다. 동시에 이런 규칙을 의사소통을 통해서 정했으면 더 좋았겠다는 아쉬움도 들었다.
🤔 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
누가 정해주지 않았지만 내 나름대로의 코드 규칙이 있다면, 하나의 클래스 내에 public 메서드와 private 메서드는 순서를 가진다는 것이다. public 메서드가 위로 올라가고 private 메서드는 아래로 내려간다.
그런데, public 메서드가 종종 private 메서드를 부를 때가 있다.
만약 public 메서드인 a가 private 메서드인 a-1을 부르고,
public 메서드인 b가 private 메서드인 b-1을 부를 때 나는 어떻게 정렬해야 될까?
현재는 a, b, a-1, b-1 순으로 정렬하고 있다.
그러나 책을 읽어보면 a, a-1, b, b-1 순으로 정렬을 해야 할 듯 하다.
그런데 이건 단순히 메서드가 4개만 있을 때의 일이다.
극단적으로 public 메서드가 a부터 z까지 있고, 각각 public에서 호출하는 private 메서드가 a-1부터 z-1까지 존재한다면 나는 과연 어떻게 정렬해야 할까?
