'Essay'에 해당되는 글 86건

  1. 2017.03.08 SW refactoring시 가장 주의해야 할 점.
  2. 2016.06.03 Builder pattern의 유용한 용법 - Constructor overroding 줄이기.
  3. 2016.01.17 관리자는 "관리하는 것" 만큼이나 "관리하고 있다고 인식하게 하는 것" 도 중요하다.
  4. 2015.07.16 Relation among 'Performance/Productivity', 'Attitude' and 'Talent' of engineers
  5. 2015.06.24 새로운 업무를 할당 받을때 혹은 할당해 줄때 업무 목적/내용 공유/확인 하는 방법.
  6. 2015.04.22 [Essay] 회사의 실적이 나빠지면 직원들이 더 바빠지는 현상.
  7. 2014.12.15 인사평가를 대비한, 인사고과 분배를 위해 필요한 선조치.
  8. 2014.12.11 인사평가의 한계 - 조직 성과의 측정의 한계에 따른, 개인성과 측정의 한계
  9. 2014.10.16 같은 말이라도 '아' 다르고 '어' 다르다. 다른 사람을 blame하는 말을 할때 유의할 점.
  10. 2014.08.11 MVC Pattern 시험...

SW refactoring시 가장 주의해야 할 점.

Essay/Software 2017.03.08 21:58

Code refactoring의 어려운 점은 이미 잘 알려진 바와 같다.
하지만, 그 문제의 복잡성 측면에서 보면, 작은 규모의 refactoring - file 혹은 class 단위 변경 - 은, 대규모 - 특히 코드의 구조 혹은 설계를 바꾸는 정도 - refactoring 에 비할 바가 못된다.

legacy 코드의 구조가 한계에 부딫혀, 재설계->재구현 을 고민할 정도의 상황을 가정해 보자.
이때, 가장 많이 고민하는 것은 아마도 "SW 재작성" vs "대규모 refactoring"일 것이다.
그리고, 어떠한 이유에서든, "refactoring"을 하기로 결정한 상황이라면 어떨까?
(실제, SW를 처음부터 새로 작성하는 것에 대한 Risk는 많이 언급되어 지고 있다.)

필자의 경험에 따르면, 이때 가장 중요한 것은
- refactoring의 단위를 적당히 작은 단계(step)로 분류하고,
- 각 step에서는 그 목적에 해당하는 refactoring만 수행
하는 것이다.

정말로 간단하고, 쉬워보이지 않는가?
하지만, 이게 정말 쉽지 않다.

Refactoring을 주제로 하는 많은 이야기들은, '좋은 구조', 'refactoring 시점' 등등 기술적인 측면을 다루고 있다.
그런데, 막상 필자가 실제로 heavy하게 사용되고 있는 SW를 refactoring하는 경험을 해보니, 정작 문제는 앞서 언급했던 두 가지에 있었다.

보통, 대규모 refactoring은 아래의 단계를 거쳐서 진행될 것이다.
- 현재 SW의 문제점 논의
- Refactoring의 범위 결정
- 새로운 SW구조에 대한 설계 철학 공유
- SW의 최종 형태 공유.
- 각 주제별로 refactring 시작.

하지만, 이런식의 진행은 'legacy SW의 상태'와 '최종 SW의 상태' 사이에 큰 차이가 있기 때문에, 그 끝이 좋지 못한 경우가 많다.
많은 양의 변화를 한꺼번에 진행하면, refactoring과정에서 발생한 오류를 찾아내기 너무 힘들어서, 결국 refactoring 코드를 버리거나, 아니면 SW 재작성에 버금가는(혹은 그 이상의) 노력이 들어가게 된다.
이론적으로는 이런 내용들을 대부분의 개발자들이 잘 알고 있지만, 실제로는 어떨까?

