끝이 없을 모험 이야기

man-month: 한달에 투입되는 사람수(소프트웨어를 개발할 때 얼마나 많은 사람이 투입되어야 하는가), 정량적 수치

1 man-month: 한 사람이 한달동안 풀로 들어가는 것

12 M/Ms = 12명이 1달 = 1명이 12달?에 대한 문제 발생 -> 문제가 없는 논리이지만 소프트웨어에서는 안 통한다.

늦어진 소프트웨어 프로젝트에 사람을 추가하는 것은 더 늦게 끝나게 한다.

책(직접 겪었던 프로젝트 관리 실패담들을 모은 책)에서 강조한 것

man-month

Second system effect

prototyping

이전처럼 소프트웨어를 관리하는 것은 실패

-> man-month쓰기 부적절, 변수가 많음. 환상이다.

   길어지는 이유

   1.새로운 사람 뽑으면 교육하는데 오래 걸림

        (애자일로 training 시간이 더 오래 걸리게 됨. 문서 수가 적으므로)

Man-month의 문제점: SW개발에서 서로 다른 팀끼리의 소통이 필수적이지만 사람이 늘어나면 소통이 길어질 수밖에 없다.

케이스 바이 케이스(no silver bullet)

한가지 방법이 모든 문제에 적용되지는 않는다.

!!!!!!!경험이 레퍼런스가 될 수 있으나 다른 문제의 솔루션이 될 수 없음!!!!!!!!!!!!!

이렇게 해결 가능한 완전 재사용가능한 프로그램은 없음

Second-system Effect

첫번째 시스템에서 느꼈던 아쉬운 점, 못 만든 기능들을 다 넣을려고, 만들려고 한다. 따라서 반드시 필요한 개선점이 들어가야 하는 것이다. 오버하는 것은 지양해야 한다.

Over-engineering

개발자들의 문제를 관리자들이 이해해야함 그리하지 못함

!!!!!!!!!!!!! Second-system에는 반드시 필요한 것들만 추가 개선!!!!!!!!!!!!!

Irreducible number of errors

버그가 없는 프로그램은 존재하기 힘들다. 따라서 작은 버그는 두고 큰 버그들을 해결해야 한다. 정성, 정량적으로 버그의 level을 나눠서 사소한 버그들은 두고, 큰 버그들을 다뤄야 한다.

Progress tracking

수면 위에 드러나지 않은 문제들로 전체적인 시간 delay가 있을 수 있다.

소프트웨어 개발이 어떻게 1년이나 늦어지는 거지? 하루에 한 시간씩 늦어지면 그럴 수도 있지.

애자일: 데일리 스크럼등으로 자주 대화하는 이유가 이러한 문제들을 파악하고 해결함

즉 각자 알아서 하라고 내버려두는 것이 아니라 소통을 통해 문제들 파악하게 하는 것

Conceptual integrity

소프트웨어를 만들 때 소프트웨어가 가져야 할 철학, 일관성

Waterfall 방식인 것 같음.

시스템 아키텍쳐: 시스템을 설계(기술적인 부분)

프로젝트 매니저: 프로젝트를 관리, 행정을 한다.

하나의 시스템 설계팀이 철학, 일관성에 따라 결정한다. Ex) 스티브 잡스, 다이슨

하나의 설계팀에서

SW의 전체적인 구조 설계와 철학, 일관성을 고려한 결정을하고 계획함

추가적인 기능등도 일관성 측면에서 판단하고 추가 또는 배제함

The Manual(개발과 관련됨, 시스템 아키텍쳐가 쓰는 것)

설계자가 매뉴얼 정의 -> 맞춰서 개발

The pilot system(권장 사항) = Prototype(주요 기능을 구현해보고 확인하고 나서 버린다.)

첫번째로 만든 시스템은 대부분 시행착오를 겪고 잘못된 설계 하에 채워질 수 있으니 상용화 하지 말고 버려라.

프로그램에서 검증해야할 중요한 것들 중심으로 먼저 만들어보기

Formal documents(project manager)

Product Manager(PM): 관리쪽(개발X)

