Be Developer

양파마켓을 돌아보며

yujin_dev — Fri, 15 Apr 2022 01:27:08 +0900

안드로이드 공부 겸 취업 포트폴리오로 만들었던 당근마켓 클론 프로젝트인 '양파마켓'이 있다.

https://github.com/yujinK/onion-market

GitHub - yujinK/onion-market: 당근마켓 클론코딩

당근마켓 클론코딩. Contribute to yujinK/onion-market development by creating an account on GitHub.

github.com

지금 보면 정말 엉망진창 개발새발 그 자체인 프로젝트다.

(다시 다 뜯어 고치고 싶은 마음이 왕왕 드는 프로젝트....)

처음으로 깃허브에서 별을 받아본 프로젝트인데 전혀 예상 못했던 거라 놀라기도 했고 당황스럽기도 했다.

대체 어디서 보고 이 프로젝트에 별을 찍어주셨을까....?

깃허브에 검색해봐도 그렇게 상위에 뜨는 프로젝트는 아닌데 많은 숫자는 아니지만 너무 신기하다.

(전엔 되게 뒤에 있었는데 지금 검색하니 2페이지네...?)

이 프로젝트를 보고 사업을 구상 중이신 분이 메일로 도움을 요청하는 경우도 있었고 궁금한 점이 생겨서 메일을 주시는 분도 계셨다.

신입으로 회사에 다니면서 혼자서만 하던 개발에서 함께하는 개발을 조금씩 알아가는 중인데 메일을 받으면서도 느끼는 점이다.

도움을 요청하는 부분이 나는 아직 많이 약하다고 생각하는데 메일 주시는 분들을 보면서 배운다.

방금도 문의 메일을 받고 답변을 작성하면서 코드를 다시 보게 되었는데 정말.... 코드가 말잇못 상태.

그런데 이걸 보고 공부하는 분들도 있다고 생각하니 내가 그동안 작성한 코드, 그리고 앞으로 작성할 코드까지 책임감이 생긴다.

더 공부하고 더 좋은 코드를 만드는 개발자가 되어야지.

[클린 코드] 10장. 클래스

yujin_dev — Wed, 9 Mar 2022 17:50:18 +0900

2022. 03. 09

오늘 읽은 범위

10장. 클래스

책에서 기억하고 싶은 내용

- 클래스를 정의하는 표준 자바 관례 : 변수 목록 (static public 상수 -> static private 변수 -> private instance 변수) -> 공개 함수 -> 비공개 함수 (자신을 호출하는 공개 함수 직후) (p.172)

- 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다. (p.172)

- 클래스는 작아야 한다. (p.172)

- 클래스의 크기 측정 척도는 클래스가 맡은 책임이다. (p.173)

- 실제로 작명은 클래스 크기를 줄이는 첫 번째 관문이다. 간결한 이름이 떠오르지 않는다면 필경 클래스 크기가 너무 커서 그렇다. 클래스 이름이 모호하다면 필경 클래스 책임이 너무 많아서다. (p.175)

- 클래스 설명은 만일("if"), 그리고("and"), -(하)며("or"), 하지만("but")을 사용하지 않고서 25단어 내외로 가능해야 한다. (p.175)

- 단일 책임 원칙 Single Responsibility Principle, SRP 은 클래스나 모듈을 변경할 이유가 하나뿐이어야 한다. (p. 175)

- 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이루어진 시스템이 더 바람직하다. 작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다. (p.177)

- 응집도가 높아질수록 변수와 메서드를 적절히 분리해 새로운 클래스 두세 개로 쪼개준다. (p.178)

- 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다. (p.185)

- OCP Open-Closed Principle : 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다. (p.188)

- 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다. (p.188)

- 시스템의 결합도를 낮추면 재사용성도 더욱 높아진다. 결합도가 낮다는 소리는 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 잘 격리되어 있다는 의미다. 시스템 요소가 서로 잘 격리되어 있으면 각 요소를 이해하기도 더 쉬워진다. (p.190)

- DIP Dependency Inversion Principle : 클래스는 상세한 구현이 아니라 추상화에 의존해야 한다. (p.190)

