개발일기🌷

1.절차지향(Procedual Programming)

• 어떤 기능을 어떤 순서로 처리하는가에 초점을 맞춤, 컴퓨터의 처리구조와 유사.
• 장점 - 처리속도가 빠름
• 단점 - 유지보수 어려움
          - 엄격한 실행순서로 인한 비효율
• 절차지향 언어의 단점을 보완하기 위해 객체지향 개념이 등장

2.객체지향(Object Oriented Programming)

2-1. 객체지향 정의

• 객체들의 집합으로 프로그램의 상호 작용을 표현하며, 데이터를 객체로 취급하여
  객체 내부에 선언된 메서드를 활용하는 방식
• 객체 : 프로그램상에서 구현할 대상
• 클래스 : 객체의 '속성'과 '기능'을 정의한 설계도와 같은 것
• 인스턴스 : 클래스의 내용대로 메모리상에 구현될 실재(일반적인 의미의 객체)

2-2. 객체지향 특성

• 캡슐화
• 상속
• 추상화
• 다형성
  → 이 특징들은 모두 유기적으로 연결된 개념

2-2-1. 캡슐화

• 객체의 내부 구조 및 정보를 캡슐처럼 하나로 감싸 외부에서 볼 수 없게 은닉하여 보호하는 것
• 완성도 : 높은 응집도(하나의 책임을 위한 메서드들이 너무 분산되지 않고 한 객체에 모여있는 정도)
• 정보은닉 : 객체 안에서 밖으로 또는 밖에서 안으로 정보에 접근 할 수 없음

→  객체는 스스로 동작 할 수 있는 환경을 가지고(높은 응집도),
     외부 의존을 최소화(낮은 결합도)하고 외부 침략을 제한 해야함

2-2-2. 상속

• 자식클래스(서브클래서)가 부모클래스(슈퍼클래스)의 속성을 물려받는 것
• 상속의 목적 : 추상과 구체화의 관계를 위한 것(공유x)

2-2-3. 추상화

• 추상체 : 추상회된 객체(상위 객체)
• 구상체 : 구체화된 객체(하위 객체)
• 추상화는 상대적인 것 → 상위객체는 반드시 하위객체보다 추상적이여야함

2-2-4. 다형성

• 하나의 객체나 메서드가 여러가지 다른 형태를 가질 수 있는 것
• Overriding(오버라이딩) : 부모클래스로부터 상속받은 메서드를 자식클래스에서 재정의하여 사용하는 것
• Overloading(오버로딩) : 메서드의 이름은 동일, 매개변수의 타입이나, 갯수를 달리하여 중복 정의함
                                           → 매개변수에 따라 특정 메서드가 호출 되는 것

2-3. 객체지향의 5가지 설계원칙( SOLID원칙)

• Simple Responsibility Principle(SRP, 단일책임원칙)
  하나의 클래스는 하나의 책임만 가져야한다
• Open/ Closed Principle(OCP, 개방폐쇄원칙)
  : 클래스는 확장에 대해 열려 있어야 하고 변경에 대해서는 닫혀 있어야 한다
• Liskov Substitution Principle(LSP, 리스코프치환원칙)
  : 파생 클래스의 메소드는 기반 클래스의 메서드를 대체하여 사용 될 수 있어야 한다
• Interface Segregation Principle(ISP, 인터페이스분리원칙)
  : 클라이언트가 사용하지 않는 메소드에 의존하지 않아야 한다
• Dependency Inversion Principle(DIP, 의존역전원칙)
  : 추상화된것은 구체적인 것에 의존하면 안된다
  (자주 변경되는 구체적인 것에 의존하지 말고 추상화된것을 참조)

3. 절차지향 프로그래밍 VS 객체지향 프로그래밍

• 절차지향 프로그래밍
  • 물이 위에서 아래로 흐르는 것처럼 순차적인 처리를 중요시하는 프로그래밍 기법이다.
  • 컴퓨터의 처리구조와 유사해 실행속도가 빠르다.
  • 코드의 순서가 바뀌면 동일한 결과를 보장하기 어렵다.
  • C, FORTRAN, COBOL,PASCAL, BASIC
• 객체지향 프로그래밍
  • 실제 세계의 사물들을 객체로 모델링하여 개발을 진행하는 프로그래밍 기법
  • 가장 대표적인 언어로 Java가 있다.
  • 캡슐화, 상속, 다형성 등과 같은 기법을 이용할 수 있다. 
  • 절치지향 언어보다 실행속도가 느리다.
  • JAVA, Object-C, Swift,C++,Python

참고) https://mangkyu.tistory.com/88

참고) https://zwzwzw123-daily-daily.tistory.com/95

1. 디자인 패턴