이들이 만드는 문서에는

프로젝트의 목적, 누가 만드는지, 언제 만들어질 건지, 비용 등

포함됨 (개발관련 X)

project estimation:

공식적인 개발과 관련된 일정을 누가 얼마에 하는지 등을 계산(행정)

어떤 SW를 파는 것은 만드는 것과 다른 얘기

상용화 하기 위한 준비기간이 매우 김

waterfall일때 전체 기간의 30퍼센트만 개발 기간이 주어짐

Communication

큰 문제 피하기위함

탑다운일 때, 내가 결정하는 것이 아닌 물어봐야함(전체철학에 맞는지)

업무의 경우 이메일로(주장 및 근거, 책임...)

통화, 대화로 하지 않는다

The surgical team

파일럿 팀: 유능한 사람들이 먼저 개발하고

그 뒤에 대체 인력 투입

개발자의 능력은 동일하지 않다.

Code freeze and system versioning: 코드를 얼린다=개발을 종료한다.

오류가 있어도 code freeze 했으면 손을 데지 않아야 한다. 완벽할 수는 없다.

요구 사항을 더이상 받지 않고 개발 종류 선언

완벽한 SW가 아닐 수 있으나 괜찮음 원래  그럼

Specialized tools

개발 도구를 직접 개발한다. 반복적인 일을 도구로 만든다. Ex) 업무 자동화.

Ex) projectlibre

Lower software development costs

소프트웨어 개발 비용을 낮추는 것이다. 어떤 조직에서는 개발하는 사람이 항상 필요하지는 않다.

코딩이 필요한 시간에만 개발자를 고용하라

요구사항을 만족하는 오픈소스나 상용 제품이 있다면 그것을 그냥 쓰는 것도 나쁘지 않다.

오픈소스 라이선스: 소프트웨어를 출시하고 사용할 때 신경 써야 할 중요한 부분

오픈소스의 정의

배포된 소스코드를 자유롭게 복사, 수정, 사용, 재배포 할 수 있는 소프트웨어를 뜻한다.

오픈소스 선택 시 고려사항

품질: 기능(우리가 원하는 기능이 있는가?), 성능, 호환성(얼마나 수정해야 하는가?) 등 오픈소스의 품질은 오픈소스를 선택하는 데 가장 중요한 요소다. 개발자 입맛에 따라 오픈 소스가 만들어지므로 오픈소스의 클래스, 메소드들이 다 다르다. github에서의 sta, fork수(정성적 정량 수치)로 오픈소스의 완성도를 가늠할 수 있다. 오픈소스를 사용하려는 기술 조직은 당연히 충분한 기능과 성능 검증을 수행한 후 제품/서비스에 도입해야 한다.

커뮤니티: 오픈소스가 얼마나 사용자를 보유하고 있는지, issue 관리는 이루어지고 있는지, 지속적으로 업데이트를 하는 지 등, 지속가능한 오픈소스를 선택해야 한다.

문서화: 문서화가 잘 되어있으면 기업이 도입하는 데 수월하다. 설명이 잘 되어 있는 것을 선택한다.

보안 취약점: 사용하려는 오픈소스의 버전이 보안 취약점이 있는지 확인 후 사용해야 한다. 보안은 OS 보안, 네트워크 보안, 웹 보안으로 나뉘는데 웹 보안이 가장 문제가 많다. CVE 사이트에서 사용하려는 오픈소스 보안 취약점을 체크해라.

라이선스: 오픈소스를 “재배포 시” 준수해야 할 의무사항을 요구한다. 가장 간단한 의무인 고지 의무부터 가장 복잡한 의무인 소스 코드 공개 의무까지.

GPL: 관련된 모든 소스코드를 공개(가장 강력한 라이센스)

오픈소스와 법적 책임

라이선스를 지키지 않으면 사용 권리가 박탈되고 제품을 판매할 수 없다. 또한 수익을 능가하는 돈을 내야 할 수도 있다. 기업 이미지에 큰 손실을 끼친다. 법적 소송에 연루될 수 있다.