오늘 읽은 소감

- 클래스에 대해 단단히 착각을 하고 있었다. 나는 여태 뭔가 클래스라면 덩어리로 있어야 한다고 생각했던 것 같다. 책을 읽지 않았다면 계속 그렇게 생각하지 않았을까? 예제에서 보여주는 한 줄짜리 클래스에 적잖이 충격을 받았다. 책임을 최대한 나누어 더 작은 클래스를 유지하도록 코드를 작성할 때 유념해야겠다.

- OOP에 대해 좀 더 자세히 공부해야 할 필요성을 느꼈다. 겉핥기로 알고 있다는 느낌이 들었고, 추상 클래스나 인터페이스에 대해서도 다시 공부해야겠다.

[클린 코드] 9장. 단위 테스트

yujin_dev — Mon, 7 Mar 2022 01:40:09 +0900

2022. 03. 06

오늘 읽은 범위
9장. 단위 테스트

책에서 기억하고 싶은 내용
- TDD 법칙 세 가지 (p.155)
   1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
   2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
   3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
- 문제는 실제 코드가 진화하면 테스트 코드도 변해야 한다는 데 있다. 그런데 테스트 코드가 지저분할수록 변경하기 어려워진다. 테스트 코드가 복잡할수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리기 십상이다. (p.156)
- 테스트 코드는 실제 코드 못지 않게 중요하다. (p.157)
- 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다. (p.157)
- 실제 코드를 점검하는 자동화된 단위 테스트 슈트는 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠다. (p.157)
- 깨끗한 테스트 코드를 만들려면? 세 가지가 필요하다. 가독성, 가독성, 가독성. (p.158)
- 명료성, 단순성, 풍부한 표현력이 필요하다. 테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다. (p.158)
- BUILD-OPERATE-CHECK 패턴
   BUILD : 테스트 자료를 만든다.
   OPERATE : 테스트 자료를 조작한다.
   CHECK : 조작한 결과가 올바른지 확인한다.
- 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다. 대개 메모리나 CPU 효율과 관련 있는 경우다. 코드의 깨끗함과는 철저히 무관하다. (p.164)
- given-when-then : 테스트 케이스를 작성하는 반 구조화된 방법 (p.165)
- TEMPLATE METHOD 패턴 : 알고리즘의 구조를 변경하지 않고 알고리즘의 특정 단계들을 다시 정의할 수 있게 해 줌 (p.165)
- “테스트 함수 하나는 개념 하나만 테스트하라” (p.167)
- F.I.R.S.T : 깨끗한 테스트의 다섯 가지 규칙 (p.167-168)
   빠르게 Fast : 테스트는 빨리 돌아야 한다.
   독립적으로 Independent : 각 테스트는 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야 한다.
   반복가능하게 Repeatable : 테스트는 어떤 환경에서도 반복 가능해야 한다.
   자가검증하는 Self-Validating : 테스트는 부울 bool 값으로 결과를 내야 한다.
   적시에 Timely : 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.
- 테스트 코드는 실제 코드만큼이나 프로젝트 건강에 중요하다. (p.168)
- 테스트 코드는 지속적으로 깨끗하게 관리하자. 표현력을 높이고 간결하게 정리하자. 테스트 API를 구현해 도메인 특화 언어 DSL를 만들자. 그러면 그만큼 테스트 코드를 짜기가 쉬워진다. (p.168)

오늘 읽은 소감
- TDD를 많이 들어보긴 했으나 아직까지 경험해보지 못했다. 그래서 그런지 이번 장은 코드 자체는 이해가 가더라도 이게 어떤 상황에서 어떻게 쓰이는지 정확하게 알기 어려웠다. 테스트 코드만 책 한 권 분량인 주제라고 하니 이런 겉핥기로 바로 이해하기는 어렵겠다는 생각이 들었다. 다음에 TDD에 대해 집중적으로 공부하고 다시 읽어보면서 이 부분을 채워나가자.
- 테스트 코드는 실제 코드만큼이나 중요하다는 글을 읽고 나니 다음 프로젝트를 진행할 때 TDD를 이용하여 진행해봐야겠다.
- 세상에는 정말 배울 게 산더미구나. 꾸준히 공부하다 보면 채워나갈 수 있겠지! 차근차근해나가다 보면 어느샌가 잘 쌓여진 내가 있을 거라고 생각한다. 하나씩 해보자!!

