기술면접 - Progamming

김문범·2021년 9월 29일

interview

기술면접 준비목록

목록 보기

4/4

1. 객체 지향 프로그래밍(Object Oriented Programming - OOP)

1-1. 객체 지향 프로그래밍(Object Oriented Programming - OOP)이란?

기능(행위, 메소드)과 데이터(변수, 필드)들을 하나로 묶어서 객체를 만들고, 각각의 객체는 메소드 및 필드를 호출하는 등의 상호 작용을 통해 흐름(로직, 알고리즘)을 구성하는 방법

객체라는 용어가 개념이 혼란스럽다면, 참조 사이트 3번을 참고하여 더보기를 확인해 보세요.

1-1-1. 개념적 혹은 문과감성에 의한 객체란?

인간 중심에서 객관적으로 인지할 수 있는 대상들이 바로 객체(Object)이다.

나와 너가 있으면,
나는 너를 볼 때 너는 객체이고,
너가 나를 볼 때, 나는 객체이다.

1-1-2. 객체, 클래스, 인스턴스의 구분

객체(Object) : 소프트웨어(프로그래밍)로(으로) 구현해야 할 대상
클래스(Class) : 객체를 만들어 내기 위한 설계도 혹은 틀
인스턴스(Instance) : 클래스(설계도)를 바탕으로 만들어진 객체가 메모리에 할당되어 실체화된 객체이자 인스턴스

개념적으로 인스턴스는 객체에 포함된다.
하지만, 메모리에 할당되지 않은 객체는 인스턴스라고 말하기는 어렵다.

/* JAVA 스타일 */

/* 클래스 */
public class Animal {
  /* 필드 */
  Public String name;
  
  /* 메소드 */
  Public void method() {
    ...
  }
  ...
}
/* 객체와 인스턴스 */
public class Main {
  public static void main(String[] args) {
    Animal cat, dog; // '객체'

    // 인스턴스화
    cat = new Animal(); // cat은 Animal 클래스의 '인스턴스'(객체를 메모리에 할당)
    dog = new Animal(); // dog은 Animal 클래스의 '인스턴스'(객체를 메모리에 할당)
  }
}

1-2. 객체 지향 프로그래밍(Object Oriented Programming - OOP)의 장점

유지보수가 쉽다. - 캡슐화로 인해 쉽다.
코드의 재사용성이 높다. - 상속을 통한 확장 / 변형(수정)이 쉽다.
대형 프로젝트에 적합하다.
현실 세계와 유사성이 높아 코드 이해가 쉽다.(하지만, 과연? - 구조적으로는 쉽게 이해하지만, 정작 직접 사용하려면 러닝커브가 있음.)

1-3. 객체 지향 프로그래밍(Object Oriented Programming - OOP)의 단점

속도가 느리고 많은 양의 메모리를 사용하는 경향이 있다.
상대적으로 용량이 커질 수 있다.
설계 과정에 많은 시간과 노력이 필요하다.

1-4. 객체 지향 프로그래밍(Object Oriented Programming - OOP)의 특징(?), 키워드(?)

1-4-1. 추상화(Abstraction)

구현해야하는 대상들의 공통점을 찾아 하나의 집합으로 만드는 것

예시)
강아지, 고양이 등은 모두 '동물'이라는 공통점이 있음.
이러한 것들을 '동물'이라는 객체로 정하고, 그에 따른 공통적인 동물의 특징, 행동 등을 필드와 메소드로 추출한다.
모든 것을 정리하여 클래스로 만든다.

1-4-2. 캡슐화(Encapsulation)

목적 : 응집도를 높이고 결합도를 낮춘다.
1. 공통적인 부분(메소도, 필드)을 묶어서 하나로 집합으로 만든다.
2. 공개된 부분을 제외한 나머지는 외부의 접근을 차단한다.

1-4-3. 상속(Inheritance)

다른 클래스의 메소드와 필드를 그대로 가져와서 기능의 확장 또는 일부를 수정하여 사용한다.

1-4-3. 다형성(Polymorphism)

하나의 변수명, 함수명 등이 상황에 따라 다른 의미로 해석될 수 있다.

오버라이딩(Overriding) : 부모클래스의 메소드와 같은 이름, 매개변수를 자식클래스에 재정의 한다.
오버로딩(Overloading) : 2개 이상의 같은 이름을 가진 메소드를 정의하고, 매개변수의 타입과 개수를 다르게 하여 매개변수에 따라서 다른 것을 호출할 수 있게 한다.

1-4-4. getter와 setter가 필요한 이유

메소드를 통해서 접근하기 때문에, 올바르지 않은 매개변수의 입력을 제한할 수 있고, 디버깅 시 어느 곳에서 접근하는 가에 대한 확인이 가능하다.
실제 멤버변수로 값을 저장하지는 않지만 클래스에서 멤버변수가 있는 것처럼 보여줄 때 사용한다.(이러한 경우가 있을까?)

보통은 1번을 생각한다. 하지만, 2번도 찾게 되어서 추가한다.
참조한 사이트 - getter와 setter가 필요한 이유