예를 들어, class간의 관계를 재 설정하는 refactoring진행 중, code의 context와 맞지 않는 변수 이름을 발견했다면? 혹은 code style이 잘못된 곳을 발견했다면?
대부분의 경우, 아주 작은 수정이므로, 겸사겸사 같이 수정하면서 진행할 것이다.
이것은, 마치 "거실 바닥 정리"라는 과정 중 "벽에 작은 얼룩을 발견"한 경우, 그냥 지나치지 못하고, 잠깐 시간내어서 얼룩을 지우는 것과 같다.
혹은, SW의 "Feature creep"과도 일맥상통해 보인다.
이런 식의 작은 side-refactoring들이 모여서, 한 step의 복잡성을 증가시키고, 결국 해당 step을 포기하고 처음부터 다시 진행하도록 만든다.

따라서, refactroing을 계획할 때는 앞서 언급한 것처럼, 그 단계를 잘게 나누어야 한다.
물론, 각 단계별로, "새로운 구조" + "legacy 구조" 의 형태를 지켜 내기 위한 overhead가 필요하므로, 너무 잘게 분리할 경우, 이 overhead 비용이 너무 커질 수 있으므로 주의해야 한다.


신고
Trackback 0 : Comment 0

Builder pattern의 유용한 용법 - Constructor overroding 줄이기.

Essay/Software 2016.06.03 21:48

외부에 service를 제공하는 모듈 (예를 들면, library)일 경우, 잘못된 사용을 원천적으로 막는 것은 상당히 어려우면서도 중요하다.(모듈의 사용성과도 밀접한 관계가 있다.)

그런데, module의 instance가 생성되고 나서, 초기화 작업 이후에는 다시 setting될 필요가 없는 값들의 경우, 되도록이면, final (혹은 const)로 선언하는 것이, 코드의 이해도를 높이기도 좋고, 잘못된 사용을 막기도 좋다.


이때, default argument 값을 사용할 수 있는 언어의 경우(C++, Python 등)는 별 문제 없는데, 그렇지 않는 경우(ex, Java)는 사용성을 위해서 module constructor를 overloading해야 한다.(대부분의 경우, default 변수가 사용될 경우, 굳이 매번 이 값들을 argument로 전달해야 하는 것은 상당히 번거롭다.)


예를 들면,  'name', 'numArms'와 'numLegs' 세개의 final 변수를 가지는 'Person' module의 경우


class Person {
    private final String mName;
    private final int mNumArms;
    private final int mNumLegs;

    public Person(String name, int numArms, int numLegs) {
        mName = name;
        mNumArms = numArms;
        mNumLegs = numLegs;
    }
    public Person(String name, int numArms) {
        this(name, numArms, 2);
    }
    public Person(String name) {
        this(name, 2, 2); // 2를 default value로 사용. 대부분의 사람은 팔 다리가 2개... 
    }
}

와 같이 작성된다.

그나마 argument가 3개인 경우가 저정도고, argument가 많아지면, 사용성을 높이기 위해서 overloading되는 생성자도 많아진다.

이 문제를 builder pattern으로 해결할 수 있다.

예를 들면.

class PersonBuilder <T extends PersonBuilder > { // Generic type T 를 사용하는 이유는, 이 Builder를 상속받는 builder를 위함이다.
    private final String mName;  // name은 default가 없으므로 생성시 외부에서 반드시 argument로 받아야 한다.
    private int mNumArms = 2;  // 대부분의 사람은 팔, 다리가 2개...
    private int mNumLegs = 2;

    public PersonBuilder(String name) {
        mName = name;
    }
    public T
    setNumArms(int numArms) {
        mNumArms = numArms;
        return (T)this;
    }
    public T
    setNumLegs(int numLegs) {
        mNumLegs = numLegs;
        return (T)this;
    }

    public Person
    create() {
        return new Person(mName, mNumArms, mNumLegs);
    }
}


