DEVELOPyo

2020.03.15 시작

객체지향의 사실과 오해

1. 객체엔 property가 존재, property는 단순값인 attribute와 타 객체를 참조하는 link로 나누니다

2. 엔티티는 참조객체를 의미한다

3. 객체를 설계할 땐 상태(필드) 보다 행동을 중심으로 설계해야 한다

4. 추상화 지형 그대로 그려놓은 지하철 노선도 vs 역과 환승을 추상화한 지하철 노선도

- 공통점을 취하고 차이점을 버린다

- 복잡성을 줄이고 단순화

- 동일한 행동은 동일한 책임 수행, 동일한 타입에 속하며 내부 표현 방식은 다를 수 있다.

- 동일한 책임은 동일한 메시지(파라미터)를 수신하며 내부 처리방식(메소드 내부 내용)은 다를 수 있다

- 책임주도설계(responsibility driven design)

  : 제공할 행동을 머저 생각 및 결정 후 행동(책임) 수행에 필요한 데이터를 생각하고

    그 데이터는 인터페이스 뒤로 캡슐화 한다

- 객체를 분류하는 기준은 타입이며 타입을 나누는 기준은 객체가 수행하는 행동이다

개발언어나 기술에 대해 깊이 다루기 보단 객체지향이라는 개념을 추상적으로 다룬 책. 

객체지향에 대해 최대한 쉬운 예로 설명하는 책.

2020.02.23

"소프트웨어 장인정신"

소프트웨어 장인정신은 소프트웨어 개발자가 스스로가 선택한 커리어에 책임감을 가지고, 지속적으로 새로운 도구와 기술을 익히며 발전하겠다는 마음가짐이다. 소프트웨어 장인정신은 책임감, 프로페셔널리즘, 실용주의 그리고 소프트웨어 개발자로서의 자부심

"애자일"

: 단일 개념이 아닌 서로 다른 여러 맥락에 따른 방법론과 테크닉의 조합

: 짧은 피드백 주기의 중요성

"카타"

: 품세라는 뜻으로 일본 무예 훈련에서 나온 용어

: 작은 훈련용 코딩

"펫 프로젝트"

: 자가 학습/훈련 용 프로젝트

"어디로 가고있지 모르고 있다면 결국 가고싶지 않은 곳으로 간다"

: 방향의 중요성

: 방향을 잡기위한 자기계발

"나쁜 코드는 암과도 같다"

: 리펙토링의 중요성

: TDD의 중요성

2020.02.01

1. 네이밍

의미없는 코드값(숫자로 된 코드값), 클래스명 등 사용 금지.

변수명, 함수명만 봐도 어떤 역할을 하는 변수/함수 인지 알 수 있도록 네이밍하기.

※ 실사례

실제로 기존에 해왔던 프로젝트들을 돌이켜 봤을 때, 아무 의미 없는 숫자들로 따져있는 공통코드 및 클래스/함수 명이 상당히 많이 존재했다. 이런 코드들은 외워지지도 않고 프로젝트 내내 개발자들이 명세서를 찾아봐야 하는 엄청난 수고를 하게 만든다. 또한 명세서를 필요 이상으로 철저히 관리 해야하는 스트레스를 받게 한다.

분류가 애매하거나 코드값이 너무 많아 숫자로 분류하는 것은 어쩔 수 없겠으나, 그렇지 않은 경우엔 최대한 삼가해야 한다고 본다.

실제로 다음은 TV광고까지 진행됐던, 국내 최대 통신사 중 하나의, 동접자 2천명 이상의 아이돌 방송 관련 프로젝트를 수행할 때 사용한 공통코드이다. (코드값을 정의한 PM님을 설득하지 못해 어쩔 수 없이 사용했다...)

LV00 : 카메라촬영

LV11 : 앱촬영

MT00 : 멀티뷰카메라촬영

MT11 : 멀티뷰앱촬영

VR00 : VR카메라촬영

VR36 : VR앱촬영

아무 의미 없는 숫자들이 사용됐으며 규칙성 또한 존재한다고 보기 힘들다.