오픈소스도 저작권 지식 재산권 존재

!!!!!!!!소스코드가 공개 되도 오픈소스 라이센스가 없으면 오픈소스가 아님!!!!!!!

오픈소스 라이선스의 주요 의무 사항

1. 저작권 표시 및 라이선스 고지: 가장 약한 라이선스, 소스 코드 파일 상단에 주석을 달거나 README 파일 안에 고지한다.

2. 소스코드 공개

3. 재배포시 동일 라이선스 적용: “Copyleft”

2,3을 동시에 요구하는 라이센스: GPL

오픈소스를 사내에서 테스트 용도로 사용한다면, 의무사항은 부과되지 않는다.

OSI: 오픈소스에 해당하는 라이선스의 최소한의 기준을 정의 해놓고 이 정의에 따라 오픈소스 라이선스를 인증함.

아무 조건 없이 사용 가능한 라이선스

Creative Commons Zero

The Unlicense: 아무런 제한을 걸지 않는 라이선스(아무런 제한을 걸지 않아도 라이선스를 등록 해야한다.)

수월하게 사용 가능한 라이선스(Permissive License)

오픈소스 라이선스의 고지 의무가 있는 라이선스

Ex) BSD, JSON License, MIT License, Microsoft Public License, Python Software Foundation License, Independent JPEG Group License

주의가 필요한 copyleft 라이선스

GPL은 재배포 시 소스코드 공개를 요구한다. +Create commons attribution.

이러한 오픈소스는 설계 단계에서부터 build 시 자사 소프트웨어와 통합되지 않고 runtime에도 독립된 프로세스로 동작되도록 해야한다.

GPL-3.0 같은 경우에는 제품을 배포하기 위해 소스 코드뿐만 아니라 설치 정보를 함께 제공해야 한다.

Weak Copyleft

LGPL: 메모리를 공유하는 방식인 Dynamic Linking 방식은 봐준다.

별도의 실행 파일을 통신으로 하면 GPL 라이선스를 겪지 않을 수 있다. LGPL Library 부분만 소스 코드를 공개하면 되고, 결합하는 코드는 공개를 하지 않아도 된다.

+apple, mozilla, eclipse

static linking: 코드가 링킹되어 하나의 실행 파일안에 링킹되어 있을때, 99개중 1개가 GPL 라이선스면 배포 시 100개가 모두 GPL이 걸리는 것이다.

dynamic linking: 별도 파일(dll)로 존재하여 필요할 때 메모리에 올려 사용

GPL: static,dynamic 둘다 소스코드 공개, 재배포시 동일 라이선스 적용

lGPL: dll은 봐주는 약화된 GPL

GPL우회법: 별도 프로그램 두개로 만들어서 '통신'으로 연결함

사용 제한 라이선스

네트워크에서는 gpl보다도 agpl이 더 강력하다. 서버에 agpl의 오픈소스가 있다면 배포하지 않아도 함께 링크되어 동작하는 다른 소프트웨어의 소스코드까지 agpl로 공개해야 한다. 회사의 핵심 서버 프로그램까지도 공개해야 하는 위험이 있다.

광고 조항 포함 라이선스도 있다.

소스코드 제공 의무 유형

GNU GPL, GNU AGPL: 모든 소스 코드를 공개해야함

GNU LGPL, NASA: static하게 연결된 모든 걸 열어라(파생 작업물)

Mozila, Sun public license: 코드가 아닌 파일 공개, 파일 단위로 열어라, 다는 아님.

이클립스: 모듈 단위(함수, 함수의 변형된 형태 공개), 다는 아님.

~ : 수정된 부분만 파일 단위로 공개

~ :모듈(함수의 수정된 부분만 모듈 단위로 공개)

Apache: 고지의무

GNU GPL

카피레프트, 자유 소프트웨어 재단에서 만든 라이선스, 배포하는 경우 무조건 GPL로 공개해야 한다. Dynamic Linking을 해도 GPL 라이선스.

별도의 실행 파일을 두개로 만들어서 통신으로 연결하면 GPL 라이선스를 겪지 않을 수 있다.