그렇지만, 역시 해당 class를 상속받는 경우, 긴 argument를 가진 생성자를 상속해야 하는 불편함은 여전하지만, 이 문제 역시, builder를 상속받는 방법으로 해결할 수 있다.


class OldPerson extends Person { ...}

class OldPersonBuilder<T extends OldPersonBuilder> extends PersonBuilder<T> {
    public OldPersonBuilder
    create() { ...}
}


Generic을 사용했기 때문에, 아래와 같은 용법이 가능하다.

OldPersonBuilder<OldPersonBuilder> bldr = new OldPersonBuilder<OldPersonBuilder>("MyName");
bldr.setNumArms(2).setNumLegs(2);

대략 정리해 보면, 이와 같은 pattern을 사용할때는


Module에서 final. Default값 존재 X => Builder에서도 final

Module에서 final. Default값 존재 O => Builder에서 NOT final.


이정도일려나?


신고
Trackback 0 : Comment 0

관리자는 "관리하는 것" 만큼이나 "관리하고 있다고 인식하게 하는 것" 도 중요하다.

Essay/Work 2016.01.17 20:48

제목 그대로다.

"멤버가 하고 있는 일, 노력 그리고 성과 등을 정확하게 파악하는 일"은 관리자가 해야할 일 중요한 일 중 하나이다.

왜냐하면, 멤버의 성과를 결국 평가해야하기 때문이다.

그렇지만, 그것만큼 중요한 건 "멤버들이, 내가 관리받고 있고, 관리자가, 나의 일, 성과 그리고 노력을 정확하게 파악하고 있다."라고 인식하게 하는 것이다.

사실 실제로 관리자가 "얼마나 '정확히' 파악하고 있나?"와는 별개로, 멤버들이 "자신들이 관리받고 있다."라고 느끼고 있다면, 나태해 지지 않고, 또 자신의 성과를 터무니없이 과장하는 등의 문제도 줄어들게 된다.


물론 관리자의 가장 중요한 역할은 "팀원들이 자신의 업무/생활에 만족하면서, 팀 전체가 최상의 성과를 낼 수 있도록 이끌어 가는 것."이라는데는 변함이 없다.

신고
Trackback 0 : Comment 0

Relation among 'Performance/Productivity', 'Attitude' and 'Talent' of engineers

Essay/General 2015.07.16 21:54

Let's assume that a engineer is working at same domain for a long time.

Then, based on my experience, relation among those three is something like this.


<Performance/Productivity> = <Talent> * <Time> ^ <Attitude>


What this means?


At early stage, Talent dominates Performance.

But, after all, Attitude dominates Performance.


Then, what is attitude means for engineer?
In my opinion, good attitude of engineer, is
    - studying continuously.
    - trying to establish strong knowledge base for domain.
    - trying to understand as many / deep as possible regarding his/her task and domain.
    .. .and so on.


Let's see below graph.



Y-axis : Performance / Productivity
X-axis : Time

Red line : Talent value = 1, Attitude value = 4
Green line : Talent value = 10, Attitude value = 2



At this graph, there is special period (0 < Time < 1).

At this period, Attitude hinders Performance.

My interpretation is, engineer who has great attitude, always tries to understand nature and fundamental knowledge of tasks.

So, during this period, in terms of so-called output, he/she may be worse than other engineers.

But, based on this strong knowledge and understanding, he/she accelerates productivity (Time > 1)

And finally, his/her performance overcome talent.


This is my opinion based one only my experience.

Reader may or may not agree with it.
But, I strongly believe this. :)




신고
Trackback 0 : Comment 0

새로운 업무를 할당 받을때 혹은 할당해 줄때 업무 목적/내용 공유/확인 하는 방법.

Essay/Software 2015.06.24 21:31

* 가장 중요한 것은, 내가 맡은 업무가 무슨 업무인지 이해하는 것이다. 따라서 업무를 할당할때, 그리고 할당해 줄때 모두 내가/타인이 주어진 Project와 그에 따른 할일을 제대로 이해하고 있는지 확인하는게 중요하다.


