개발자 일반

좋은코드?

1. 이해가 편한 코드
   띄어쓰기 if else 삼항연산자 등 내가 아닌 누군가 보더라도 한번에 파악하기 쉬운 코드를 작성해야한다.

2. 중복이 없는 코드
   코드에서 중복을 최소화해 공통부분은 모듈화 하면 후에 재상용하기에 편하고 코드를 리펙토링할때 중복작업을 피할 수 있다.

3. 테스트가 용의한 코드
   다양한 정의가 있지만 멱등성을 유지하는(여러번 시도에 같은 결과를 반환하는 함수)가 중요한 부분이다.
   3.1 그러기 위해 제어할 수 없는 값에 의존적이지 않도록 만들고 (Random(), new Date(), 전역 함수, 전역 변수, 외부 라이브러리 의존, 사용자 입력 등)
   3.2 외부에 영향을 주는 코드를 분리한다(DB, 메시지큐, 로거 외부 API 등)
   ※실제 함수형 프로그래밍을 할 때 순수함수라는 부분이 있다. 그것을 지키기 위해서는 값, 액션, 함수를 철처하게 분리하는데 이렇게 하는 이유에 테스트가 용의 하도록 하는 이유도 있다.

OOP?

흔히 객체지향프로그래밍이라 부르는 방식이다. 기존 프로그래밍 방식은 컴퓨터중식적 사고를 가지고 프로그래밍을 했다.컴퓨터의 계산방식에 맞추어 개발을 했다. 하지만 점점 프로그래밍이 발달되면서 현실객체를 추상화해서 그것을 기준으로 프로그래밍을 하는 방법을 고안했고 그것이 객체 지향 프로그래밍이다.
설계원칙
1. 단일책임원칙: 하나의 클래스는 한 객체만 책임지며 변경되는 이유도 하나의 이유여야한다.
2. 개방폐쇄원칙: 확장에는 열려있고 변경에는 폐쇄적이여야한다. 이 부분이 조금 추상적이긴한다. 쉽게 굳이 기존 코드를 건드려서 기능을 추가하지 않도록 하는 것이 좋다는 것이다.
3. 리스코프치환원칙: 하위 객체는 상위객체를 대신할 수 있다. TS를 생각하면 extend로 확장한 인터페이스로 기존 인터페이스를 치환해도 프로그램은 정상동작한다.
4. 인터페이스분리원칙: 인터페이스는 사용자 기준으로 분리해야한다.
5. 의존역전원칙: 고수준 모듈은 저수준 모듈에 의존적이면 안된다.
https://velog.io/@huurray/SOLID-%EC%9B%90%EC%B9%99%EC%97%90-%EA%B8%B0%EC%B4%88%ED%95%9C-React-%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1%EB%B2%95

RESTfull API

RESTfull이 뭐냐 물으면 딱 뭐라고 정의하긴 쉽지않다 말 처럼 full(~하다)하는 형용사를 붙인것이기 때문이다. 그렇다면 RSET하다가 무엇인지 생각해야한다. REST는 디자인패턴으로 자원중심의 그리고 행위는 CRUD(http method)를 이용해 표현하는 것이다.

정리하면 REST라는 자원 중심 행위는 http method를 이용하는 디자인 패턴을 잘따르도록 설계한 API이다.

여기에는 내가 좋아하는 글이있다. https://meetup.nhncloud.com/posts/92
이글을 보면 확실하게 설명해주는데 기저를 보면 훌륭한 http method를 이용하지 못하는 당시의 웹 생태계를 보고 고안한 방법이다.
이 패턴에는 3가지 요소가 있는데 자원(URI), 행위(http method), 표현이다.
6가지 특징이 있는데

1. Uniform (유니폼 인터페이스)
   Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말합니다.

2. Stateless (무상태성)
   REST는 무상태성 성격을 갖습니다. 다시 말해 작업을 위한 상태정보를 따로 저장하고 관리하지 않습니다. 세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 됩니다. 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해집니다.

