ddukddak.log

[클린코드] 13. 동시성

Thu, 28 Jul 2022 03:44:19 GMT

TIL (Today I Learned)

2022.05.26

오늘 읽은 범위

동시성

📖 책에서 기억하고 싶은 내용을 써보세요.

동시성과 깔끔한 코드는 양립하기 어렵다. 다중 스레드는 시스템이 부하를 받기 전까지 멀쩡하게 돌아간다.
동시성이 필요한 이유? 동시성은 결합(coupling)을 없애는 전략이다. 즉, 무엇(what)과 언제(when)를 분리한다.
웹 컨테이너가 제공하는 결합분리(decoupling )전략은 완벽과 거리가 아주 멀다. So, 서블릿 프로그래머는 동시성을 정확히 구현하도록 각별한 주의와 노력 요구. But, 그럼에도 서블릿 모델이 제공하는 구조적 이점은 아주 크다.
대량으로 분석하는 시스템, 모든 정보를 처리한 후에 최종적인 답을 냄. ** → 정보를 병렬로 처리하면 시스템 반응 시간 빨라짐.**
- ex 1 ) 웹 사이트에서 정보를 가져와 요약하는 정보 수집기 매일 실행하므로 24시간 안에 끝나야 함. 웹 사이트를 계속 추가할 수록 정보 수집하는 시간도 늘어남. → 단일 스레드 수집기는 웹 소켓에서 입출력을 기다리는 시간이 아주 많다. 한 번에 한 사이트를 방문하는 대신 다중 스레드 알고리즘을 이용하면 수집기 성능을 높일 수 있다.
- ex 2 ) 한 번에 한 사용자를 처리하는 시스템 1user / 1sec → 사용자 수가 늘어날수록 시스템이 응답하는 속도도 늦어짐. ⇒ 많은 사용자를 동시에 처리하면 시스템 응답 시간을 높일 수 있다.

동시성 미신과 오해
1. 동시성은 항상 성능을 높여준다. (X) 때로 성능을 높여준다. (O) → 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만 성능이 높아진다.
2. 동시성을 구현해도 설계는 변하지 않는다. (X) 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다. (O) → 단일 스레드 시스템과 다중 스레드 시스템은 설계가 판이하게 다르다
3. 웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다. (X) → 실 컨테이너 동작과 문제 해결방법을 이해해야 한다. (동시수정 해결법, 데드락 등)
4. 동시성은 다소 부하를 유발한다.
5. 동시성은 복잡하다.
6. 동시성은 버그를 제현하기 어렵다. (→ 일회성 문제로 여겨 무시하기 쉽다.)
7. 동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 한다.

동시성 방어 원칙
1. 단일 책임 원칙Single Responsibility Principle, SRP : 동시성 코드는 독자적인 개발, 변경, 조율 주기가 있음. → 동시성 코드와 다른 코드는 분리.
2. 따름 정리corollary: a. 자료 범위를 제한하라. : 자료를 캡슐화(encapsulation ) & 공유 자료를 최대한 줄이기.
  
  b. 자료 사본을 사용하라 : 공유 객체를 피하는 방법 → 코드가 문제를 일으킬 가능성도 낮아짐. (ex.객체를 복사해 읽기 전용으로 사용.) if, 복사하는 시간과 부하가 걱정 → 진짜 문제인지 실측 필요. but, 내부 잠금을 없애 절약한 수행 시간이 사본 생성과 가비지 컬렉션에 드는 부하를 상쇄할 가능성이 크다.
  1. 스레드는 가능한 독립적으로 구현하라
    
    : 독자적인 스레드로, 가능하면 다른 프로세서에서, 돌려도 괜찮도록 자료를 독립적인 단위로 분할.
3. 라이브러리를 이해하라
실행 모델을 이해하라
- 생산자-소비자 (Producer-Consumer) : 하나 이상 생산자 스레드가 정보를 생성해 버퍼buffer나 대기열queue에 넣는다. 하나 이상 소비자 스레드가 대기열에서 정보를 가져와 사용.
  - 대기열 = 한정된 자원 #
- 읽기-쓰기 (Readers-Writers) :읽기 스레드를 위한 주된 정보원으로 공유 자원을 사용, 쓰기 스레드가 공유 자원을 이따금 갱신.
  - 처리율(throughput)이 문제의 핵심
  - 처리율을 강조하면 → 기아starvation 현상 / 오래된 정보가 쌓인다. 갱신을 허용하면 → 처리율에 영향을 미친다

동기화하는 부분을 최대한 작게 만들어라 : synchronized를 사용하면 락을 설정한다. 같은 락으로 감싼 모든 코드 영역은 한 번에 한 스레드만 실행이 가능하다.
- 락은 스레드를 지연시키고 부하를 가중시킨다.
- synchronized를 남발하는 코드는 바람직하지 않다.
- 임계영역은 반드시 보호. So, 임계영역 수 최소화.
  - 주의_ 하나의 거대한 임계 영역으로 통합하면 안됨. → 이 영역을 사용하려고 하는 스레드도 늘어남. → 경쟁으로 이어지고 → 성능이 떨어지기 때문이다. (p. 236)
스레드 코드 테스트 하기
- 문제를 노출하는 테스트 케이스 작성. (프로그램 설정, 시스템 설정, 부하 바꿔가며 자주 돌려라)
- 랜덤한 상황을 넣고 주기적으로 테스트를 진행해라. 스레드 코드는 다시 테스트 할 때는 성공하는 경우가 있을 수 있다. 그렇다고 해서 넘어가지 말고 원인을 꼼꼼히 파악하길 바란다.
- 시스템 실패를 ‘일회성’이라 치부하지 마라.
  - 일회성 문제란 존재하지 않는다고 가정하는 편이 안전하다. ‘일회성’ 문제를 계속 무시한다면 잘못된 코드 위에 코드가 계속 쌓인다.

결론

다중 스레드 코드를 작성시, 주의하지 않으면 알 수 없는 오류에 직면할 수 있다.

SRP 준수: 스레드를 아는 코드와 스레드를 모르는 코드를 분리.

테스트 할 때 스레드 코드를 테스트 할 때에는 스레드만 테스트한다.
즉 스레드 코드는 최대한 집약되고 작아야 한다. # 동시성 오류를 일으키는 잠정적인 원인을 철저히 이해해야 한다.
여러 스레드가 공유 자료를 조작하거나 자원 풀을 공유할 때 동시성 오류가 발생한다.
루프 반복을 끝내거나 프로그램을 깔끔하게 종료하는 등 경계 조건의 경우 더 까다로우므로 특히 주의해야 한다. # 사용하는 라이브러리와 기본 알고리즘을 이해한다.
특정 라이브러리 기능이 기본 알고리즘과 유사한 어떤 문제를 어떻게 해결하는지 파악한다. # 보호할 코드 영역을 찾아내는 방법과 특정 코드 영역을 잠그는 방법을 이해한다. 또 공유하는 정보와 공유하지 않는 정보를 정확하게 이해한다.
잠글 필요가 없는 코드는 잠그지 않는다.
잠긴 영역에서 다른 잠긴 영역을 호출하지 않는다.
공유하는 객체 수와 버위를 최대한 줄인다.
클라이언트에게 공유 상태를 관리하는 책임을 떠넘기지 않는다.

공유하는 정보: 공유하는 객체 수와 범위를 최대한 줄인다.

일회성 문제는 대개 시스템에 부하가 걸릴 때나 아니면 뜬금없이 발생한다. 그러므로 스레드 코드는 많은 플랫폼에서 많은 설정으로 반복해서 계속 테스트해야 한다.

🐱‍👓 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