1-5. 객체 지향 프로그래밍(Object Oriented Programming - OOP)의 설계 원칙 : SOLID

1-5-1. SRP(Single Responsibility Principle) : 단일 책임 원칙

클래스는 단 하나의 책임을 가져야 하며, 클래스를 변경하는 이유는 단 하나의 이유이어야 한다.

1-5-2. OCP(Open-Closed Principle) : 개방-폐쇄 원칙

확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.
기능을 변경하거나 확장할 수 있으면서, 그 기능을 사용하는 코드는 수정하지 않는다.

1-5-3. LSP(Liskov Substitution Principle) : 리스코프 치환 원칙

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

1-5-4. ISP(Interface Segregation Principle) : 인터페이스 분리 원칙

인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.
각각의 사용자가 필요로 하는 인터페이스들로 분리함으로써, 각각의 사용자들이 사용하지 않는 인터페이스에 변경이 있더라고 영향을 받지 않도록 만들어야 한다.

1-5-5. DIP(Dependency Inversion Principle) : 의존 역전 원칙

고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.
저수준 모듈이 변경되어도 고수준 모듈은 변경할 필요가 없다.

2. CI(Continuous Integration, 지속적인 통합) / CD(Continuous Delivery[Deployment], 지속적인 제공[배포])

어플리케이션 개발 단계부터 배포 때까지 이 모든 단계들을 자동화를 통해서 조금 더 효율적이고 빠르게 사용자에게 자주 배포할 수 있도록 만드는 것

2-1. CI(Continuous Integration, 지속적인 통합)

코드의 수정 사항을 저장소(Repository)에 자주 통합(merge)를 해야한다.
통합을 위한 단계(Build, Test, Merge)의 자동화

종합적으로,
1번을 자주하지 않는다면 나중에 코드가 너무 변경사항이 많아 적용이 힘들어진다. 그에 따른 통합을 위한 에러 수정 등에 너무 많은 시간이 소모된다.
2번을 통해 문제점을 빠르게 발견할 수 있고, 버그 수정이 용이하며 그에 따른, 개발 생산성 및 코드의 퀄리티가 향상된다.

CI의 핵심 = 버그를 신속하게 찾아 해결하고, 품질을 개선하고, 통합을 위한 시간을 단축시킨다.

2-2. CD(Continuous Delivery[Deployment], 지속적인 제공[배포])

Continuous Delivery와 Continuous Deployment의 차이점은 마지막 단계로 사용자에게 업데이트가 배포되기 전에 검증하는 것을 자동으로 처리하면 Deployment이고 수동으로 확인 후 처리되면 Delivery이라고 한다.

3. 개발 방법론 - 워터폴, 애자일

3-1. 워터폴(Waterfall)

전통적인 개발 방법론
요구분석부터 기획, 개발, 테스트, 출시까지 순차적으로 진행
순차적으로 처리하는 흐름이 폭포수가 떨어지는 모습처럼 보인다고 하여 작명된 개발 방법론

프로젝트 전체를 요구분석, 기획을 하기 때문에 이러한 과정을 거치고 개발을 하면, 중간에 종종 고객의 요구가 있어서 결과물에 있어서 고객이 100%를 만족하는 제품이 없다는게 문제가 된다.
이러한 문제를 개선하기 위해 고객의 요구를 받아서 다시 요구분석, 기획 등의 단계를 거치면 시간과 비용이 낭비가 된다.

3-2. 애자일(Agile)

전통적인 방법 워터폴의 문제점들을 개선하기 위해 많은 수의 개발 방법론이 나왔으며 그 중에 대표적인 한 가지이다.
Agile => 민첩한, 재빠른, 기민한...
요구사항을 재빠르게 대응하여 충족시킨 개발을 통해 고객에게 직접 보여주고, 피드백을 받아서 개발을 하는 방법론
고객과의 소통을 통해 제품을 개발하여 나가는 방법이라고 할 수 있을 것 같다.

3-2-1. 스크럼(Scrum)이란?

5 ~ 9명으로 구성되는 소규모의 팀이 제품 개발을 하기 위해 스프린트(Sprint)를 반복한다.
스프린트(Sprint)는 작업의 단위, 스프린트 백로그(Sprint Backlog)는 스프린트 각각의 작업 목록
일일 스크럼 회의는 모든 팀원이 참가하고, 짧게 진행하고, 상황을 점검한다.

3-2-2. 칸반(Kanban)이란?

게시판(벽, 화이트보드 등)을 구성 방식에 따라 구간을 나누어 작업의 현재 상태와 흐름을 시각적으로 보여주는 방법
프로젝트의 모든 참가자가 프로젝트의 진행상태를 확인 가능
기본적인 구성방식은 계획, 진행중, 완료
WIP(Work-In-Process)를 즉, 진행 중인 일에 대한 개수를 최소한으로 제한하는 것이 가장 중요하다.

참조한 내용의 사이트 목록

김문범

다양하지만 공부할 것이 많은 개발자입니다.

이전 포스트