[클린 코드] 8장. 경계

yujin_dev — Mon, 7 Mar 2022 01:30:56 +0900

2022. 03. 06

오늘 읽은 범위
8장. 경계

책에서 기억하고 싶은 내용
- 학습 테스트는 프로그램에서 사용하려는 방식대로 API를 호출한다. 통제된 환경에서 API를 제대로 이해하는지를 확인하는 셈이다. 학습 테스트는 API를 사용하려는 목적에 초점을 맞춘다. (p.147)
- 학습 테스트를 이용한 학습이 필요하든 그렇지 않든, 실제 코드와 동일한 방식으로 인터페이스를 사용하는 테스트 케이스가 필요하다. (p.150)
- 통제하지 못하는 코드를 사용할 때는 너무 많은 투자를 하거나 향후 변경 비용이 지나치게 커지지 않도록 각별히 주의해야 한다. (p.152)
- 경계에 위치하는 코드는 깔끔히 분리한다. 또한 기대치를 정의하는 테스트 케이스도 작성한다. (p.152)
- 통제가 불가능한 외부 패키지에 의존하는 대신 통제가 가능한 우리 코드에 의존하는 편이 훨씬 좋다. (p.152)
- 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자. (p.152)

오늘 읽은 소감
- 학습 테스트와 Adapter 패턴에 대해 알게 되었다.
학습 테스트 : 간단한 테스트 케이스를 작성해 외부 코드를 익히는 것
Adapter 패턴 : 클래스의 인터페이스를 사용하기 원하는 다른 인터페이스로 변환하는 것. 어댑터를 이용하면 인터페이스 호환성 문제로 같이 쓸 수 없는 클래스를 연결하여 사용할 수 있다.
- API를 사용할 때 그냥 무작정 가져와서 코드에다 사용하고 있었는데 이렇게 분리하는 방법이 더 좋은 방법이라는 것을 알았다. 최대한 나의 코드와 외부의 경계를 구분지어 코드를 작성해보자.
- 코드를 깔끔하게 작성하기 위해 고려해야 할 부분이 정말 많다. 앞으로 코드를 작성할 때 이 책을 자주 들여다보며 좋은 코드를 작성할 수 있도록 노력하자.

[클린 코드] 7장. 오류 처리

yujin_dev — Sat, 5 Mar 2022 01:27:16 +0900

2022. 03. 04

오늘 읽은 범위

7장. 오류 처리

책에서 기억하고 싶은 내용

- 먼저 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다. 그러면 자연스럽게 try 블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워진다. (p.133)

- 오류 메시지에 정보를 담아 예외와 함께 던진다. 실패한 연산 이름과 실패 유형도 언급한다. 애플리케이션이 로깅 기능을 사용한다면 catch 블록에서 오류를 기록하도록 충분한 정보를 넘겨준다. (p.135)

- 실제로 외부 API를 사용할 때는 감싸기 기법이 최선이다. 외부 API를 감싸면 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다. 나중에 다른 라이브러리로 갈아타도 비용이 적다. 또한 감싸기 클래스에서 외부 API를 호출하는 대신 테스트 코드를 넣어주는 방법으로 프로그램을 테스트하기도 쉬워진다. (p.137)

- 흔히 예외 클래스가 하나만 있어도 충분한 코드가 많다. 예외 클래스에 포함된 정보로 오류를 구분해도 괜찮은 경우가 그렇다. 한 예외는 잡아내고 다른 예외는 무시해도 괜찮은 경우라면 여러 예외 클래스를 사용한다. (p.137)

- 특수 사례 패턴(Special Case Pattern) : 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식 (p.138)

- 메서드에서 null을 반환하고픈 유혹이 든다면 그 대신 예외를 던지거나 특수 사례 객체를 반환한다. 사용하려는 외부 API가 null을 반환한다면 감싸기 메서드를 구현해 예외를 던지거나 특수 사례 객체를 반환하는 방식을 고려한다. (p.139)