안드로이드 블루투스 페어링 관련해서 작업하면서 java 스레드로 애먹었던 기억이 있어, 책에서 복잡한 거라고 말해줘서 고마웠다.. (나만 힘든게 아니었어-!)
이번에도 이해하려고 애썼지만 조금 어려웠다. 그래도 최대한 안드로이드 플젝 할 때의 기억과 js 상황(맞는진 모르겠지만 유사하다고 생각한 비동기 처리)에 대입해 보고자 하며 읽어보았다.
기능 구현하는 것도 어려운데.. ㅋㅋ 테스트코드 워후-! 할수있어...!

(feat.동기화 단위를 최소화하라. 그러면 조금 낫다.)
starvation, 페어링 구현하면서 경험해본적 있었다.. 개념에 대한 용어를 알고 생각해보니 생산자-소비자 모델이었는데, 생산자에서 오류가 발생하면 스레드 종료 처리를 해주지 못해 오류가 발생하는 상황이었다. 검색도 하고 선배 개발자 분에게 조언을 얻어 해결하긴 했었는데, 이번에 책을 읽으면서 다시 곱씹어 보니 당시 상황을 복기해보니 좀 더 이해가는 부분이 있었다.

🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

‘서블릿Servlet’ 모델
- 서블릿: 웹 혹은 EJB 컨테이너라는 우산 아래서 돌아가는데, 이들 컨테이너는 동시성을 부분적으로 관리. 웹 요청이 들어올 때마다 웹 서버는 비동기식으로 서블릿을 실행함.
결합분리(decoupling )전략
EJB 컨테이너
데드락

: 여러 스레드가 서로가 끝나기를 기다린다. 모든 스레드가 각기 필요한 자원을 다른 스레드가 점유하는 바람에 어느 쪽도 더 이상 진행하지 못함.
JIT (Just In Time) 컴파일러

[클린코드] 12. 창발성

Thu, 28 Jul 2022 02:21:15 GMT

TIL (Today I Learned)

2022.05.19

오늘 읽은 범위

창발성

📖 책에서 기억하고 싶은 내용을 써보세요.

모든 테스트를 실행하라 ▪ 설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다. ▪ 테스트가 불가능한 시스템은 검증도 불가능 ▪ 테스트 케이스를 많이 작성할수록 도구를 사용할 수록 아래의 이점이 있음. (도구; DIP, 의존성 주입 (DI), 인터페이스, 추상화)

1) 낮은 결합도와 높은 응집력 2) 설계 품질이 높아짐. → 객체 지향 방법론이 지향하는 목표를 저절로 달성
리팩터링 순서)
```
 1. 테스트 케이스 작성 
```
1. 코드와 클래스 정리
2. 코드추가
3. 잠시 멈추고 설계를 조감
중복을 없애라 ▪ 중복 === 추가 작업, 추가 위험, 불필요한 복잡도 ▪ 구현 중복 포함
표현하라 ▪ 소프트웨어 프로젝트 비용 중, 대다수는 장기적인 유지보수. ▪ 시스템이 점차 복잡해지면서 유지보수 개발자가 시스템을 이해하느라 보내는 시간은 점점 늘어나고 동시에 코드를 오해할 가능성도 점점 커진다. ▪ 코드는 개발자의 의도를 분명히 표현해야 한다. 개발자가 코드를 명백하게 짤수록 다른 사람이 그 코드를 이해하기 쉬워진다. ⇒ 결함감소 & 유지보수 비용 절감.
클래스와 메서드 수를 최소로 줄여라 ▪ SRP를 준수한다는 개념도 극단으로 치달으면 득보다 실이 많아진다. ex. 클래스와 메서드 크기를 줄이자고 조그만 클래스와 메서드를 수없이 만드는 사례 ▪ 함수와 클래스 크기를 작게 유지하면서 동시에 시스템 크기도 작게 유지.

🐱‍👓 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

이쯤되니 책에서 계속해서 반복해 말하는 것들이 눈에 뜬다. 저자가 중요하게 말하고자 하는 개념이 뭔지 명확해 졌다. 좋은 이름, 크기랑 중복 줄이기, 단위테스트.. 이제 절반이상 읽었는데 지금까지 배운내용을 양분삼아 리팩토링 공부로 이어 나가면 되겠다.

🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

창발 : 떠오름 현상은 하위 계층(구성 요소)에는 없는 특성이나 행동이 상위 계층(전체 구조)에서 자발적으로 돌연히 출현하는 현상

[클린코드] 11. 시스템

Mon, 25 Jul 2022 05:31:34 GMT

TIL (Today I Learned)

2022.05.19

오늘 읽은 범위

시스템

#

책에서 기억하고 싶은 내용을 써보세요.

시스템 제작과 시스템 사용을 분리하라 (p.194)

SW는 준비 과정과 런타임으로 로직을 분리해야 한다.
- 준비 과정: 애플리케이션 객체를 제작하고 의존성을 서로 ‘연결’ 하는 로직
- 런타임: 준비 과정 이후에 이어지는 로직

관심사 분리
초기화 지연Lazy Initialization (계산 지연Lazy Evaluation) 기법
1. 실제로 필요할 때까지 객체를 생성하지 않으므로 불필요한 부하가 걸리지 않는다.
2. 애플리케이션을 시작하는 시간이 그만큼 빨라진다.
3. 어떤 경우에도 null 포인터를 반환하지 않는다.
Main 분리
- 생성과 관련한 코드: main이나 main이 호출하는 모듈로 이동.
- 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정.
  
  애플리케이션은 main이나 객체가 생성되는 과정을 전혀 모른다.

팩토리
- 때로는 객체가 생성되는 시점을 애플리케이션이 결정할 필요 有.
- 생성시점은 결정가능하나, 생성하는 코드는 애플리케이션이 알 수 없음.

의존성 주입 (DI, Dependency Injection)
- 제어역전) 한 객체가 맡은 보조 책임 → 새로운 객체에게 전적으로 떠넘긴다. (SRP 지켜짐)
- 의존성 관리) 맥락에서 객체는의존성 자체를 인스턴스로 만드는 책임은 지지 않는다. 대신에 이런 책임을 다른 ‘전담’ 메커니즘에 넘겨야만 한다.
확장
- 성장할지 모른다는 기대로 비용을 정당화할 수 있을까? → NO.
- ‘처음부터 올바르게’ 시스템을 만들 수 있다는 믿음은 미신이다.
  
  오늘 주어진 사용자 스토리에 맞춰 시스템을 구현해야 한다. 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다. ⇒ 이것이 반복적이고 점진적인 애자일 방식의 핵심.
- 시스템 아키텍처는 사전 계획이 필요하지 않을까.
  
  → ‘단순한 아키텍처를 복잡한 아키텍처로 조금씩 키울 수 없다’는 맞는 말 아닌가? NO.
  
  → 시스템은 수명이 짧아, 점진적으로 발전할 수 있다. YES.

자바 프록시
- 단순한 상황에 적합
- ex. 개별 객체나 클래스에서 메서드 호출을 감싸는 경우
- 단점1) 코드가 상당히 많고 복잡함. → 깨끗한 코드 작성 어려움
- 단점2) 시스템 단위로 실행 ‘지점’을 명시하는 메커니즘도 제공하지 않음. (AOP 위반)
POJO 장점
- (엔터프라이즈)프레임워크 & 도메인에 의존하지 않음.
- 테스트가 개념적으로 더 쉽고 간단.
- 상대적으로 단순하기 때문에 사용자 스토리 구현 쉬움. → 미래 스토리에 맞춰 코드를 보수하고 개선하기 편리.
테스트 주도 시스템 아키텍처 구축
BDUF (Big Design Up Front) → Not GOOD.
- 정의) 구현을 시작하기 전에 앞으로 벌어질 모든 사항을 설계하는 기법.
- 단점) 처음에 쏟아 부은 노력을 버리지 않으려는 심리적 저항으로 인해, 그리고 처음 선택한 아키텍처가 향후 사고 방식에 미치는 영향으로 인해, 변경을 쉽사리 수용하지 못함.
‘아주 단순하면서도’ 멋지게 분리된 아키텍처로 소프트웨어 프로젝트를 진행해 결과물을 재빨리 출시한 후, 기반 구조를 추가하며 조금씩 확장해 나가도 괜찮다.