• 소프트웨어 디자인과정에서 자주 발생하는 문제들에 대한 전형적인 해결책
  → SW에서 설계적 관점으로 좀 더 쉽고 간편하게 개발하는 방법(패턴)
• 시스템의 유지보수, 설계의도를 명확히 정의가능
• MVC패턴 또한 디자인패턴의 한 종류

2. MVC 패턴 정의

• Model, View, Controller의 약자 → 프로젝트(또는 애플리케이션)를 구성할 때 세가지의 역할로 구분한 개발 방법론
• 사용자가 Controller 조작 → Model을 통해 데이터를 가져옴 → View에서 제어해 사용자에게 전달

2-1.  Model 모델

• 백그라운드에서 동작하는 비즈니스 로직(데이터)처리 / 프로젝트(애플리케이션)의 정보, 데이터
• 규칙 - 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다
          - View나 Controller에 대해서 어떤 정보도 알지 말아야한다
          - 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다
     

2-2. View 뷰

• 사용자에게 보여지는 부분, User Interfaca(UI) / 데이터 및 객체의 입력, 출력 
• 규칙 - 모델이 가지고 있는 정보를 따로 저장해서는 안된다
          - 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 한다
          - 변경이 일어나면 변경통지에 대한 처리방법을 구현해야만 한다

2-3. Contoller 컨트롤러

• Model(데이터)과 View(사용자 인터페이스)의 사이를 이어주는 다리역할
• 규칙 - 모델이나 뷰에 대해 알고 있어야 한다
          - 모델이나 뷰의 변경을 모니터링 해야한다

3. MVC 패턴 사용이유

•  비즈니스로직과 UI로직을 분리  → 유지보수성이 높음
• 결합도가 낮음
• Model, View가 다른 컴포넌트들에 종속되지 않아 확장성, 유연성에 유리
• 기능별로 코드를 분리 → 가독성, 재사용성 증가

4. MVC 패턴 한계

• 컨트롤러가 불필요하게 커지는 현상 발생
• 컨트롤러에 다수의 model과 view가 복잡하게 연결되는 상황 발생가능

5. MVC 패턴의 예

• Google의 Angular JS
• PHP의 CODEIGNITER
• Python의 django
• Facebook의 React등

참고) https://readystory.tistory.com/114

참고) https://cocoon1787.tistory.com/733

참고) https://zwzwzw123-daily-daily.tistory.com/94

1. Git

• Version Control System(VCS)로 로컬에서 관리되는 버전관리 프로그램
• 소스코드 수정에 다른 버전을 관리해주는 시스템

* VCS : 파일 변화를 시간에 따라 기록했다가 특정 시점의 버전을 다시 불러올 수 있는 시스템

• 코드와 수정내역을 기록/관리하도록 돕는 버전관리 프로그램
• 브랜치를 생성/복구/삭제/병합 가능
• 혼자 작업하거나 폐쇄적인 범위의 협업
• 개발자와 실시간 작업공유 불가능(로컬 저장소를 사용하기 때문)

2. Github

• 클라우드 방식으로 관리되는 버전관리 시스템
• Git Repository를 위한 웹기반 호스팅서비스
• 클라우드 서버(자체구축x)를 사용해 로컬에서 버전관리한 소스코드를 업로드하여 공유가능
• 저장소를 깃허브에서 제공해주는 클라우드 서버를 이용
• 협업시 오픈소스 공유가능

3. Git 관련 용어

• 로컬 저장소(local repository) : 내 PC에서 관리하는 git저장소
• 원격 저장소(remote repository) : 로컬저장소를 업로드 하는 곳 (ex. GitHub, Bitbucket,GitLab 등)
• Staging Area(Index) : 작업 폴더에서 작업한 변경 내용을 기록하는 곳(git저장소에 commit하기 전 올려두는 공간) 
• 커밋(commit) : Git(로컬 저장소)에 파일을 추가하거나 변경 내용을 저장하는 작업
• 푸쉬(push) : Github(또는 원격 저장소)에 파일을 추가하거나 변경 내용을 저장하는 작업
• 풀(pull) : Github(또는 원격 저장소)에 파일을 다운로드하는 작업
• 머지(merge) : 브랜치 병합

3-1. commit type

• feat : 새로운 기능 추가
• fix : 버그 수정
• docs : 문서 수정
• style : 코드 포맷팅, 세미콜론 누락, 코드변경이 없는 경우
• refector : 코드 리펙토링
• test : 테스트 코드, 리펙토링 테스트 코드 추가
• chore : 빌드업무 수정, 패키지 매니저 수정

4. Git의 3가지 영역