3. Cacheable (캐시 가능)
   REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능합니다. 따라서 HTTP가 가진 캐싱 기능이 적용 가능합니다. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능합니다.

4. Self-descriptiveness (자체 표현 구조)
   REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것입니다.

5. Client - Server 구조
   REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 됩니다.

6. 계층형 구조
   REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 합니다.

위의 특징을 지키면서 API 디자인은 어떻게 해야할까요?

1. 자원 중심이기때문에 GET food/delete/1 가 아니라
   DELETE food/1 으로 해야한다 더 나아가서 동사의 사용은 최대한 지양해야한다.
2. 그렇기 때문에 생성은 POST, 읽기는 GET, 수정은 PUT, 삭제는 DELETE이다. 여기서 수정은 PUT으로 했지만 PUT은 전체 수정에, PATCH는 일부 수정에 이렇게 나누어 사용하기도 한다.
3. URI에 마지막에/는 사용하지않는다. /는 계층구조용으로 사용한다.
4. -은 사용하지만_는 사용을 지양한다.
5. URI는 소문자를 이용한다.
6. 포맷형태를 포함하지않는다. ex poto/3.jpg
7. 만약 리소스간 연관관계가 있다면 /users/{userid}/devices 처럼 표현하고 만약 이러한 부분이 많아 파악이 힘들다면 likes와 같이 URI에 표현한다.
8. Collection과 Document를 구분하자 각각 객체집합, 객체로 생각한다.그래서 Collection의 경우 복수로 표현해 이해하기 쉽게 설계한다.

이렇게 잘 설계한 후 적절한 상태코드또한 반환해줘야한다. 이는 위에 참조글에서 확인하는 것이 좋다.

TDD

TDD란 테스트 중식의 개발방식으로 개발자는 미리 테스트케이스를 만들고 이를 통과하는 가장 간단한 코드를 만들어서 이를 이용한 개발을 하는 방식이다.

그렇기에 TDD는 요구사항을 정확하게 파악하고 사용자를 파악해 적절한 테스트를 만들 수 있어야한다. 또한 이렇게 코드를 작성하면서도 좋은코드 품질을 유지해야한다.

물론 많은 사람이 좋은 개발방식이라하지만 100% 정확한 테스트케이스를 만들기는 무리가 있고 개발뿐아니라 테스트케이스를 작성해야해 업무량이 늘어나는 단점 또한 존재한다.

함수형프로그래밍

이 또한 가장 좋아하는 글이 있다. https://velog.io/@teo/functional-programming
기존에도 대학을 다니거나 취업준비를 하면서 순수함수니 설계를 어떻게 해야하니 많은 자료가 있어지만 위에서 보여준 함수, 값, 액션 그리고 넘을 수 없는 계층을 만드는 방식을 보고 왜 함수형 프로그래밍을 하는지 바로 알게되었다. 실제 코드를 작성할 때에도 함수형 프로그래밍을 쓰도록 노력하게 해주었다.

MVC

모델, 뷰, 컨트롤러 3가지로 이루어진 아키텍쳐로 뷰를 통해서 사용자에게 요청을 받으면 컨트롤러가 그 요청을 실행해야하는 모델을 불러오고 쉽게 사용하도록 데이터는 가공해준다. 그러면 모델에서 비지니스 로직을 통해 작업을 실행하고 다시 보내줄 데이터가 있다면 컨트롤러를 통해서 다시 뷰에 전달 해준다.

Git사용 방법론

참고 https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/
크게 3가지로 나뉜다 GitFlow, GitHub Flow, GitLab Flow이다. 전부 형상관리를 어떠한 방식으로 할지 방법론을 알려주며 실제 Git을 통해 형상관리를 하는 기업에서는 위의 방식 중 하나를 선택해서 이용한다고 알고있다.