그렇다보니 프로젝트 내내 코드값 의미하는 바가 헷갈려 매번 명세서를 찾아보아야 했다.

위와 같은 코드 값은 아래와 같이 수정할 수 있다.

LVCAM : 카메라촬영

LVAPP : 앱촬영

MTCAM : 멀티뷰카메라촬영

MTAPP : 멀티뷰앱촬영

VRCAM : VR카메라촬영

VRAPP : VR앱촬영

위와 같이 네이밍은 작업능률을 올리고 유지보수성을 높이기 위해 가장 중요하고 따르기 쉬운 규칙이지만,

실제론 가장 지켜지지 않고 있는 악습이라고 생각한다.

2. 함수

인자값은 적을수록 좋다(단항함수가 최고)

인자값이 너무 많을 경우 객체를 인자값으로 받도록 설계한다

함수는 하나의 기능만 수행하도록 해라

위에서 아래로 읽히도록 해라

boolean 값을 인자값으로 받느니 함수를 별도로 만들어라

※ 실사례

//boolean 을 인자값으로 취하는 메소드 (부적절)
public JsonObject httpUrlConnection(boolean isJson, String targetUrl, String method){}

//boolean 을 인자값으로 받는 대신 아래와 같이 메소드 두개로 분리 (적절)
//isJson 이 false 일 때 사용하는 메소드
httpUrlConnection(String targetUrl, String method){}
//isJson 이 true 일 때 사용하는 메소드
httpUrlConnectionJsonBody(String targetUrl, String method){}
위 함수 2개로 처리

코드결과값보단 예외를 활용하라

※ 실사례

//boolean 을 리턴하는 코드 (부적절)
public boolean ftpFileUpload(...){
   return ftpClient.storeFile(remoteFilePath, inputStream);
}
//예외를 던지는 코드 (적절)
public void ftpFileUpload(...) throws Exception{
   try{
      ftpClient.storeFile(remoteFilePath, inputStream);
   } catch(Exception e) {
      logger.error(e.getMessage);
      throw e;
   }
}

3. 주석

주석을 많이 달 시간에 소스 리팩토링을 하라

주석까지 현행화되는 경우는 드물다, 주석을 믿지 말라

정규식, 리턴타입 에 대한 설명, TODO 에 대한 주석은 유용하다(상식적으로 필요한 주석만 달라는 의미같다)

4. 형식 맞추기

논리적으로 비슷한 함수끼리 모아서 작성.

함수 1에서 함수2를 호출한다면, 함수1 바로 밑에 함수2를 작성하여 신문읽듯 코드를 읽을 수 있게 작성하라. (호출되는 함수를 호출하는 함수에 가까이 작성)

마찬가지로 변수선언은 사용하는 위치와 최대한 가까이 둔다. (예외로 멤버변수는 최상단에 놓는게 관습)

적절한 행구분은 필수(새로운 개념/논리는 행구분을 하여 끊어주자).

팀 내 형식 규칙을 따를 것

5. 객체와 자료구조

객체는 자료(멤버변수)를 숨기고(private) 함수는 공개(public)한다. (캡슐화)

자료구조는 자료는 공개하고 함수는 숨긴다.

6. 오류 처리

오류코드 정의 및 리턴보단 try catch 문을 사용하라

null을 주고받지 말라 (nullpointerexception 방지 및 불필요한 null 체크 생략이 가능)

7. 경계

학습테스트(외부라이브러리(ex: log4j, aspectj 등)의 충분한 연습과 학습)의 중요성

Adapter 패턴(캡슐화)을 사용하여 외부라이브러리가 직접적으로 사용되지 않도록 하자

8. 단위테스트

1) 실패 케이스 부터 작성

2) 실패를 통과하는 실제 코드 작성

테스트는 한번에 1개의 개념만 테스트

assert 문도 가급적 한개만 사용하도록 테스트코드 작성

9. 클래스

1) SRP : single responsibility principal/단일 책임원칙 