• Working Directory : 내가 작업하고 있는 프로젝트의 디렉토리
• Staging Area : 커밋하기 위해 $git add 명령어로 추가한 파일들이 모여있는 공간 
• Repository : 커밋들이 모여있는 저장소

5. Staging Area

어떤 변경사항이 저장소에 커밋되기 전에 반드시 거쳐야하는 중간단계이다.

Staging Area에 추가한 파일들을 commit 하면 최종적으로 저장소(Repository)에 저장된다.

6. 정리

Git은 버전관리 프로그램이고

Github는 버전관리, 소스코드 공유, 분산버전제어 등이 가능한 원격 저장소다.

1. TDD (Test Driven Development) 란?

TDD는 '테스트 주도 개발'로 작은 단위의 테스트 코드를 작성해 프로그램이 잘못되었음을 증명하고,

이를 수정하면서 목표에 부합하는 코드를 추가하는 단계를 반복 구현하는 소프트웨어 방법론이다.

일반적인 개발방식은 '요구사항 분석 > 설계 > 개발 > 테스트 > 배포'의 형태.

이러한 방식은 소프트웨어 개발을 느리게 하는 잠재적 위험 존재

작은 부분의 기능 수정에도 모든 부분을 테스트해야하므로 전체 버그 검출이 어려워짐

TDD의 대표적인 Tool 'JUnit'은 가장 널리 사용되는 Java 단위 테스트 프레임워크이다.

최근에는 동작 테스트 뿐만아니라 jenkins(빌드자동화를 위한 ) 등의 ci 도구를 사용할 때

테스트 코드의 성공여부를 확인해 pr을 통과시키거나 운영브랜치로 merge 시키는 등의 추가동작에도 많이 활용된다.

2. TDD 개발주기

- RED : 실패하는 테스트 코드를 작성한다.

- GREEN : 테스트 코드를 성공시키기 위한 실제 코드를 작성

- BLUE : 중복 코드 제거, 일반화 등의 리팩토링 수행- 

- TDD 세부프로세스

단위 테스트 작성 > 단위 테스트 실행 > 운영 코드 작성 > 단위 테스트 실행 > 설계 개선(리팩토링) > 단위테스트 ...반복

3. 어떤 상황에서 TDD를 해야할까?

TDD는 사용설명서이자 의사소통의 수단이 되므로 피드백과 협력이 증진되어, 불확실성에 대비가 가능해진다.

처음 해보는 프로그램 주제이거나(내부의 불확실성), 고객 요구조건이 바뀔 수 있는 프로젝트(외부의 불확실성),

누가 유지보수할 지 모르는 경우 등의 상황에 적용하면 좋다.

4. TDD 장점

- 개발자의 의도대로 로직이 동작하는지 명확히 알 수 있다. (개발의 방향성을 잃지 않게 유지)

- 잠재적 오류를 방어하여 디버깅 시간과 재설계 시간을 단축할 수 있다.

- 로직 변경에 대한 영향도를 명확히 알 수 있고, 추가 구현이 용이하다.

5. TDD 단점

- 생산성의 저하

(SI 프로젝트에서는 소프트웨어 품질보다 납기일 준수가 중요하므로 TDD 방식을 잘 사용하지 않음)

- 기존의 개발방식을 많이 바꾸어야함

- 구조에 얽매인다.

1. 프로그래밍 패러다임

- 프로그래밍 스타일을 의미하며, 전체적인 프로그래밍 방식을 말함

- 대표적으로 절차적, 객체지향, 함수형 프로그래밍이 존재한다.

- 크게 분류하면 명령형 / 선언형 프로그래밍으로 나눌 수 있다.

1-1. 명령형(Imperative)프로그래밍

: 프로그래밍 상태와 상태를 변경시키는 구문의 관점에서의 연산을 설명

(컴퓨터가 수행할 명령들을 순서대로 써놓은것)

- 절차적 프로그래밍, 객체지향 프로그래밍

- 명령형 프로그래밍 언어: C, C++, Java, Pascal, Ruby 

1-2. 선언형(Declarative)프로그래밍

: 필요한 것을 달성하는 과정을 기술하기보다 필요한 것이 어떤 것인지를 기술하는 것에 초점을 맞추는 프로그래밍 구조

: 목표를 명시하고, 알고리즘을 명시하지 않는 것으로 '무엇'에 집중하는 프로그래밍('어떻게'에 대한 부분은 추상화)

- 함수형 프로그래밍 : 

- 선언형 프로그래밍 언어 : HTML, Lisp, Haskell, Prolog, SQL, XML 

2. 함수형 프로그래밍

- 자료처리를 수학적 함수의 계산으로 취급하고, 상태와 가변데이터를 멀리하는 프로그래밍 패러다임.

- 순수함수를 조합하고 프로그램을 만드는 방법이다.