- 메서드에서 null을 반환하는 방식도 나쁘지만 메서드로 null을 전달하는 방식은 더 나쁘다. (p.140)

- 깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다. (p.142)

- 오류 처리를 프로그램 논리와 분리해 독자적인 사안으로 고려하면 튼튼하고 깨끗한 코드를 작성할 수 있다. 오류 처리를 프로그램 논리와 분리하면 독립적인 추론이 가능해지며 코드 유지보수성도 크게 높아진다. (p.142)

오늘 읽은 소감

- 예외 처리에 대한 부분을 소홀히 하고 넘어갔던 과거에 대한 반성을 하게 되었다. 그냥 try-catch로 끝내는 게 아니라 조금만 더 신경 쓰면 튼튼하고 깨끗한 코드를 만들 수 있다. 그냥 코드를 작성하는 것에 그치지 말고 생각을 좀 더 하면서 작성해보자.

- 특수 사례 패턴에 대해 처음 알게 되었다. 앞으로 코드를 작성하면서 이를 활용할 수 있는 부분이 생긴다면 적극적으로 활용해보자.

[클린 코드] 6장. 객체와 자료 구조

yujin_dev — Tue, 1 Mar 2022 21:10:28 +0900

2022. 03. 01

오늘 읽은 범위

6장. 객체와 자료 구조

책에서 기억하고 싶은 내용

- 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다. (p.119)

- 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다. 아무 생각 없이 조회/설정 함수를 추가하는 방법이 가장 나쁘다. (p.119)

- 객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다. 자료 구조는 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다. (p.119)

- 분별 있는 프로그래머는 모든 것이 객체라는 생각이 미신임을 잘 안다. 때로는 단순한 자료 구조와 절차적인 코드가 가장 적합한 상황도 있다. (p.122)

- 잡종 구조는 되도록 피하는 편이 좋다. 프로그래머가 함수나 타입을 보호할지 공개할지 확신하지 못해 (더 나쁘게는 무지해) 어중간하게 내놓은 설계에 불과하다. (p.125)

- (어떤) 시스템을 구현할 때, 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합하다. 다른 경우로 새로운 동작을 추가하는 유연성이 필요하면 자료 구조와 절차적인 코드가 더 적합하다. 우수한 소프트웨어 개발자는 편견없이 이 사실을 이해해 직면한 문제에 최적인 해결책을 선택한다. (p.128)

오늘 읽은 소감

- 절차적 프로그래밍과 객체 지향 프로그래밍에 대한 정확한 이해가 부족했다.

https://st-lab.tistory.com/151 해당 포스팅을 보고 두 개념에 대한 공부를 추가로 했다.

- 자바와 코틀린으로 코드를 작성하면서 정말 객체 지향적으로 코드를 작성하고 있었나...? 나 자신을 돌아보게 되었다. 앞으로는 객체 지향에 대한 것을 더 유념하며 코드를 작성해야겠다.

- 최악은 절반은 객체, 절반은 자료 구조인 잡종 구조이다. 코드를 작성하기 전 설계에 집중해보자.

[클린 코드] 5장. 형식 맞추기

yujin_dev — Tue, 1 Mar 2022 00:35:17 +0900

2022. 02. 28

오늘 읽은 범위

5장. 형식 맞추기

책에서 기억하고 싶은 내용

- 프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다. 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다. (p.96)

- 코드 형식은 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무다. (p.96)

- 소스 파일도 신문 기사와 비슷하게 작성한다. (p.98)

- 좋은 소프트웨어 시스템은 읽기 쉬운 문서로 이뤄진다는 사실을 기억하기 바란다. 스타일은 일관적이고 매끄러워야 한다. (p.114)

오늘 읽은 소감

- 아직 협업 경험이 부족하다보니 코드 형식을 맞추는 규칙을 정하고 그것을 따르는 것이 익숙하지 않아서 어서 경험해보고 싶다.

