3 분 소요


병렬 프로그래밍

큰 문제를 작게 나누어 동시에 해결할 때 사용하는 프로그래밍 방식.
병렬 프로그래밍은 큰 문제를 프로세스 혹은 스레드가 나누어 처리를 하기 때문에 처리 속도가 향상된다는 장점을 가지만, 구현 난이도가 높다는 것이 단점.

병렬 프로그래밍 유의 사항

뮤텍스나 세마포어를 사용해도 데드락이 발생할 수 있다.

뮤텍스

공유 자원에 단 하나의 스레드만 접근하도록 하여, 공유 자원을 사용중인 스레드가 작업을 완료할 때 까지 기다리게 하는 것.

세마포어

공유 자원을 여러 스레드가 사용하려고 할 때 지정해 둔 최대 허용치 까지만 접근을 허용하고, 나머지는 대기하게 하는 것.


CI / CD(Continuous Integration / Continuous Delivery)

개념

애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법.

탄생

프로젝트를 배포했는데, 올바르게 작동하지 않아 문제가 발생했다면, 빠르게 문제를 수정해야만 한다.
코드 수정 후에는 다시 컴파일, 빌드, 배포 과정을 통해 수정된 코드가 제대로 동작하는지 테스트하고, 검증할 필요가 있다.
이 과정은 시간도 많이 걸리고, 수정된 코드에서 문제가 발생하면 이 과정을 다시 반복해야 한다.
이를 위해서 CI/CD가 탄생했다.

CI(Continuous Integration)

지속적 통합이라는 뜻으로 개발을 진행하면서도 품질을 관리할 수 있도록 하는 것.
CI를 적용하면, 개발자가 단위별로 구현한 부분을 브랜치에 병합하기만 하면 자동으로 빌드와 테스트가 트리거되어 실행된다.
이 결과를 통해 어떤 부분에서 문제가 있는지 배포전에 확인할 수 있고, 배포 후에 버그를 수정할 수 있던 기존의 방식보다 빠르고 정확하게 해결할 수 있다.
결과적으로 버그를 신속하게 찾아 해결할 수 있을 뿐 아니라, 새로운 SW 업데이트를 검증하고 릴리즈하는데 걸리는 시간을 단축할 수 있다.

CD(Continuous Deployment)

지속적 제공(Continuous Delivery)은 소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 관리하자는 개념.
지속적 제공은 CI를 통해서 빌드와 테스트 병합까지 성공적으로 진행되었다면, github과 같은 저장소에 업로드 하는것을 의미.
지속적 배포는 성공적으로 병합한 내역을 저장소 뿐만 아니라, 사용자가 사용할 수 있는 배포환경까지 릴리즈하는 것을 의미.

CI/CD의 방법으로는 Travis와 Jenkins가 있다.


객체지향

객체지향 프로그래밍은 구현에 필요한 객체를 파악하고, 각각의 객체들의 역할이 무엇인지 정의하여, 객체들 간의 상호작용을 통해 프로그램을 만드는 방식

객체 지향 프로그래밍의 장/단점

장점

  • 코드 재사용이 용이하다.
    • 다른 사람이 만든 클래스를 가져와서 이용할 수 있고, 상속을 통해 확장해서 사용할 수 있다.
  • 유지보수가 쉽다.
    • 절차 지향 프로그래밍에서는 코드를 수정해야 할 때 일일이 찾아 수정해야 하지만, 객체지향 프로그래밍은 수정해야 할 부분이 클래스 내부에 변수 혹은 메서드로 존재하기 때문에 해당 부분만 수정하면 된다.
  • 대형 프로젝트에 적합
    • 클래스 단위로 모듈화 시켜서 개발할 수 있으므로, 여러 명, 여러 회사에서 프로젝트를 개발할 때 업무를 분담하기 쉽다.

단점

  • 처리 속도가 상대적으로 느림
  • 객체가 많으면 용량이 커질 수 있음

클래스와 인스턴스(객체)

  • 클래스 : 객체를 만들어 내기 위한 설계도 혹은 틀
  • 객체 : 클래스에 선언된 모양 그대로 생성된 실체. (설계도로 구현한 모든 대상)
    • 클래스의 인스턴스라고도 한다.
  • 인스턴스 : 클래스에서 정의한 것을 토대로 실제 메모리에 할당된 것.

클래스의 타입으로 선언되었을 때 객체라고 부르고, 그 객체가 메모리에 할당되어 실제 사용될 때 인스턴스라고 부른다.

객체 지향의 특징

추상화

  • 객체에서 공통된 속성과 기능을 찾아서 타입을 정의하는 것.
  • 추상화는 불필요한 정보는 숨기고, 중요한 정보만을 표현함으로서 프로그램을 간단하게 만드는 것.
  • EX) Car -> 현대, 기아, 아우디 등..

캡슐화

  • 서로 연관있는 속성과 기능들을 클래스라는 하나의 캡슐로 만들어 데이터를 외부로부터 보호하는 것.
  • 변수와 메서드를 클래스라는 캡슐에 넣어서 분류하기 때문에 객체 재활용이 원활하다는 장점이 있고, 접근 제어자를 활용해 정보 은닉을 활용할 수 있다.

상속

자식 클래스가 부모 클래스의 속성과 기능을 그대로 물려받아 사용할 수 있게하고, 필요에 따라 기능을 확장하여 사용할 수 있게 하는 것.

장점

  • 재사용으로 코드가 줄어든다.
  • 범용적인 사용이 가능

단점

  • 상위 클래스의 변경이 어려워진다.
  • 불필요한 클래스가 증가할 수 있다.

다형성

하나의 변수명, 함수명이 상황에 따라 다른 의미로 해석될 수 있는 것.
대표적으로 오버라이딩과 오버로딩이 있다.

  • 오버라이딩 : 상위 클래스가 가지고 있는 메서드를 하위 클래스가 재정의해서 사용하는 것.
  • 오버로딩 : 같은 이름의 메서드가 인자의 개수나 자료형에 따라 다른 기능을 하는 것.

객체 지향 설계 원칙(SOLID)

단일 책임 원칙(SRP, Single Responsibility Principle)

  • 하나의 클래스는 하나의 책임만 가져야 한다.
  • 단일 책임 원칙을 지키지 않을 경우 한 책임의 변경에 의해 다른 책임과 관련된 코드에 영향이 갈 수 있다.

개방-폐쇄 원칙(OCP, Open/Closed Principle)

  • 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
  • 기능을 변경하거나 확장할 수 있으면서 기능을 사용하는 코드는 수정하지 않는다.
    • 문제 해결 : 객체를 생성하고, 연관관계를 맺어주는 설정자 필요

리스코프 치환 원칙(LSF, Liskov Substitution Principle)

  • 상위 타입의 객체를 하위 타입의 객체로 치환해도, 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.

인터페이스 분리 원칙(ISP, Interface Segregation Principle)

  • 범용 인터페이스 하나보다 특정 클라이언트를 위한 여러 인터페이스로 구성하는 것이 좋다.
  • 인터페이스를 분리함으로써 클라이언트가 사용하지 않는 인터페이스에 변경이 있어도 영향을 받지 않도록 만들어야 한다.

의존관계 역전 원칙(DIP, Dependency Inversion Principle)

  • 구체화에 의존하지 말고, 추상화에 의존해야 한다.
    • 즉, 구현 클래스에 의존하지 말고, 인터페이스에 의존해라.

댓글남기기

참고