* 그렇다면 위의 내용을 확인하는 가장 좋은 방법은 무엇인가?

Project에 대한 내용을 말로 설명하고 말로 확인하는거? 당연히 그렇게 해야 한다. 그렇지만 단순히 여기에 그칠 경우 한계가 명확하고, mis-communication도 종종 생긴다.

따라서 좀더 확실한 방법은, "난/넌 어떻게 내/니 일이 완료되었다는 것을 확인할래?"라는 질문을 던지는 것이다.

여기서 '어떻게'를 좀더 기술적인 용어로 변환해 보면, 'Test/Verification'이 될 수 있다.

즉, '어떤 Test/Verification을 통과하면, 이 일을 완료되었다고 확신할 수 있나?'가 된다.
(Project Management 쪽에서는 이것을 'Definition of done' 이라고 표현하고 있다.)


* 위의 과정의 핵심은 '어떤 Test/Verification'이다. 즉 Test design이다.


정리하면, 해당 업무를 '완료'했다고 말할 수 있는 'Test'를 design할 수 있다면, 그 업무를 완전히 이해했다고 볼 수 있다.


따라서, 업무를 받을때/할때 모두, 다음과 같은 질문/확인 을 통해서 업무에 대한 이해도를 확인할 필요가 있다.

업무를 할당 받았을때: "제가 <이런이런>시험을 했을때 문제가 없으면 되는거죠?"

업무를 할당할때:

(저급)1. <이런이런>시험을 했을때 문제가 없으면 됩니다.

- 문제의 본질을 이해하지 못하고, 단순히 시험에 통과하기위한 업무만을 진행할 가능성이 있음.

(고급)2. 업무는 <이러이러>합니다. 자, 당신은 어떻게 이 업무가 완료되었다는 것을 확인할 예정입니까?

- 제대로 된 답을 한다면, 이 사람은 업무를 완전히 이해하고 있다고 볼 수 있다.


신고
Trackback 0 : Comment 0

[Essay] 회사의 실적이 나빠지면 직원들이 더 바빠지는 현상.

Essay/General 2015.04.22 21:53

직장생활을 하다보면, 제목과 같은 현상을 경험할 수 있다.

이게 '일반적'이라고 말하기에는 근거가 부족하지만, 개인적으로는 위와 같은 경험을 많이 해 본거 같다.


왜 그럴까?

가장 쉽게 생각할 수 있는 것은, 회사의 고정비를 줄이기 위해서 인력을 감축시키기 때문일 것이다.

업무량은 변하지 않았는데, 일하는 사람이 줄어드니, 남은 직원들은 더 바빠진다.


그런데, 개인적인 의견으로, 이것보다 더 중요한 요인은 "살아남기 위해서 일을 벌리기 때문" 이라고 생각한다.

회사의 고위층은, 실적이 나빠지면 살아남기 위해서 실적을 만들어야 한다.

그리고, 보통 '실적'은 '기존에 해 오던 일을 잘 하는 것' 보다는 '새로운 일을 해 내는 것'이 더 높은 평가를 받기 마련이다.

그렇다보니, 소위 '윗선'에서 자꾸 새로운 일을 만들어 내게 된다.


생각하기에 따라서는, 긍정적인 시각으로 이런 현상을 바라볼 수 있겠지만, 난, 부정적인 측면이 더 많다고 생각한다.

회사의 실적이 안 좋아지고, 고정비를 줄여야 하는 상황이라면, 일을 만들어 내는 것 보다는, 기존 일들에 대해서 우선순위를 정하고 "선택과 집중"을 통해서 어디에 회사의 역량을 집중할 것인가를 판단하는게 더 중요한 일이 아니겠는가?