클래스는 한 가지 기능(역할)만 해야 한다.

2) 응집도(Cohesion)가 커야 좋다

인스턴스 변수를 여러 메소드에서 사용해야 응집도가 높다 할 수 있다.

인스턴스 변수가 많다면? 클래스가 분리되어야 한다는 의미(클래스는 작을 수록 좋다)

3) OCP : open closed principle

확장에 개방적이고 수정에 폐쇄적이어야 한다

10. 동시성(멀티스레드)

[방어전략]

1) 동시성코드는 타 코드와 분리 (SRP)

2) 임계영역을 최소화(동기화 하는 부분을 최대한 작게)

3) 사본 사용(객체 복사)

4) 테스트

4-1) 단일 스레드에서 먼저 확인 후 멀티 스레드 작성

4-2) 보조코드(wait(), sleep(), yield() 등) 사용하여 테스트/AOF(aspect oriented framework), cglib 등과 같은 멀티스레드 테스트 도구 사용

4-3) 다양한 os에서 테스트

4-4) 프로세서 수보다 많은 스레드 테스트 (스와핑시 문제발생하는 경우가 존재)

* 스와핑 : 프로세스의 cpu 할당 시간이 끝나면, 메모리를 보조 기억장치(하드디스크)로 내보내고 다른 프로세스 메모리 불러 들이는 것

2019.12.28

개발자로 진로를 틀게 된 후, 처음으로 읽은 자기계발서.

읽은지 2년이 다 되어가는 책.

개발자로 살아온 지난 2.5년을 돌아볼겸, TRUE 개발자의 자세로 다시금 정신무장 할 겸 정리해본다.

부숴도 괜찮은 장난감
장난감 프로젝트를 만들어 보아라

흰띠를 매라
새로운 것을 습득할 땐 기존의 것을 내려놓자
머리를 비워야 채울 수 있다

열정을 드러내라
팀에 맞추기 위해 개발에 대한 흥분과 열정을 숨기지 말라
팀에 열정을 불어넣고 모든 것에 질문하라
팀이 열정을 받아주지 못한다면 열정을 키울 다른 방법을 찾아라.

무지를 드러내라
다른 사람들이 내가 잘 모른다고 생각하는 것을 두려워 말라. 모르는 것을 질문하라

무지에 맞서라
빈틈을 능동적으로 메우자
무지함을 인지하면서도 그에 맞서지 않는 부류("잘은 모르지만 이렇게 하면 되잖아?")에 속하지 말자

깊은 쪽
어려운 문제가 주어진다면 그 기회를 잡아라
두려운 일을 맡고 해결을 하면서 성장 할 수 있다.
실패한다 해도 그 실패 속에서 경험치가 쌓인다

한 발 물러서라
너무나 부족한 나 자신을 발견하면, 압도됨을 느낄 때가 있다.
이 땐 익숙한 능력으로 돌아가라.
익숙한 코드를 짜며 힐링하라.

비교적 잘 해온 것들 : 한 발 물러서라, 깊은 쪽, 무지를 드러내라, 무지에 맞서라, 열정을 드러내라

비교적 잘 못 해온 것들 : 부숴도 괜찮은 장난감, 흰띠를 매라

Spring Boot + JPA 위에서 동작하는 게시판(TDD 개발) 형태의 부숴도 괜찮은 장난감부터 만들어봐야지

Head First : Design Patterns

자바스럽게 개발하려면 디자인 패턴에 대한 공부는 필수.

아직 1장 스트래터지 패턴 밖에 읽어 보지 못했지만, 이해하기 쉽게그래도 어렵다 정말 잘 쓴 책 같다.

공부하며 각각의 패턴들을 블로그에 따로 정리해보려고 한다.

실무에서 다양한 상황에 맞게 각각의 패턴들을 적용하여 개발하려면 내공이 더 쌓여야 가능하겠지만,

일단 각종 API, 라이브러리 및 고수 선배님들의 소스를 파악하는데 큰 도움이 될 듯 하다.

2019-06-03 시작.