프로젝트를 시작시 생각할 것
- 일반적인 범위,
- 목표, 일정
- 결과로 내놓을 시스템의 일반적인 구조도
- 변하는 환경에 대처해 진로를 변경할 능력도 반드시 유지.
의사 결정을 최적화하라
때때로 가능한 마지막 순간까지 결정을 미루는 방법이 최선이다.
- 최대한 정보를 모아 최선의 결정. / 성급한 결정은 불충분한 지식으로 내린 결정
- 너무 일찍 결정하면 고객 피드백을 더 모으고, 프로젝트를 더 고민하고, 구현 방안을 더 탐험할 기회가 사라진다.
관심사를 모듈로 분리한 POJO 시스템은 기민함을 제공한다.
- 기민성, 기민함 in 시스템
  
  p.211) 최신 정보에 기반해 최선의 시점에 최적의 결정을 내리기가 쉬움. and 결정의 복잡성도 줄어든다.
  
  p. 213) 기민성이 떨어지면, 생산성이 낮아져 TDD 제공하는 장점이 사라진다.
시스템은 도메인 특화 언어가 필요하다.
- 추상화 수준을 코드 관용구나 디자인 패턴 이상으로 끌어올린다.
- 개발자가 적절한 추상화 수준에서 코드 의도를 표현.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

Java 관련 배경지식이 이 챕터를 이해하기에는 너-무 부족했었다. 모르는 것들 검색하면서 읽는시간 절반이상 쓴 것 같다. (휴.. 🤷‍♀️) 그중에서도 관점이라는 개념이 잘 와닿지 않아서 애먹었는데, 이해 될까 하다가도 뒤돌면 다시 까먹는것 같다.. 😹
이번 주 읽은 부분에서는 기민성, 지엽적, 창발.. 라는 단어가 나왔었는데, IT랑 전혀 상관없는 단어가 오히려 더 이해가 안됬다. 개발 공부하려면 국어공부도 같이 해야되나보다. (0개국어설..)

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

자바 생명주기 https://minnnne.tistory.com/110 #
XML 배포기술자 (deployment descriptors)
- 책) 영구 저장소에서 객체와 관계형 자료가 매핑되는 방식, 원하는 트랜택션 동작방식, 보안 제약조건이 들어감..
- 스프링 옛날 버전(스프링 부트 안 쓸 때) 배포를 어떤식으로 되게 할 건지 정의하는 거 #
엔티티 빈
- 데이터베이스로 부터 읽어드린 테이블의 데이터를 담는 빈 Entity Bean #
InvocationHandler
- 프록시 패턴으로 구현할 때 쓰는거. #
POJO (Plain Old Java Object) #
프록시
- 원래 로직을 유지하면서 뭔가 더 공통적인 처리를 추가하는 방식. (↓ 내가 이해 하려고 첨부한 초간단 예제 코드 )

관점 지향 프로그래밍 AOP, Aspect-Oriented Programming

횡단관심: 로깅, 보안, 트랜잭션 등등 다수의 모듈에서 반복적으로 나타나는 부분.

참고: https://expert0226.tistory.com/200 [여름나라겨울이야기] #
관심사 분리 (SOC, separation of concerns)
- 관심사: 컴퓨터 프로그램 코드에 영향을 미치는 정보의 집합.
- Easy.ver) 프로그램을 기능 면에서 되도록 중복이 아닌 여러 모듈로 명확히 나누는 것.
- 모듈식 (== 관심사의 분리)는 정보를 잘 정의된 인터페이스가 있는 코드 부분 안에 캡슐화시킴으로써 달성함.
기민성, 기민함 in 시스템
- p.211) 최신 정보에 기반해 최선의 시점에 최적의 결정을 내리기가 쉬워진다. 또한 결정의 복잡성도 줄어든다.
- p. 213) 기민성이 떨어지면, 생산성이 낮아져 TDD 제공하는 장점이 사라진다.
지엽적인 관리 : 소스코드 중에서 비즈니스 로직 상 중요한 거랑 아닌거랑 나뉘는거.

[클린코드] 10. 클래스

Mon, 25 Jul 2022 04:56:25 GMT

TIL (Today I Learned)

2022.05.17

오늘 읽은 범위

10장. 클래스

책에서 기억하고 싶은 내용을 써보세요.

캡슐화 (p.172)
- 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다.
- 그 전에 비공개 상태를 유지할 온갖 방법을 강구한다. 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다. #
클래스는 작아야 한다! (p.172-173)
- 함수는 물리적인 행 수로 크기를 측정했다. 클래스는 맡은 책임을 센다.
- 클래스 이름은 해당 클래스 책임을 기술해야 한다. : 간결한 이름이 떠오르지 않는다면 필경 클래스 크기가 너무 커서 그렇다. 클래스 이름이 모호하다면 필경 클래스 책임이 너무 많아서다.
- 클래스 설명은 만일(“if”), 그리고(“and”), -(하)며(“or”), 하지만(“but”)을 사용하지 않고서 25단어 내외로 가능해야 한다. #
단일 책임 원칙 (SRP, Single Responsibility Principle) (p.175-176)
- 클래스는 책임, 즉 변경할 이유가 하나여야 한다.
- 문제는 프로그램이 돌아가면 일이 끝났다고 여기는 데 있다. 프로그램으로 되돌아가 만능 클래스를 단일 책임 클래스 여럿으로 분리하는 대신 다음 문제로 넘어가버린다.
  - SPR 단점 많은 개발자는 자잘한 단일 책임 클래스가 많아지면 큰 그림을 이해하기 어려워진다고 우려한다. 큰 그림을 이해하려면 이 클래스 저 클래스를 수없이 넘나들어야 한다고 걱정한다.
  - 그럼에도 불구하고 써야하는 이유 규모가 어느 수준에 이르는 시스템은 논리가 많고도 복잡하다. 이런 복잡성을 다루려면 체계적인 정리가 필수다. 그래야 개발자가 무엇이 어디에 있는지 쉽게 찾는다. (변경을 가할 때) 직접 영향이 미치는 컴포넌트만 이해해도 충분함.
  - 결론 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다. 작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.
응집도Cohesion (p.177)
- 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다.
- 응집도가 높다 == 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다.
- 몇몇 메서드만이 사용하는 인스턴스 변수가 아주 많아진다. 이는 십중팔구 새로운 클래스로 쪼개야 한다는 신호다. 응집도가 높아지도록 변수와 메서드를 적절히 분리해 새로운 클래스 두세 개로 쪼개준다. #
변경하기 쉬운 클래스 (p.185)
- 대다수 시스템은 지속적인 변경이 가해진다. 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

🔽 몇몇 메서드만이 사용하는 인스턴스 변수가 아주 많아진다. 이는 십중팔구 새로운 클래스로 쪼개야 한다는 신호다. 응집도가 높아지도록 변수와 메서드를 적절히 분리해 새로운 클래스 두세 개로 쪼개준다.

응집도가 높은 것이 바람직 한 것만은 아니겠군..
나는 클래스 분리를 선뜻 생각하지 않는 편이라, 클래스를 쪼개는 상황을 기회가 생긴다.라고 표현 한 것이 인상적이었다. # 나는 보통
로직 복잡도가 올라가거나,
코드 라인이 지나치게 길어질 때,
중복적으로 사용되는 부분이 많아 공통으로 분리할 때
.. 같은 경우에 꽤 고민 하다가 정 불가피하게 해야된다면 클래스로 분리했다.