물론, '기존에 해 오던 일을 잘 하는 것' 보다는 '새로운 일을 해 내는 것'에 대해서 압도적으로 높은 평가를 하는 것이 이런 현상의 근본 원인이긴 하겠지만, 그것과 별개로, 위기상황이라면, 좀더 합리적인 선택 - 선택과 집중 - 을 해야하지 않을까?

그렇지 못할 경우, 아마도 회사는 더 빠른 속도로 몰락의 길을 걷게 될 것이라고 본다.



신고
Trackback 0 : Comment 0

인사평가를 대비한, 인사고과 분배를 위해 필요한 선조치.

Essay/Software 2014.12.15 14:27

익히 알려진 바와 같이, 인사평가가 100% 공정 - 공정이라는 단어의 정의를 어떻게 하느냐에 따라 달라질 수도 있겠지만 - 할 수는 없다.

일례로, 기왕이면 진급 대상자에게 상위고과를 주는 것이 어찌보면 '인지상정'이라고 할 수도 있을 것이다.

이런 것이 '좋다' 혹은 '바르다'라고 이야기 하는 것이 아니다. 평가는 100% 공정한 것이 좋다. 그렇지만, '공정'이라는 것이 그 속성상 100% 객과적일 수가 없기 때문에, 주관적인 판단이 반드시 개입된다는 것을 인정해야 한다.

그리고, 이런 '주관적인 판단'에는 주변의 환경적인 요소가 포함되기 마련이다.

예를 들면, "같은 성과라면, 기왕이면 진급이 절실한 사람에게 손을 들어 준다던가."라는 것들 말이다.

비슷한 이유로, 상위고과가 다른 이들보다 절실한 사람이 있기 마련이다.

그렇다고 해서, 인사평가 시즌에 무턱대로, 이런 사람에게 아무런 이유없이 상위고과를 줄 수는 없는 일이다.

이런 경우, 어떻게 해야 합리적인 방법으로 무리없이 이런 문제를 처리할 수 있을까?


내가 보기에, 인사평가는 "일을 얼마나 잘 하였느냐?"보다는, "어떤 일을 하였느냐?"가 더 많은 부분을 차지하는것 같다.

SW의 분야의 경우 예를 들어보면, 기존일을 '유지/보수'하는 일은 정말 압도적인 '실력/성과'를 보이지 않고서는 최상위 평가를 받기는 거의 볼가능하다.

그렇지만, 회사가 주요하게 추진하는 새로운 제품을 개발한다던가, 새로운 기능을 추가 구현하는 일은 일단 무사히 업무를 마치기만 해도 상위 평가를 받을 가능성이 높다.

이 두가지 업무 중 어느 쪽이 더 힘들고, 덜 힘든지는 경우에 따라 다를 것이지만, 일을 마쳤을 때 받을 수 있는 평가의 차이는 상당하다.


다시, 앞의 이야기로 돌아가 보자.

어떤 사람에게 '기왕이면' 상위고과를 주고 싶은 경우는 위에서 언급한 내용을 응용하는 것이 좋다.

그 사람에게, '상위고과를 받을 수 있는 일'을 할 수 있는 기회를 주는 것이다.

'좋은'일이 생겼을 때, 소위 '챙겨줘야'할 사람에게, 먼저 "이 일을 할 것인지?"에 대한 의사를 물어보는 것이다. 그리고, 이 일을 잘 해내었을때 좋은 평가를 받을 수 있다는 것도 같이 언급하는 것이 좋다.

이렇게 먼저 기회를 주고, 무사히 일을 잘 해내었을 경우 큰 물의를 일으키지 않고 필요한 사람에게 '상위고과'를 줄 수 있게 된다.

한편, 이런 기회에도 불구하고, 일처리가 미숙했다면, 그 사람은 거기까지가 한계인 것으로 볼 수 있다.


지금까지 어찌보면 굉장히 '부당'하다고 생각할 수도 있는 이야기를 했다.

읽는 사람에 따라서 상당히 불편하게 받아들일 수도 있을 것이다.