EX) 리눅스 커널, 워드프레스

GNU AGPL(server)

서버에 agpl의 오픈소스가 있다면 배포하지 않아도 함께 링크되어 동작하는 다른 소프트웨어의 소스코드까지 agpl로 공개해야 한다.

Ex) 몽고DB

GNU LGPL

좋은 자유 소프트웨어 제품이 더 많이 쓰이고 표준이 되도록 유도하기 위해 단순한 라이브러리, 모듈 링크를 허용한 라이선스.

EX) 모질라 파이어폭스

MIT License

MIT에서 소프트웨어 공학도들을 돕기 위해 개발한 라이선스. 가장 느슨한 조건을 가진 라이선스 중 하나이다. 고지의무를 가진다.

EX) 부트스트랩, Backbone.js, jQuery

BSD License

버클리의 캘리포니아 대학에서 배포하는 라이선스다. 공공의 몫으로 돌려주자는 의미가 강하다. 저작권 표시 조건 외에는 제약이 없다.

EX) Nginx

주의가 필요한 copyleft 라이센스

가장 강력함!

GPL이 여기 속함

Creative common 라이센스, 뒤에 붙는 레벨에 따라 다름!

지적 재산권을 명시하면서도 사용을 허용함

기능정의 후 개발 전 관련 라이센스 등을 다 확인

weak copyleft:

LGPL: DLL에 대해서 완화해준다.(약간 완화됨)

이클립스: lgpl에 속하는 오픈소스

소스코드 말고도 설치 정보등의 사용자 제품에대한 정보도 공개해야함

다이나믹 link에대해서 dll은 봐줌(PPT 참조)

대부분의 법적 절차는 '기간'이 치명적임

그 정도 기간이면 웬만한 스타트업은 못버티고 사라짐

사용 제한 라이선스

GNU affero : 옾소가 들어간 서버가 인터넷 서비스 -> 이건 재배포에 해당하니까 코드 공개

따라서 많은 기업들이 금지함

광고를 포함한 라이선스 : 요구사항 준수가 어려워 대부분 사용을 금지함

대표적인 오픈소스 라이선스

[GPL이 무서운 이유]

내가만든 실행파일에 GPL 라이선스 포함되면 전부 공개

static link,Dynamic linking: 동일한 메모리를 공유하면 전부 해당됨

몽고DB: Affero GPL(통신으로~ 소스코드 다운가능해야함)

LGPL: 분리되어 있는 경우, 봐줌(라이브러리,모듈 링크를 허용함)

정적링크는 소스코드와 앱의 오브젝트 코드도 공개해야함

Mozilla Public License(MPL)

개발자 편향적(GPL과 반대)

소스코드와 실행파일의 저작권을 분리함!

실행파일은 내꺼

MIT License

가장 느슨, 법적 고지문을 카피해서 포함하는 형태면 충분

bootstrap,angular.js

Berkeley Sw Distribution (BSD)

라이센스 및 저작권 표시하면 끝

0. Decorator Pattern이란?

 데코레이터 패턴은 객체의 추가적인 요건을 동적으로 추가하는 패턴이다. 중심이 되는 객체가 반환하는 값에 추가적으로 더해져서 결과값을 반환한다.

1. goal

 데코레이터 패턴은 특정 객체의 기능을 정적으로 확장(장식)하는 데 사용할 수 있다. 하나의 객체에 부가적인 기능을 덧붙여 많은 객체에게 다양한 부가기능을 쉽고 빠르게 적용하는 것이 목표이다. 다시 말해 객체가 동적으로 움직이고 있는 중에 특정 기능을 추가하고 뺄 수 있도록 하는 것이다.