그래서 보통 로직이 골치아플때 많이 겪은 상황이라 이걸 긍정적으로 볼수도 있겠구나 싶었다. 아무래도 나는 개발 표준이라는 큰 틀을 벗어나고 싶지 않아 했던 것 같다. (클래스 분리를 한 코드에 개발표준 내에서 처리하라는 피드백을 받은 이후 부터 였던 듯 하다.) 클래스 분리가 개발 표준을 크게 해치는 것일까..? 오히려 가독성을 높여줘 코드 파악에는 더 도움이 될 수도 있을텐데 싶다. 혼자서 개발하면 상관 없겠지만, 여러명이서 개발 할 때는 내 판단하에 분리를 할 수 없으니 서로 합의하에 이루어 된다고 생각한다.. 그러면 코드 작성 전이나 커밋 전에 협의 해서 정하는 걸까?

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

최상위 GUI 윈도의 스윙 표현
- JFrame
참고 | 자바(Java)의 기초 박살내기 - Java GUI②
스윙 코드
버전 번호

(* 클래스 설계 원칙)

OCP (Open-Closed Principle) (p.188) : 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다는 원칙.
DIP (Dependency Inversion Principle)
- 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙.

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

Mon, 25 Jul 2022 04:55:32 GMT

TIL (Today I Learned)

2022.05.17

오늘 읽은 범위

9장 단위 테스트

책에서 기억하고 싶은 내용을 써보세요.

TDD 법칙 세 가지 (p.155) ·첫째 법칙: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. ·둘째 법칙: 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. ·셋째 법칙: 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
테스트 주기가 대략 30초 주기로 묶인다. (..) 이렇게 일하면 실제 코드를 사실상 전부 테스트하는 테스트 케이스가 나온다. 하지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다. (p.155)
깨끗한 테스트 코드 유지하기 (p.156)
- 지저분한 테스트 코드를 내놓으나 테스트를 안 하나 오십보 백보라는, 아니 오히려 더 못하다.
- 실제 코드가 진화하면 테스트 코드도 변해야 한다. 그런데 테스트 코드가 지저분할수록 변경하기 어려워진다. 테스트 코드가 복잡할수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리기 십상이다.
- 실제 코드를 변경해 기존 테스트 케이스가 실패하기 시작하면, 지저분한 코드로 인해, 실패하는 테스트 케이스를 점점 더 통과시키기 어려워진다.
테스트는 유연성, 유지보수성, 재사용성을 제공한다. (p.157)
- 테스트 코드를 깨끗하게 유지하지 않으면 결국은 잃어버린다.
- 단위테스트가 버팀목. : 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다. 아키텍처가 아무리 유연하더라도, 설계를 아무리 잘 나눴더라도, 테스트 케이스가 없으면 개발자는 변경을 주저한다.
- 실제 코드를 점검하는 자동화된 단위 테스트 슈트는 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠다. 테스트 케이스가 있으면 변경이 쉬워지기 때문이다.
- 테스트 코드가 지저분하면 코드를 변경하는 능력이 떨어지며 코드 구조를 개선하는 능력도 떨어진다.
깨끗한 테스트 코드 (p.158)
- 깨끗한 테스트 코드를 만들려면? 가독성.
- 명료성, 단순성, 풍부한 표현력이 필요하다. 테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다.
이중표준 (p.161-162)
- 테스트 API 코드에 적용하는 표준은 실제 코드에 적용하는 표준과 확실히 다르다. 단순하고, 간결하고, 표현력이 풍부해야 하지만, 실제 코드만큼 효율적일 필요는 없다. (..) 테스트 환경에서 돌아가는 코드이기 때문이다.
- 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다. 대개 메모리나 CPU 효율과 관련 있는 경우다. 코드의 깨끗함과는 철저히 무관함. (p.164)
테스트 당 assert 하나 (p.164)
- assert 문이 단 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다.
테스트 당 개념 하나 (p.166)
F.I.R.S.T. (p.168)
- 빠르게Fast: 테스트가 느리면 자주 돌릴 엄두를 못 낸다. 자주 돌리지 않으면 초반에 문제를 찾아내 고치지 못한다.
- 독립적으로Independent: 다음 테스트가 실행될 환경을 준비해서는 안 된다. 어떤 순서로 실행해도 괜찮아야 한다. 테스트가 서로에게 의존하면 하나가 실패할 때 나머지도 잇달아 실패하므로 원인을 진단하기 어려워지며 후반 테스트가 찾아내야 할 결함이 숨겨진다.
- 반복가능하게Repeatable: 어떤 환경에서도 반복 가능해야 한다. (네트워크에 연결되지 않은) 노트북 환경에서도 실행할 수 있어야 한다.
- 자가검증하는Self-Validating: 부울bool 값으로 결과를 내야 한다.
- 적시에Timely: 코드를 구현하기 직전에 구현한다. 테스트가 불가능하도록 실제 코드를 설계할지도 모른다.
결론 : 테스트 코드는 지속적으로 깨끗하게 관리하자. 표현력을 높이고 간결하게 정리하자. 테스트 API를 구현해 도메인 특화 언어Domain Specific Language, DSL를 만들자. (p.168)

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

반복가능하게Repeatable: 어떤 환경에서도 반복 가능해야 한다. (네트워크에 연결되지 않은) 노트북 환경에서도 실행할 수 있어야 한다.

발생한 의문점🤔 > 네트워크에 연결되지 않은 상태에서도 테스트가 가능해야한다고..? 이정도 까지...? 데이터 통신하는 테스트는 ..? 예외처리로 제외하나 아니면 false 감안하고 하는 건가.

깨끗한 테스트 코드 유지하기 (p.156)

지저분한 테스트 코드를 내놓으나 테스트를 안 하나 오십보 백보라는, 아니 오히려 더 못하다.

실제 코드가 진화하면 테스트 코드도 변해야 한다. 그런데 테스트 코드가 지저분할수록 변경하기 어려워진다. 테스트 코드가 복잡할수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리기 십상이다.

실제 코드를 변경해 기존 테스트 케이스가 실패하기 시작하면, 지저분한 코드로 인해, 실패하는 테스트 케이스를 점점 더 통과시키기 어려워진다.

너무 공감되었다.. 사이드 플젝을 하며 작성했던 TC 코드는 프로젝트 진행하면서 관리에 실패했다. 결국 허울 뿐인 TC코드가 되었고 빌드할 때.. 주석하고 돌리기도 했다.! 🙄😥 주 실패요인은 무엇보다 책에서 강조한 가독성이 좋지 않아서 인 듯하다. 당시 Jest를 사용해 TC를 작성했었다. 당시 처음으로 TC 작성을 하는 거라 잘 모르는 상태로 작성하기 급급해 검색하며 덕지덕지 만든 코드였다. (😂) 지금 생각해 보면, 간단한 기능 위주로 더 분리를 할 수 있었을 것 같다. 아마도, 한개의 테스트 케이스에 너무 많은 기능 테스트를 작성했던 것이 또 다른 실패 원인인듯 하다. 시나리오를 어느정도 작성해두고 코드로 옮기면 더 명료한 TC가 가능했을 것이다. (💬 음.. 시나리오는 사용자 행동패턴 위주로 짜는 게 좋을까 기능별로 테스트 하는 것이 좋은 걸까?)

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

테스트 슈트
Given-When-Then 패턴 : Test Code 스타일을 표현하는 방식.
- Given : 테스트를 위해 준비하는 과정. ex. 테스트에 사용하는 변수, 입력 값 등을 정의하거나, Mock 객체를 정의하는 구문
- When : 구체화하고자 하는 그 행동. 실제로 액션을 하는 테스트를 실행하는 과정. ex. click, getData ..
- Then : 테스트를 검증하는 과정. 예상한 값, 실제 실행을 통해서 나온 값을 검증. ex. equals, includes, hasClass..
  
  참고] Given-When-Then 패턴 | https://kchanguk.tistory.com/40

템플릿 메서드 패턴 (template method Pattern)

: 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴

given/when 부분을 부모 클래스에 두고 then 부분을 자식 클래스에 두면 된다. 아니면 완전히 독자적인 테스트 클래스를 만들어 @Before 함수에 given/when 부분을 넣고 @Test 함수에 then 부분을 넣어도 된다. (p.165)

참고] Design Pattern 템플릿 메서드 패턴 | https://gmlwjd9405.github.io/2018/07/13/template-method-pattern.html

[클린코드] 8. 경계

Tue, 05 Jul 2022 05:05:13 GMT

TIL (Today I Learned)

2022.05.13

오늘 읽은 범위

8장. 경계

책에서 기억하고 싶은 내용을 써보세요.

Map은 굉장히 다양한 인터페이스로 수많은 기능을 제공한다. (p.144) (..) Map 클래스를 사용할 때마다 위와 같이 캡슐화하라는 소리가 아니다. Map과 같은경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의한다.
경계 살피고 익히기 (p.146) 우리가 사용할 코드를 테스트하는 편이 바람직하다.
학습테스트 (p.147) : 우리쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히는 방법. (외부코드;사용라이브러리 코드)
학습 테스트는 패키지가 예상대로 도는지 검증한다. (..) 패키지가 우리 코드와 호환되리라는 보장은 없다. (..) 새 버전이 우리 코드와 호환되지 않으면 학습 테스트가 이 사실을 곧바로 밝혀낸다. (..) 실제 코드와 동일한 방식으로 인터페이스를 사용하는 테스트 케이스가 필요하다. (p.149-150)
아직 존재하지 않는 코드를 사용하기 (p.150) : 아는 코드와 모르는 코드를 분리하는 경계다. (..) 저쪽 팀이 아직 API를 설계하지 않았으므로 구체적인 방법은 몰랐다. (aka.모르는 코드)
깨끗한 경계 (p.152) 경계에 위치하는 코드는 깔끔히 분리한다. 또한 기대치를 정의하는 테스트 케 이스도 작성한다. 이쪽 코드에서 외부 패키지를 세세하게 알아야 할 필요가 없 다. 통제가 불가능한 외부 패키지에 의존하는 대신 통제가 가능한 우리 코드에 의존하는 편이 훨씬 좋다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

TC가 필요한 이유.. 라이브러리 사용에 대한 최소한의 보험.! (* 새 버전이 우리 코드와 호환되지 않으면 학습 테스트가 이 사실을 곧바로 밝혀낸다. .. 링크)
아직 존재하지 않는 코드를 사용하기 (링크) : 아.. 너무 공감 된다. 오늘만 해도 구현되지 않은 API의 데이터구조를 상상하며 작업을 하였다. 프로젝트를 진행하다 보면, 여러사람들과 같이 일하게 되기에, 불가피하지만 충분히 일어날 수 있는 상황이다. 저자가 인터페이스 구현에 있어 코드 가독성도 높아지고 코드 의도도 분명해진다고 말한건, 발상의 전환 그자체였다.. 뭐 그렇게 보면 장점도 있겠다 싶었다. 완전히 분리된 설계가 가능해 지니까.. 수정가능성도 여부에 두고 작업을 하게 되니 API 변경여부에 대해서도 유연하게 대응할 수 있겠다 생각했다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

학습테스트 (p.147) : 우리쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히는 방법. (외부코드; 사용라이브러리 코드)

ADAPTER 패턴

정의) 한 클래스의 인터페이스를 클라이언트에서 사용하고자하는 다른 인터페이스로 변환한다. 어댑터를 이용하면 인터페이스 호환성 문제 때문에 같이 쓸 수 없는 클래스들을 연결해서 쓸 수 있다.
클라이언트와 구현된 인터페이스를 분리시킬수 있으며, 향후 인터페이스가 바뀌더라도 그 변경 내역은 어댑터에 캡슐화 되기 때문에 클라이언트는 바뀔 필요가 없어진다. 디자인패턴_어댑터 패턴(adapter pattern) 참고 블로그

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

Tue, 05 Jul 2022 05:04:41 GMT

TIL (Today I Learned) 2022.05.09

오늘 읽은 범위 7장. 오류 처리

책에서 기억하고 싶은 내용을 써보세요.

오류 코드보다 예외를 사용하라 (p.130) #
Try-Catch-Finally 문부터 작성하라. (p.132)
- try 블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워진다. #
먼저 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다. 그러면 자연스럽게 try 블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워진다. (p.133) #
미확인 예외를 사용하라. (p.133)
- 확인된 예외 (..) 메서드 모두가 선언부에 해당 예외를 정의해야 한다. (..) 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야 한다. (..) ! throws 경로에 위치하는 모든 함수가 최하위 함수에서 던지는 예외를 알아야 하므로 캡슐화가 깨진다. #
null을 반환하지 마라 (p.139)
- 메서드에서 null을 반환하고픈 유혹이 든다면 그 대신 예외를 던지거나 특수 사례 객체를 반환한다. 사용하려는 외부 API가 null을 반환한다면 감싸기 메서드를 구현해 예외를 던지거나 특수 사례 객체를 반환하는 방식을 고려한다. #
null을 전달하지 마라. (p.140-141)
- 대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없다. 그렇다면 애초에 null을 넘기지 못하도록 금지하는 정책이 합리적 이다. 즉, 인수로 null이 넘어오면 코드에 문제가 있다는 말이다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

😏 확인된 예외, 구체적인 오류처리를 하면 장점만 있다고 생각했다.

오류 case를 잡아내는 것에만 중점을 둬서, 자세하고 확실한 경우를 잡아내는 것이 우선이라고만 생각했다. 기존 코드를 수정하는 것도 비용에 포함된다고는 생각을 못했었다. 기회비용을 잘 따져 선택하는 것이 중요하다 생각이 되었다. 책을 읽을수록 당연하다고 생각하고 신경쓰지 않았던 것들을 의식하게 되어서 너무 좋다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

asset : Assert는 개발/테스트 단계에서 파라미터가 제대로 넘어왔는지 계산이 제대로 됬는지 혹은 특정 메소드가 작동하는 한계상황(Null이 들어오면 작동안함)을 정하는 용도로 사용한다.

참고 블로그 | Java에서 assert 제대로 쓰기

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

Tue, 05 Jul 2022 05:01:47 GMT

TIL (Today I Learned)

2022.05.13

오늘 읽은 범위 6. 객체와 자료구조

📖 책에서 기억하고 싶은 내용을 써보세요.

구현을 감추려면 추상화가 필요하다! P.119 : 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미 의 클래스다.

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

a. 객체 지향 코드는 기존 함수를 변경하지 않으면 서 새 클래스를 추가하기 쉽다. b. (자료 구조를 사용하는) 절차적인 코드는 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다.

a. 객체 지향 코드는 새로운 함수를 추가하기 어렵다. 그러려면 모든 클 래스를 고쳐야 한다. b. 절차적인 코드는 새로운 자료 구조를 추가하기 어렵다. 그러려면 모든 함수를 고 쳐야 한다.

#
잡종 구조 (p.124) : 단점만 모아놓은 구조. (..) 프로그래머가 함수나 타입을 보호할지 공개할지 확인하지 못해 내놓은 설계.

구조체 감추기. (p.125) : 객체라면 내부구조를 감춰야한다.

🐱‍👓 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

내가 혹여나 알고 있던 개념이더라도 줄 글로 읽으니 이해 하기가 어려웠다. 코드예제를 같이 보니 좀 나았다.

그리고 객체.. 굉장히 기본적인 개념인데 책 읽다보니.. 아는 것이라고 볼 수 없겠더라. 객체와 자료구조.. 책도 별도로 있을 만큼 방대하게 다룰 수 있는 주제인데.. 중요한 내용만 함축된 것으로 접해서 그런지 이해하기 어려운 부분이 있었다. 또 멋모르고 개발 했던 내 스스로를 되돌아 보게됬다. (나는 얼마나 무지랭이로 개발 했던가.. 후후)