- 함수형 프로그래밍 언어 3대장 : Clojure, Scala(실무에 도입하기 좋음), Haskell(학계 정통파 순수 함수형 언어) 

- 자바스크립트, 코틀린, 파이썬 등에도 최근 함수형 프로그래밍 문법이 추가되었다.

- 외부환경으로부터 독립적. 주어진 작업만 한다.

수학의 원리와 밀접하게 연관. 매우는데 시간이 오래걸리고 난해..

그래서 사람의 사고방식과 가까운 절차지향, 객체지향 프로그래밍이 더 보편적으로 많이 쓰여지고 있음.

방대한 데이터를 빠르게 계산해서 병렬적으로 안정적으로 처리하는 것의 중요성이 부각되면서

함수형 프로그래밍 언어가 다시 주목을 받기 시작한것.

3. 함수형 프로그래밍의 특징

3-1. 순수함수 Pure function

- 함수의 실행이 프로그램 실행에 영향을 미치지 않아야 하는 함수

- 함수 내부에서 인자의 값을 변경하거나 프로그램 상태를 변경하는 side effect 가 없는 것.

- 함수에서 외부의 상태값을 참조하거나 또는 외부의 상태를 변경하는 것은 순수함수라 볼 수 없다!

- 동일한 인자를 넣었을 때 항상 동일한 결과값을 반환하고, 언제 선언되었는지 외부에 영향받지 않도록 작성해야한.

3-2. 비상태 Stateless , 불변성 Immutability

- 함수형 프로그래밍에서의 데이터는 변하지 않는 불변성을 유지해야한다.

- 데이터의 변경이 필요한 경우 원본 데이터 구조를 변경하지 않고,

그 복사본을 만들어 그 일부를 변경하고 변경한 복사본을 사용해 작업을 진행

(전달된 데이터를 변경하는게 아니라 새로운 버전의 새로운 오브젝트를 만들어서 결과값으로 전달해야함)

- 변경하지 않음으로서 부작용(함수호출시 외부상태변경, 예상치못한 에러발생 등)을 만들지 않음

- 멀쓰레딩 환경(여러 스레드가 동시에 하나의 자원을 공유하고 있기때문에 같은 자원을 두고 경쟁상태와 같은 문제가 발생)에서도 안정적으로 동작한다.

3-3. 선언형 함수 Expressions

- 선언형은 "무엇"을 할 것인가에 주목 / 명령형은 무엇을 "어떻게"할 것인가에 주목 

- if, for, switch와 같은 명령문을 사용하지 않고 프로그래밍한다.

3-4. 1급 객체와 고차함수 First-class, Higher-order functions

- 1급객체의 특징 : 변수나 데이터 구조 안에 담을 수 있다. 파라미터로 전달할 수 있다. 반환값으로 사용할 수 있다.

할당된 이름과 관계없이 고유한 구별이 가능, 동적으로 프로퍼티 할당 가능.

- 고차함수의 특징 : 함수를 인자로써 전달할 수 있어야한다. 함수의 반환값으로 또 다른 함수를 사용할 수 있다.

4. 함수형 프로그래밍의 장점

- 높은 수준의 추상화 제공(복잡한 자료, 모듈, 시스템 등으로부터 핵심 개념, 기능을 간추려냄)

  * 함수의 기본원칙 '함수는 한가지 동작만 해야함' => 여러 동작을 동시에 수행하면, 다른 함수, 모듈과의 종속성이 커져        유지보수가 어려워짐.

- 함수 단위의 코드 재사용 수월

-. 불변성을 지향하므로 프로그램 동작 예측이 쉽다

5. 함수형 프로그래밍의 단점

- 코드의 가독성이 좋지 않을 수 있음

- 반복을 for문이 아닌 재귀함수를 통해 이루어지는데(deep copy), 재귀적 코드스타일은 무한루프에 빠질 수 있다.

* 재귀함수 : 함수 안에 자신의 함수를 다시 호출하는 함수. 자신의 로직을 내부적으로 반복하다가 일정 조건이 만족되면

함수를 이탈하여 결과를 도출한다.

- 순수함수의 사용은 쉬울 수 있으나, 조합은 쉽지 않다.

6. 정리

ui 어플리케이션은 특성상 많은 상태변화가 일어나므로 순수함수형프로그래밍만을 이용해서는 무리가 있다고함.

따라서 '함수형 반응형 프로그래밍'을 이용하거나, 객체지향프로그래밍에서 함수형프로그래밍의 특징을

결합해 안정적인 프로그램을 하는 식으로 활용. 

원하는 목표에 따라 적절한 것을 잘 골라 사용해하고, 여러 패러다임을 잘 이해하고 두루 알아야 한다.