개발일기🌷

1. 메모리 구조(Memory Structure)

• 운영체제(Operating System)의 메모리 구조
  → 커널영역 : kernel 은 운영체제의 핵심, 커널영역은 system call을 통해 커널모드로 전환해야만 접근 가능
  → 유저영역 : Code, Data, Stack, Heap 4가지로 구성
• 프로그램 실행을 위해 운영체제가 프로그램 정보를 메모리(RAM)에 공간을 할당해주어야함
  → CPU가 코드를 처리하기 위해서는 메모리가 명령어와 데이터들을 저장해야함
  → 할당받는 대표적인 메모리공간(=유저영역)

2. Code 영역 ( = Text 영역 )

• 기계어로 컴파일되어 적재되는 코드 자체의 영역 / Read-only
• 실행할 프로그램의 코드가 저장되는 영역
• 프로그램의 시작부터 종료까지 메모리에 계속 남아있음
• CPU는 이 영역에 저장된 명령을 하나씩 가져가 처리

3. Data 영역

• 전역변수(Global)와 정적변수(Static)가 저장되는 영역
• 프로그램 시작과 함께 할당되고, 프로그램이 종료되면 소멸
• Read-Write

4. Heap 영역

• 프로그래머가 직접 공간을 할당, 해제하는 공간
  → 메모리 할당 : malloc() 또는 new 연산자 이용
  → 메모리 해제 : free() 또는 delete 연산자 이용

5. Stack 영역

• 프로그램이 자동으로 사용하는 임시 메모리 영역
• 호출시 지역변수, 매개변수가 저장되고, 호출완료되면 사라짐
  → 저장된 함수의 호출정보 : stack frame
  → 저장 : push / 인출 : pop

6. Heap VS Stack

7. 오버플로우

• 할당 가능한 메모리 영역을 넘어설 때 발생하는 오류
  → 이러한 특성을 이용해 해킹공격에 사용될 수 있다고함
• 종류
  → 힙 오버플로우 : 힙이 스택을 침범하는 경우
  → 스택 오버플로우 : 스택이 힙을 침범하는 경우, 오버플로우 중 가장 많이 발생

참고) https://mentum.tistory.com/475

참고) https://zangzangs.tistory.com/107

참고) https://hdacker.tistory.com/6

1. 클린코드란?

• 원하는 로직을 빠르게 찾을 수 있는 코드
• 모든 팀원이 해당 코드의 동작을 직관적으로 예측하기 쉽도록 작성된 코드
• 성능향상 / 가독성이 좋아 코드의 의미가 명확 / 중복을 제거해 생산성 향성

2. 클린코드의 중요성

• 유지보수 시간 단축(코드리뷰, 코드파악, 디버깅 시간 단축)
• 기술부채감소 (Technical Debt 기술부채  : 쉬운 솔루션을 채택함으로써 발생되는 추가적 재작업의 비용)

3. 클린코드의 원칙(General)

• Follow Standard Conventions : 코딩의 표준, 아키텍쳐 표준 및 설계 가이드 준수
• Keep it Simple, Stupid(KISS) : 단순한 것이 효율적, 복잡합을 최소화
• Boy Scout Rule : 참조되거나 수정되는 코드는 원래보다 클린하게 해야함
• Root Cause Analysis : 항상 근본적인 원인을 찾아라. 그렇지 않으면 반복될 것
• Do not Multiple Languages in One Source File : 하나의 파일은 하나의 언어로 작

3-1. 객체지향설계 SOLID 원칙(Class Design) → 설계관점 클린코드시 많이 회자된다고 함.

참고) https://talkwithcode.tistory.com/73

참고) https://zwzwzw123-daily-daily.tistory.com/96?category=994308 

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는 버전관리, 소스코드 공유, 분산버전제어 등이 가능한 원격 저장소다.