2. Detail

 중심이 되는 객체를 놔두고 추가적인 사항을 첨가하는 방식이라 객체에 기능을 추가 또는 삭제할 때 중심이 되는 객체를 수정하지 않고 동적으로 추가 또는 삭제할 수 있다는 장점이 있다. 객체 지향의 원칙 중 확장에는 열려 있고 변경에는 닫혀 있어야 한다는 원칙인 OCP(Open-Close Principle)에 충실한 패턴이다. 데코레이터 패턴을 사용하게 되면 기존 객체는 변경하지 않고 자유로운 확장을 구현할 수 있으며 기존 객체 혹은 데코레이터가 수정되더라도 해당 클래스의 내용만 수정해주면 되기 때문에 변경에 대해서도 닫혀 있다. 또한 기본적인 데이터에 첨가하는 데이터가 일정하지 않고 다양할 때 데코레이터 패턴을 사용하면 효율적으로 사용할 수 있다. 반면에 데코레이터를 너무 많이 사용하게 되면 자잘한 객체가 많이 추가될 수 있고 오히려 코드가 복잡해질 수 있다는 단점이 있다.

[상속과의 차이점]

상속은 하위 클래스를 생성하는 방법으로 확장을 하며 데코레이터 패턴은 기본 객체에 추가하는 객체를 생성하는 방법으로 확장을 한다. 상속은 오버라이딩을 통해 기능을 전부 명시해 줘야 하지만 데코레이터 패턴은 기본 기능은 놔두고 추가되는 기능만 명시해 줄 수 있다는 차이가 있다.

[Composite 패턴과 차이점]

다양하고 일정하지 않은 여러 객체들을 하나의 객체로 묶는 것을 Composite 패턴이라고 한다. Composite 패턴은 목적이 생성되어 있는 객체들 간의 합성에 있고 데코레이터 패턴은 목적이 객체에 새로운 행동을 추가하는 데에 있다.

[Strategy 패턴과의 차이점]

Strategy 패턴은 유사한 행위를 캡슐화하는 인터페이스를 정의하여 객체들의 행위를 유연하게 확장하는 방법이다. Strategy 패턴은 객체의 내부를 변화시키며 데코레이터 패턴은 새로운 객체를 추가하여 객체를 변경시킨다는 점에서 차이가 있다.

3. UMLs

Component: 동적으로 추가할 객체들의 인터페이스 역할을 한다.

ConcreteComponent: 제공할 서비스의 베이스가 되는 컴포넌트를 정의한다.

Decorator: Component 객체에 대한 참조자를 관리(인스턴스 변수로 소유)하면서 Component에 정의된 인터페이스를 만족하도록 인터페이스를 정의한다.

ConcreteDecoreator: Component에 추가할 내용을 구체적으로 구현한다.

4.     Code Example

 위젯을 그리는 프로그램을 만든다고 가정하고 여러가지 위젯 중 캘린더 위젯을 만들고 위젯은 Scroller, Boarder로 구성할 수 있다.

[Component]

class WidgetComponent {

public:

    virtual void Draw() = 0;

};

[ConcreteComponent]

class CalendarWidget: public WidgetComponent {

public:

    virtual void Draw() {

        cout<<"Draw Window"<<endl;

    }

};

[Decorator]

class Decorator: public WidgetComponent {

public:

    Decorator(WidgetComponent* comp): component(comp){};

    virtual void Draw() {

        component->Draw();

    }

private:

    WidgetComponent* component;

};

[ConcreteDecorator]

class BorderDecorator: public Decorator {

public:

    BorderDecorator(WidgetComponent* comp)

    :Decorator(comp){}

    virtual void Draw() {

        Decorator::Draw();

        DrawBoarder();

    }

private:

    void DrawBoarder() {

        cout<<"Draw Boarder"<<endl;

    }

};

class ScrollDecorator: public Decorator {

public:

    ScrollDecorator(WidgetComponent* comp)

    :Decorator(comp){}

    virtual void Draw() {

        Decorator::Draw();

        DrawScroll();

    }

private:

    void DrawScroll() {

        cout<<"Draw Scroll"<<endl;

    }

};

[실행]

int main(int argc, const char * argv[]) {

    WidgetComponent* widget = new CalendarWidget();

    widget = new BorderDecorator(widget);

    widget = new ScrollDecorator(widget);

    widget->Draw();

    return 0;

}

[실행 결과]

Draw Window

Draw Boarder

Draw Scroll