자료구조는 프로그래밍을 건축으로 치면 기본 뼈대를 잡는 것이라고 많이들 이야기한다. 아기 돼지 삼형제 이야기가 생각난다. 나는 지금까지 첫째 돼지가 집짓는 것 처럼 코딩했었다. 앞으로는 형식만 내는 것이 아닌, 위기가 오더라도 견딜 수 있는 견고한 프로그래밍을 하고 싶다. 벽돌집을 짓는 그날 까지 화이팅하자. 🔥👊

🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

객체와 자료구조 차이. : 책에서 말하는 개념을 내 나름대로 재정의 해보았다.

다형polymorphic 메서드 : 하나의 객체가 여러 가지 타입을 가질 수 있는 것을 의미합니다. 자바에서는 이러한 다형성을 부모 클래스 타입의 참조 변수로 자식 클래스 타입의 인스턴스를 참조할 수 있도록 하여 구현. 다형성은 상속, 추상화와 더불어 객체 지향 프로그래밍을 구성하는 중요한 특징 중 하나. [JAVA] 다형성(polymorphism)

디미터 법칙 (p.123) : 객체는 자료를 숨기고 함수를 공개한다. 즉, 객체는 조회 함수로 내부 구조를 공개하면 안 된다.

객체 지향적로 함수를 통해서 접근하는 것이 좋음. (기차충돌; 내부상황 모두 공유하거나 객체안의 모습을 보여주면, 나중에 상태변환하기 힘들다.)

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

Tue, 05 Jul 2022 04:01:51 GMT

TIL (Today I Learned)

2022.05.09

오늘 읽은 범위

5장. 형식 맞추기

📖 책에서 기억하고 싶은 내용을 써보세요.

서론

코드 형식을 맞추기 위한 간단한 규칙을 정하고따라야 한다
팀 이 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다
필요하다면 규칙을 자동으로 적용하는 도구를 활용한다.

형식을 맞추는 목적

융통성 없이 맹목적으로 따르면 안됨. 코드 형식 === 의사소통의 일환 의사소통은 전문 개발자의 일차적인 의무.

코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다.

aka. 코드는 사라질지라도 개발자의 스타일과 규율은 사라지지 않는다

적절한 행 길이를 유지하라 큰 파일보다 작은 파일이 이해하기 쉽다.

신문 기사처럼 작성하라

[클린코드] 4. 주석

Tue, 05 Jul 2022 03:55:14 GMT

TIL (Today I Learned)

2022.06.02

오늘 읽은 범위

4장. 주석

📖 책에서 기억하고 싶은 내용을 써보세요.

주석사용 = 코드로 의도표현 실패 → 주석을 가능한 줄이도록 꾸준히 노력
주석은 나쁜 코드를 보완하지 못한다 코드에 주석을 추가하는 일반적인 이유 = 코드 품질이 나쁘기 때문 주석달기 << 코드 정리
코드로 의도를 표현하라!

좋은 주석 🔽

1. 법적인 주석 소스 파일 첫머리에 주석으로 들어가는 저작권 정보와 소유권 정보는 필요하며 타당하다.

2. 정보를 제공하는 주석 가능하다면, 함수 이름에 정보를 담는 편이 더 좋다. (+클래스를 만들어 코드를 옮겨주면 더 좋고 더 깔끔함.)

3. 의도를 설명 & 명료하게 밝히는 주석 인수나 반환값 자체를 명확하게 만들면 best, 인수나 반환값이 표준 라이브러리나 변경하지 못하는 코드에 속한다면 의미를 명료하게 밝히는 주석이 유용하다.

4. 결과를 경고하는 주석

Ex. 특정 테스트 케이스를 꺼야 하는 이유를 설명 → 여유 시간이 충분하지 않다면 실행하지 마십시오.

요즘은 주석 대신 테스트 케이스를 꺼버림. (@Ignore 사용)

5. TODO 주석

필요하나, 당장 구현하기 어려운 업무
더 이상 필요 없는 기능을 삭제하라는 알림,
누군가에게 문제를 봐달 라는 요청,
더 좋은 이름을 떠올려달라는 부탁,
앞으로 발생할 이벤트에 맞춰 코드를 고치라는 주의

But, 어떤 용도든, 시스템에 나쁜 코드를 남겨 놓는 핑계가 되면 안됨.

6. 중요성을 강조하는 주석 대수롭지 않다고 여겨질 뭔가의 중요성을 강조.

7. 공개 API에서 Javadocs Javadocs도 잘못된 정보 전달 가능성 있음. ex.독자를 오도, 잘못 위치..

나쁜 주석 🔽

1. 주절거리는 주석 의미없음 → 다른 사람들에게 전달되지 않는다.

2. 같은 이야기를 중복하는 주석 (코드파악 시간 <<< 주석을 읽는 시간) 코드만 지저분하고 정신 없게 만든다. Ex. 쓸모없고 중복된 Javadocs

3. 오해할 여지가 있는 주석 주석에 담긴 ‘살짝 잘못된 정보’로 인해 프로그래머는 코드가 돌아가는 이유를 찾느라 골머리를 앓는다.

4. 의무적으로 다는 주석 코드만 헷갈리게 만들며, 거짓말할 가능성을 높이며, 잘못된 정보를 제공할 여지만 만듦. 특별한 이유 없이 의무감으로 다는 주석은 === 시간낭비.

5. 이력을 기록하는 주석 이전에는 소스 코드 관리 시스템이 없었으니까 괜찮음. 지금은 필요 없음.

6. 있으나 마나 한 주석 :당연한 사실을 언급하며 새로운 정보를 제공하지 못하는 주석. → 개발자가 주석을 무시하는 습관에 빠진다. 결국 코드가 바뀌면서 주석은 거짓말로 변함. 함수나 변수로 표현할 수 있다면 주석을 달지 말 것.

7. 위치를 표시하는 주석 배너 아래 특정 기능을 모아놓으면 유용한 경우도 있긴 함. 배너는 눈에 띄며 주의를 환기 뒷부분에 슬래시(/)로 이어지는 잡음은 제거하는 편이 좋다. 반드시 필요할 때만, 아주 드물게 사용하기 Ex. // Actions //////////////////////////////////

8. 닫는 괄호에 다는 주석 중첩이 심하고 장황한 함수라면 의미가 있을지도 모르지만 작고 캡슐화된 함수에는 잡음 함수를 줄이려 시도

코드 예제

9. 공로를 돌리거나 저자를 표시하는 주석 이제는 소스 코드 관리 시스템으로 대체. → 주석은 그냥 오랫동안 코드에 방치되어 점차 부정 확하고 쓸모없는 정보로 변하기 쉽다.

10. 주석으로 처리한 코드 이유가 있어 남겨 놓았으리라고 생각함 & 중요하니까 지우면 안 된다고 생각. → 계속 불필요하게 메모리 차지 & 코드 지저분..

11. HTML 주석 HTML 태그를 삽입해야 하는 책임은 프로그래머가 아니라 도구가 져야 한다.

Ex. 코드예제

12. 모호한 관계 주석과 주석이 설명하는 코드는 둘 사이 관계가 명백해야 한다.

13. 함수 헤더 짧고 + 한 가지 역할만 수행 + 굿 네이밍 함수 → 주석으로 헤더추가한 함수

14. 비공개 코드에서 Javadocs 공개하지 않을 코드라면 Javadocs는 쓸모가 없다.

⛳결론 변수 이름을 바꾸거나, 코드 구조를 조정해 이유를 명확하게 설명할 방법을 찾지 못했다. → 주석 필요.

🐱‍👓 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

“주석보다는 전달하는 메세지가 명료한 코드가 낫다” 는 결론. 그만큼 코드가 읽기 쉽게 잘 짜여져야 된다는 이야기로도 들렸다.

🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

[클린코드] 3장. 함수