그렇지만, 사람이 사는 곳이라면 이런 문제가 반드시 발생하고, 실제 많은 조직에서 이런 문제가 심심치 않게 보인다는 것에 이견을 가진 사람은 없으리라 생각한다.

따라서, 이런 일을 피할 수 없다면, 최대한 합리적인 방법으로 처리할 필요가 있고, 내 개인적인 생각으로는 위과 같은 방법이 무난하다고 여겨진다.


여기서 다시 한번 강조하고 싶은 내용은, 상당히 많은 경우 "그 사람이 얼마나 일을 잘 했느냐?"가 아니라, "그 사람이 어떤 일을 했느냐?"가 평가에 더 많은 비중을 차지한다는 것이다.


신고
Trackback 0 : Comment 0

인사평가의 한계 - 조직 성과의 측정의 한계에 따른, 개인성과 측정의 한계

Essay/Software 2014.12.11 10:29

Software분야에서 소위 '성과 평가'에 대한 문제는 아주 오래되고, 또 진부한 문제다.

여러가지 한계를 이야기 하고 있고, 그럼에도 불구하고, "평가를 하지 않는 것 보다는 하는게 낫다."라는 이론(?)을 근거로, 여전히 다양한 형태의 '평가'가 행하여 진다.

이 글은 '대안'을 제시 - 가장 어려운 부분 - 하는 것이 아니고, 기존 '평가' 방식이 가지는 여러가지 문제 중 하나를 언급하기 위해 작성된 것이다.


Software분야의 여러가지 연구 중 아래와 같은 것이 있었던 것으로 기억한다. (출처는 기억이 잘...)

"Software engineer에 개인의 기술적인 역량은, '어떤 group에 속해 있느냐'에 따라 상당히 많이 좌우된다."

즉, 좋은 group에서 좋은 경험을 쌓은 engineer가 기술적으로 뛰어난 engineer가 될 확률이 높다는 뜻이다.

그리고 또 재미있는 연구 중 하나는 (이것도 출처가 잘...)

"Software engineer 개인의 성과 차이는 100배까지도 발생하지만, 조직의 성과 차이는 10배 정도까지 밖에 차이가 나지 않는다."

관점에 따라서, 80:20 법칙을 생각나게 하기도 한다.

개인의 역량차는 심하게 나지만, 조직의 역량차는 그렇게까지 크지 않다는 뜻이다.

아마, [역량이 '1'인 엔지니어들의 group] vs. [역량이 '100'인 엔지니어들의 group] 과 같은 극단적인 조건에서가 아니라, 현실세계에 존재하는 일반적인 group을 대상으로 한 조사였을 것이라 생각된다. 

그리고 또, 일반적인 '회사'에서 똑같은 일을 두 곳 이상에서 하는 경우는 거의 없다.


내가 하고 싶은 말은, 

"조직의 역량 차는 각 개인의 역량차에 비해 크지도 않고, 또 같은 일을 하는 조직이 없기 때문에 SW조직의 역량을 비교 평가하는 것은 상당히 어려운 일이다."

라는 것이다.

특히, 같은 일을 하는 조직이 없다는 뜻은, 그 조직의 역량과 무관하게, 해당 분야의 history / 경험/ domain knowledge 등에 따라 진입장벽이 만들어 진다는 말이다. 그리고, 이 진입장벽으로 인해, 조직간 역량 평가는 결국 무의미해 진다."

즉, 개인의 성과 평가보다도 SW 조직(개발 조직)의 평가가 더 어렵다.


SW조직의 평가가 어렵다는 것을 받아 들인다면, 독립된 두 조직이 있을때 어느 조직이 더 나은 조직인지 알지 못한다는 뜻이다.

A, B 두 조직 중 실제 A 조직이 더 우수하지만, 조직 평가의 어려움 때문에 A, B 조직의 평가가 같게 나온 상황을 가정하자.