- 혼자 프로젝트를 많이 했지만 책에서 나오는 내용들을 거의 대부분 지키면서 코드 작성을 하고 있어 다행이라고 생각했다.

[클린 코드] 4장. 주석

yujin_dev — Sat, 26 Feb 2022 00:39:32 +0900

2022. 02. 25

오늘 읽은 범위

4장. 주석

책에서 기억하고 싶은 내용

- 나쁜 코드에 주석을 달지 마라. 새로 짜라. (p.68)

- 진실은 한 곳에만 존재한다. 바로 코드다. 코드만이 자기가 하는 일을 진실되게 말한다. 코드만이 정확한 정보를 제공하는 유일한 출처다. 그러므로 우리는 (간혹 필요할지라도) 주석을 가능한 줄이도록 꾸준히 노력해야 한다. (p.69)

- 표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가, 복잡하고 어수선하며 주석이 많이 달린 코드보다 훨씬 좋다. (p.69)

- 몇 초만 더 생각하면 코드로 대다수 의도를 표현할 수 있다. 많은 경우 주석으로 달려는 설명을 함수로 만들어 표현해도 충분하다. (p.70)

- 일반적으로 대다수 주석은 허술한 코드를 지탱하거나, 엉성한 코드를 변명하거나, 미숙한 결정을 합리화하는 등 프로그래머가 주절거리는 독백에서 크게 벗어나지 못한다. (p.75)

오늘 읽은 소감

- 내가 처음 프로그래밍을 배울 당시에는 주석을 자세히 달아라!라고 배웠었는데 나는 그게 습관이 잘 안 들어서 아직까지도 주석을 많이 달지 않고 좀 함수나 변수명을 구구절절 만드는 편이었다. 내가 하는 방법이 나쁜 방법은 아니었음을 알게 되어서 좋았다.

- 지금 달아 놓았던 몇 안 되는 주석들도 더 깔끔하게 처리할 수 있다니...! 새로운 시각으로 코드를 볼 수 있게 되었다.

[클린 코드] 3장. 함수

yujin_dev — Tue, 22 Feb 2022 08:00:41 +0900

2022. 02. 21

오늘 읽은 범위

3장. 함수

책에서 기억하고 싶은 내용

- 함수를 만드는 첫째 규칙은 '작게!'다. 함수를 만드는 둘째 규칙은 '더 작게!'다. (p.42)

- 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. (p.44)

- 함수가 확실히 '한 가지' 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다. (p.45)

- 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다. 즉, 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다. (p.46)

- "코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다." (p.49)

- 한 가지만 하는 작은 함수에 좋은 이름을 붙인다면 이런 원칙을 달성함에 있어 이미 절반은 성공했다. 함수가 작고 단순할수록 서술적인 이름을 고르기도 쉬워진다. (p.49)

- 함수에서 이상적인 인수 개수는 0개(무항)다. (p.50)

- 플래그 인수는 추하다. 함수로 부울 값을 넘기는 관례는 정말로 끔찍하다. 왜냐고? 함수가 한꺼번에 여러 가지를 처리한다고 대놓고 공표하는 셈이니까! 플래그가 참이면 이걸 하고 거짓이면 저걸 한다는 말이니까! (p.52)

- 가변 인수를 취하는 모든 함수에 같은 원리가 적용된다. 가변 인수를 취하는 함수는 단항, 이항, 삼항 함수로 취급할 수 있다. 하지만 이를 넘어서는 인수를 사용할 경우에는 문제가 있다. (p.54)

- 함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야 한다. 둘 다 하면 안 된다. 객체 상태를 변경하거나 아니면 객체 정보를 반환하거나 둘 중 하나다. 둘 다 하면 혼란을 초래한다. (p.56)

- try/catch 블록은 원래 추하다. 코드 구조에 혼란을 일으키며, 정상 동작과 오류 처리 동작을 뒤섞는다. 그러므로 try/catch 블록을 별도 함수로 뽑아내는 편이 좋다. (p.58)

- 오류 코드 대신 예외를 사용하면 새 예외는 Exception 클래스에서 파생된다. 따라서 재컴파일/재배치 없이도 새 예외 클래스를 추가할 수 있다. (p.60)