Mon, 27 Jun 2022 13:34:15 GMT

TIL (Today I Learned)

2022.05.09

오늘 읽은 범위

3장. 함수

📖 책에서 기억하고 싶은 내용을 써보세요.

함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. (p.44)
함수가 확실히 ‘한 가지’ 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다.
- 한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈린다. 근본 개념과 세부사항을 뒤섞기 시작하면, 깨어진 창문처럼 사람들이 함수에 세부사항을 점점 더 추가한다. (p.45-46)
코드는 위에서 아래로 이야기처럼 읽혀야 좋다. (p.46)
길고 서술적인 이름이 길고 서술적인 주석보다 좋다. (p.49)
최선은 입력 인수가 없는 경우이며, 차선은 입력 인수가 1개뿐인 경우다. (p.51)
플래그 인수는 추하다. (...) 함수가 한꺼번에 여러 가지를 처리한다고 대놓고 공표하는 셈이니까! 플래그가 참이면 이걸 하고 거짓이면 저걸 한다는 말이니까! (p.52)
어떤 코드든 절대로 무시하면 안되니까. 무시한 코드에 오류가 숨어드니까. (p.52)
부수 효과를 일으키지 마라! (p.55)
- 함수에서 한 가지를 하겠다고 약속하고선 (..) 예상치 못하게 클래스 변수를 수정한다.
- 만약 시간적인 결합이 필요하다면 함수 이름에 분명히 명시한다.

🐱‍👓 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

추상화 수준이 동일해야한다. : 맞는말이다. 지금껏 의식하지 못했던 사항이라 이제부터 추상화 레벨에 대해 신경써서 개발 해야겠다. #
시스템 구현하면서도 계속 함수 세분화를 의식하면서 하는 것이 중요하다. 깨어진 창문논리가 공감이 많이 되었다. 책에서 이야기하는 개발 방식은 신경과 정성이 많이 들어갈 수밖에 없는데, 한번 괜찮겠지.. 급하니까 라고 생각하다보면 어느 새 겉잡을 수 없는 스파게티 소스가 되어버렸다.. 그리고 날잡고 리팩토링을 하는 수 밖에.. 오히려 리소스가 더 많이 들어가니 틈틈히 하자..!

깨진 창문 (p.45-46)

한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈린다. 근본 개념과 세부사항을 뒤섞기 시작하면, 깨어진 창문처럼 사람들이 함수에 세부사항을 점점 더 추가한다.

인수를 최소화 하는 것이 좋다는 것은, Object 타입의 인수를 넘겨 함수에서 구조분해할당으로 사용하는 방식에도 해당되는 것일까? : Object내 필요 property만 선언해 사용하다 보면 Object내 전체 항목을 파악하는 것이 어려울 때가 있다. (Object 항목이 많을 때, 추가적으로 호출이 필요하다면, 상위 함수를 추적해 전체 데이터를 확인해야하는 불상사가 간혹 있었다.) 이 경우에는 인수는 하나지만, 저자가 말하는 다중 인수의 부작용과 비슷한 상황이 있을 수 있는 경우라 생각했다.
🤔❔ 타입스크립트를 사용하는 것으로 해결을 할 수도 있다. 만약 vue 컴포넌트를 사용한다면 컴포넌트 생성할 때 prop 타입을 지정해 주는 것으로 어느 정도의 가이드라인이 될 수 있겠다. 지금 사내 프로젝트에서는 어떻게 보완할수 있을까.. #
🤔❔ 아니면 근본적인 원인해결, object 내 선언하는 property 갯수 한정..? 어디까지 허용되게 할 것인가.

🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

TO 문단 (내려가기 규칙사용) (p.46)

A와B를 하려면 C를 해야한다.
   A를 하기위해서는 D를 해야한다.
   D를 하기위해서는 F를 해야한다.
   F를 하기위해서는 H를 해야한다.
        H를 하기위해서는 I를 해야한다.
        I를 하기위해서는 O를 해야한다.
   B를 하기위해서는 Q를 해야한다.
....
...

SRP (Single Responsibility Principle) :단일 책임 원칙, 모든 클래스는 하나의 책임만 가지며 클래스는 그 책임을 완전히 캡슐화해야 함을 일컫는다.
OCP (Open Closed Principle) :개방 폐쇄 원칙, 소프트웨어 객체(클래스, 모듈, 함수 등등)는 확장에 대해 열려 있어야 하며 수정에 대해서는 닫혀있어야 한다.
추상 팩토리 (Abstract Factory) :구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴

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

Thu, 23 Jun 2022 17:17:58 GMT

TIL (Today I Learned)

2022.05.04

오늘 읽은 범위

2장. 의미있는 이름

📖 책에서 기억하고 싶은 내용을 써보세요.

의도를 분명히 밝혀라.
- 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. (p.22)
그릇된 정보는 피해라.
의미있게 구분하라.
- 연속된 숫자를 덧붙이거나 불용어(noise word)를 추가하는 방식은 적절하지 못하다. ... 아무런 정보를 제공하지 못하는 이름 ... (p.26)
발음하기 쉬운 이름은 중요하다. 프로그래밍은 사회 활동이기 때문이다. (p.27)
검색하기 쉬운 이름을 사용하라.
- 이런 관점에서는 긴 이름이 짧은 이름 보다 좋다. (p.28)
전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다. (p. 31)

🐱‍👓 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

“검색하기 좋은 변수명과 의도를 분명하게 하기. ” chapter를 보며든 생각. 프로그램이 확장되면 추후에 비슷한 기능을 하는 변수명 네이밍시, 잘못된 예시와(Ex. getList getListItem getListItemCustom..) 굉장히 유사한 변수 네이밍을 한적이 있다. (꽤 있다..) 조회 매서드 내 기능이 확장되면서 불가피하게 이런 식으로 한적이 있었는데 구현에 급급해 찜찜하면서도 넘어갔었다. 검색을 위해 중복되지는 않게 했지만 의도가 분명하게 드러나는 네이밍은 아니었다. 추후에는 직관적이면서도 확장성있는 네이밍을 고민하게 될 것 같다.

🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

grep : 입력으로 전달된 파일의 내용에서 특정 문자열을 찾고자할 때 사용하는 리눅스 명령어.

📝참고 리눅스 grep 명령어 사용법. (Linux grep command) - 리눅스 문자열 검색

[클린코드] 1장. 깨끗한 코드

Thu, 23 Jun 2022 17:09:56 GMT

TIL (Today I Learned)

2022.05.04

오늘 읽은 범위 1장. 깨끗한 코드

📖 책에서 기억하고 싶은 내용을 써보세요.

코드는 요구사항을 상세히 표현하는 수단이다.
빨리 가는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관이다. (p.7)

🎿 The only way to go fast, is to go well
깨끗한 코드 === 명쾌한 추상화. 코드를 읽는 사람에게 프로그래머가 단호하다는 인상을 줘야한다. (p.11)
중복을 피하라. 한 기능만 수행하라. 제대로 표현하라. 작게 추상화하라. (p.14)
새코드를 짜면서 우리는 끊임 없이 기존 코드를 읽는다. ...읽기 쉬우면 새 코드를 짜기도 쉽다. (p.18)

🐱‍👓 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

나쁜 코드의 원인을 촉박한 프로젝트 일정 등, 외부 요인으로 핑계를 돌리지 말자. 전문가라면 상황을 탓하기 보다 상황에 맞는 해결책을 제시하는 것이 바람직하다.
프로덕트 설계/기획 단계와 별개로 개발자 본인도 개발 전, 어느 정도 레벨의 설계는 필요하다. (Ex. 컴포넌트 분리 레벨, 메서드 중복.. )
- 빨리 가는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관이다. (p.7)
클린코드가 왜 필요한 지에 대해 한 번더 생각해보게 됨. 필요하다..! 같이 개발하는 동료 개발자를 위해서, 유지보수를 위해서 라고만 생각 했지만, 내 개발 효율을 위해서도 필요했다. 의식하고 있지 않았던 것 뿐이지 내 코드를 가장 많이 보는 사람은 나였다. 기능 추가가 이루어 지더라도, 기존 코드에 대한 분석이 필수적이기에 해당 내용이 많이 공감되었다. 클린코드가 잘 이루어진다면 최대 수혜자는 당사자가 아닐까-!

🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

경쟁 상태(Race Condition) : 두 개 이상의 프로세스(혹은 스레드)들이 하나의 자원(리소스)에 접근하기 위해 경쟁하는 상태를 말합니다.
- 임계영역(Critical Section): 경쟁 상태에서 아무나 접근하지 못하도록 보호되어야 하는 부분.

경쟁 상태 해결 조건

Mutual Exclusion (상호 배제) : 어떤 프로세스가 임계 영역을 수행 중이면, 다른 모든 프로세스들은 그 임계 영역에 들어가지 못하게 막는 것.
Progress(진행) : 임계 영역에 들어간 프로세스가 없는 상태에서, 임계영역에 들어가려는 프로세스가 있으면 들어가게 해주어야 함. 임계 영역에 있는 프로세스 외에는 다른 프로세스가 임계영역에 진입하는 것을 방해하면 안됨.
Bounded Waiting(한정 대기) : 기아(starvation) 상태를 방지하기 위해 프로세스가 임계 영역에 들어가려고 요청한 후부터, 다른 프로세스들이 임계 영역에 들어가는 횟수 한계 필요. 임계영역에 한 번 들어갔다온 프로세스는 다음 들어갈 때 제한 있음.

JS userAgent / navigator

Mon, 01 Nov 2021 04:58:10 GMT

var ua = navigator.userAgent;

https://developer.mozilla.org/en-US/docs/Web/API/Navigator/userAgent

https://webzz.tistory.com/82

[Android] 안드로이드 30 apache Http 추가

Mon, 18 Oct 2021 07:43:55 GMT

#1

기존 소스의 재사용을 위해 아파치 Http 라이브러리의 사용이 필요한 상황. 안드로이드 6.0 (API 23)까지 지원. -> build.gradle에 dependency 추가

dependencies {
    api 'com.github.ok2c.hc4.android:httpclient-android:0.1.0'
    ...
}

#2 Error

Msg :: uses-sdk:minSdkVersion 22 cannot be smaller than version 26 declared in library

#3

추가해준 apache Lib 최소 API 26이상부터 사용가능함. build.gradle의 minSdk를 26으로 수정해 줌.

android {
    defaultConfig {
        applicationId ""
        minSdk 26
    }
}

[참고]

안드로이드 스튜디오 - minSdkVersion 오류 해결방법

[Android] bluetooth StartDiscovery() false :: 새로운 기기 검색 구현시 오류

Fri, 15 Oct 2021 08:18:04 GMT

Bluetooth StartDiscovery() always returns false

이미 페어링되어 있는 기기의 경우 잘 불러와지나, 새로운 기기 검색 리스트만 계속 조회 실패 한 경우.. 계속 해서 빈 배열만 리턴되어따..;;

결론)

안드로이드 10 이상부터 관련 권한 체크를 필수적으로 해주어야했음. 세상에 권한 체크로직 넣으니 정상적으로 주변 기기들을 검색해 오는 것이었음..

블루투스 제어시 필요 권한

: location 관련 권한은 왜 필수일까.. 하지만 정상작동을 위해 아래 두 항목 꼭 필요하다. 넣어주도록 하자.

[참고]

- 안드로이드 스튜디오 - 블루투스 통신

- Error 참고

+++ 추가

위치 설정 ON-!! https://stackoverflow.com/questions/58428763/android-10-not-working-with-ble-bluetooth-scanning

[Vue]생성자 함수

Tue, 05 Oct 2021 13:04:32 GMT

함수를 이용해서 어떤 정보를 담은 객체를 생성 = 생성자 함수의 객체 생성 패턴-!

매번 생성해서 사용하는 것이 아닌, 미리 정의한 함수를 가져다가 사용할 수 있음. -> Vue에서는 생성함수로 API & 속성들을 정의. -> 추후 가져와서 사용함으로써 재사용성 용이.

VS Code 단축키

Tue, 05 Oct 2021 11:38:48 GMT

HTML 기본 포맷

! + Tab

HTML id가 있는 tag 생성

div#app ➡

[Vue] v-model / v-bind / v-on 차이

Fri, 10 Sep 2021 02:16:41 GMT

v-bind: 뷰 인스턴스의 데이터 속성을 해당 HTML 요소에 연결할 때 사용 v-on: 해당 HTML 요소의 이벤트를 뷰 인스턴스의 로직과 연결할 때 사용 v-model: v-bind와 v-on의 조합

HTML 입력 요소의 종류에 따른 `v-model` 속성

(1) input 태그에는 value / input (2) checkbox 태그에는 checked / change (3) select 태그에는 value / change

** v-model의 한계

: IME(한국어, 일본어, 중국어) 입력시 한 글자에 대한 입력이 끝나야지만, data 속성값과 input박스의 텍스트가 동기화됨. Vue 공식문서에서는 한국어 입력을 다룰 때 v-bind:value와 v-on:input을 직접 연결해서 사용하는 것을 권고.

[참고] 캡틴판교-v-model의 동작 원리와 활용 방법

[Vue] v-bind:click과 @click의 차이

Tue, 31 Aug 2021 07:38:33 GMT

차이 없음 단축어임!

ddukddak.log

[클린코드] 13. 동시성

📖 책에서 기억하고 싶은 내용을 써보세요.

결론

🐱‍👓 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

[클린코드] 12. 창발성

📖 책에서 기억하고 싶은 내용을 써보세요.

🐱‍👓 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

[클린코드] 11. 시스템

#

책에서 기억하고 싶은 내용을 써보세요.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

[클린코드] 10. 클래스

책에서 기억하고 싶은 내용을 써보세요.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

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

책에서 기억하고 싶은 내용을 써보세요.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

[클린코드] 8. 경계

책에서 기억하고 싶은 내용을 써보세요.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

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

책에서 기억하고 싶은 내용을 써보세요.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

😏 확인된 예외, 구체적인 오류처리를 하면 장점만 있다고 생각했다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

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

📖 책에서 기억하고 싶은 내용을 써보세요.

🐱‍👓 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

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

📖 책에서 기억하고 싶은 내용을 써보세요.

[클린코드] 4. 주석

📖 책에서 기억하고 싶은 내용을 써보세요.

좋은 주석 🔽

나쁜 주석 🔽

🐱‍👓 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

[클린코드] 3장. 함수

📖 책에서 기억하고 싶은 내용을 써보세요.

🐱‍👓 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

깨진 창문 (p.45-46)

🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

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

📖 책에서 기억하고 싶은 내용을 써보세요.

🐱‍👓 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

[클린코드] 1장. 깨끗한 코드

📖 책에서 기억하고 싶은 내용을 써보세요.

🐱‍👓 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

경쟁 상태 해결 조건

JS userAgent / navigator

[Android] 안드로이드 30 apache Http 추가

#1

#2 Error

Msg :: uses-sdk:minSdkVersion 22 cannot be smaller than version 26 declared in library

#3

[Android] bluetooth StartDiscovery() false :: 새로운 기기 검색 구현시 오류

Bluetooth StartDiscovery() always returns false

결론)

블루투스 제어시 필요 권한

[참고]

+++ 추가

[Vue]생성자 함수

VS Code 단축키

HTML 기본 포맷

HTML id가 있는 tag 생성

[Vue] v-model / v-bind / v-on 차이

HTML 입력 요소의 종류에 따른 v-model 속성

** v-model의 한계

[Vue] v-bind:click과 @click의 차이

HTML 입력 요소의 종류에 따른 `v-model` 속성