이 상황에서, 우수한 조직에서는 우수한 engineer가 배출될 확률이 높고(앞서 언급했다.) A 조직과 B조직의 역량차는 계속해서 커진다.

그렇지만, 여전히 조직간 평가의 문제점/어려움 때문에 이 부분이 보여질 가능성은 극히 낮다.


이런 상황에서, 일반적인 '회사'에서는 '상대평가'를 수행한다.

각 조직에서 상위 성과자와 하위 성과자를 구분하는 것이다.

개인의 역량평가를 정확히 실시하는 것도 사실 거의 불가능 하지만, 개인간 정확한 성과 평가가 가능하다는 것을 가정하더라도, 이미 조직의 평가에서 정확성을 잃어 버렸으므로, 개인간 평가의 정확성은 상당부분 희석될 수 밖에 없다.

뛰어난 조직의 하위 성과자가, 다른 조직의 상위 성과자 보다 더 나은 성과를 보였을 가능성도 무시하기 힘들다.


별다른 통일성이 없는 글이였는데... 정리하면...

SW분야에서 개인의 역량 평가에 대한 연구도 중요하지만, 조직의 역량 평가에 대한 연구도 동등 혹은 그 이상으로 중요하다.




신고
Trackback 0 : Comment 0

같은 말이라도 '아' 다르고 '어' 다르다. 다른 사람을 blame하는 말을 할때 유의할 점.

Essay/General 2014.10.16 10:29

"다른 사람을 blame하는 말을 할때, 주어가 '나'가 되고, 나를 blame하는 문장으로 바꾸어 구성하자."

아래와 같은 예를 보면 명확하게 이해될 것 같다.


* "너는 왜 아빠 말은 안듣니?"

=> "OO야, 아빠가 OO가 이해하기 어렵게 말했니?"


* "OO부장님께 말씀드렸습니다만, 받아들여지지 않았습니다."

=> "제가, OO부장님께 드린 설명이 부족했나 봅니다."


신고
Trackback 0 : Comment 0

MVC Pattern 시험...

Essay/Software 2014.08.11 14:54

MVC Pattern에 대한 다양한 종류의 해석/적용이 있긴 한데... 일단, 내가 생각하기에, 일반적인 SW에서 좋다고 생각하는 구조는 아래와 같다 (Web SW나 기타 여러 case가 존재하고, 각각에 맞는 다양한 해석이 존재할 수 있으니, 정답은 없다.) 물론, 아직 나 자신이 MVC Pattern에 대해 미숙하기 때문에 확신할 수는 없으나...


+-----------+ Query(write/read) +------------+

| | <-------------------------- | |

| Model | | Control |

| | ---------------------------> | |

+-----------+ Response/Data for query +------------+

| | ^

| | |

| Feedback to user(ex. select view) | | User interaction event

| v |

| +------------+

| | |

+--------------------------------------> | View |

Read data / (Observe changes - optional) | |

+------------+


Pros : MVC간 연결이 최소화 되어 있어 각각에 대한 독립성이 잘 보장되어 있다.

Model부분이 최소화 되므로, Data 부분에 대한 안정성을 높이기 유리하다.

Cons : Control부분의 역할이 Model, View에 비해 압도적으로 복잡할 가능성이 높다.

따라서, 복잡한 UX를 가질 경우, Control 부분의 통제가 상당히 어려워질 수 있다.

일단 가장 좋은 점은, Model에 대한 update가 Control로 제한되어 있기 때문에

(View -> Model로 write path가 없다.), Data에 대한 관리가 일원화 되어 있다.

또한, Control이 Model의 data를 update하므로, View는 Model의 Data가 바뀌는지 아닌지 굳이 Observing할 필요가 없다.

(필요에 따라 Observing하는 것도 괜찮다.)



. .


신고
Trackback 0 : Comment 0

티스토리 툴바