- 중복은 소프트웨어에서 모든 악의 근원이다. 많은 원칙과 기법이 중복을 없애거나 제어할 목적으로 나왔다. (p.60)

- 함수는 그 언어에서 동사며, 클래스는 명사다. (p.62)

- 진짜 목표를 시스템이라는 이야기를 풀어가는 데 있다는 사실을 명심하기 바란다. (p.62)

오늘 읽은 소감

- 플래그 인수 부분에서 과거 내 코드들이 머릿속으로 스쳐 지나갔다. 아찔하다. 플래그 인수는 다음부터 절대 사용하지 말고 함수는 한 가지만 잘하도록 만들자.

- 책을 읽기 전 함수는 최대한 쪼개는 게 좋다고 어디선가 스쳐지나가듯 봐서 그렇게 짜려고 노력하고 있었는데 길이가 짧은 함수들이 많아지니 이게 맞는 건가 하는 생각을 했었다. 오늘 그 해답을 들어 기분이 좋다.

- 계속 읽다보니 빨리 내 코드를 뜯어 고쳐서 리팩토링 하고 싶다는 생각이 간절해졌다. 하나씩 고쳐봐야겠다.

- 고수들은 코드를 작성할 때 처음부터 그냥 뚝딱뚝딱 만드는 줄 알았는데 서툴고 복잡한 코드를 다듬고 고쳐서 만든다는 걸 알았다. 사람은 다 똑같다. 처음부터 가능한 사람은 없다.

- 여기서도 완벽주의는 백해무익이라는 사실을 다시 깨닫는다. 처음부터 완벽하려고 하지 말자.

[클린 코드] 2장. 의미 있는 이름

yujin_dev — Sun, 20 Feb 2022 23:58:52 +0900

2022. 02. 20

오늘 읽은 범위

2장. 의미 있는 이름

책에서 기억하고 싶은 내용

- 의도를 분명히 밝혀라 (p.22)

- 프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다. 그릇된 단서는 코드 의미를 흐린다. 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다. (p.24)

- 서로 흡사한 이름을 사용하지 않도록 주의한다. (p.24)

- 유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다. (p.25)

- 컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라져야 한다. (p.26)

- 읽는 사람이 차이를 알도록 이름을 지어라. (p.27)

- 발음하기 쉬운 이름을 사용하라. (p.27)

- 검색하기 쉬운 이름을 사용하라. (p.28)

- 인코딩을 피하라. (p.29)

- 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다. (p.31-32)

- 클래스 이름과 객체 이름은 명사나 명사구가 적합하다. (p.32)

- 메서드 이름은 동사나 동사구가 적합하다. (p.32)

- 생성자를 중복정의할 때는 정적 팩토리 메서드를 사용한다. 메서드는 인수를 설명하는 이름을 사용한다. (p.32)

- 재미난 이름보다 명료한 이름을 선택하라. (p.32)

- 한 개념에 한 단어를 사용하라. (p.33)

- 한 단어를 두 가지 목적으로 사용하지 마라. (p.34)

- 프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다. (p.34)

- 모든 이름을 문제 영역에서 가져오는 정책은 현명하지 못하다. (p.34)

- 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다. 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다. (p.35)

- 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다. (p.35)

- 일반적으로는 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다. (p.37)

오늘 읽은 소감

- 코드를 작성할 때 변수명, 메서드명, 클래스명 다 의미 있는 이름을 사용하려고 생각하면서 지었었는데 그동안 잘해왔구나 생각하게 되었다. 내가 여태 해온 것들이 그래도 의미가 없진 않았구나 하는 생각. 하지만 부족한 부분들도 있어서 앞으로 코드 작성할 때 오늘 읽었던 부분을 조금 더 생각하면서 작성해야겠다.

- 역시 개발자는 혼자 하는 직업이 아니라 협업이 중요하구나 다시 한 번 깨닫는 계기가 되었다. 협업 경험이 부족한 나로써는 이런 부분에서 많은 것을 느끼지 못해서 아쉬웠다. 이것 저것 많이 경험해봐야지.