환경:

NodeJS: 8.X

typescript: 2.8.X

jest: 22.X.X

ts-jest: 22.X.X



NodeJS + Typescript를 이용해서 backend를 구성할때, 특정 module을 여러 module에서 공유하고 싶을때가 있다.

이때, 공통 모듈을 package.json 을 가지는 하나의 독립모듈로 구성하고, 이를 dependency에 넣는 것도 좋지만(npm module을 사용하는 일반적인 방법), 그냥 단순하게 module directory를 공용으로 사용하고 싶은 경우도 많다.

예를 들면.


moduleA/

|- package.json

|- src/

|- common (*1)

|- ...


moduleB/

|- package.json

|- src/

|- common (*2)

|- ...


에서 (*1)과 (*2)에서 동일한 코드를 사용하고자 한다고 가정해 보자. 매번 똑같은 파일을 유지하는 것은 문제의 여지가 많으므로, 아래와 같은 구조를 만들고 싶을 것이다.



moduleA/

|- package.json

|- tsconfig.json

|- src/

|- commonA --> (*3) // Symbolic link to (*3)

|- ...


moduleB/

|- package.json

|- tsconfig.json

|- src/

|- commonA --> (*3) // Symbolic link to (*3)

|- ...


shared/

|- commonA/ (*3)

|- ...



그리고, moduleA와 moduleB의 tsconfig.json에는 symbolic link를 쫓아갈 수 있도록 


"compilerOptions": {

...

"preserveSymblinks:" true

...

}


로 설정한다.


자... 이제 모든 것이 문제없이 동작하는 것처럼 보인다.

그런데.. Jest를 수행시키면, 바로 문제가 발생한다.(제대로 Type을 Import하지 못한다!)

그리고, Symbolic link를 제대로 쫓아가지 못하는 것처럼 보인다.

Jest관련 각종 정보를 찾아보면, 일단은, 이 부분은 Known Issue이고, 지원하지 않기로 결정한 것으로 보인다.

(어딘가 본 기억이 있는데, 정확한 link는 잊어 먹었다는... 뭐 이후 또 바뀔수도 있으니....)

그래서, workaround를 고민해 보면, 아래와 같이 그냥 shared module에 ts-jest를 설치해 주면 문제가 해결되는 것 같다.



shared/

|- package.json // only 'ts-jest' exists at 'devDependencies'

|- commonA

|- ...


이렇게 해 두고, shared에서 npm install 을 통해서 ts-jestnode_modules 안쪽에 설치하고 나면, moduleA와 moduleB의 jest가 문제없이 동작하는 것을 볼 수 있다.

더 좋은 방법이 있는지는, 그리고 왜 이렇게 하면 동작하는지는 좀 더 살펴봐야할 부분이긴하나... 굳이 살펴봐야하나... 싶기도 하다... ^_^




Sub module은 내가 어디에 붙어 있는지 몰라야 한다.  즉 module "내부" => "외부" 로 dependency가 없어야 한다. 따라서, Inter-Module Communication은 상위 module을 통하는게 좋아 보인다.


                      +--------------------+
              +------->  Parent  Module    +---+
              |       +---------+----------+   |
              |                 |              |
Parent Module is observing    Notify         Notify
              |                 |              |
    +---------+-+     +---------v-+     +------v---------+
    | Module A  |     | Module B  |     | ...            |
    +-----------+     +-----------+     +----------------+


이 경우, 문제는 Lazy-loading module이다.

Lazy-loading module의 Concept상, Parent Module (이 경우, Root Module)에서 Notify를 할 수 없고 해서도 안된다 - Notify를 하려면, loading을 해야하는데... 그럼 더 이상 lazy loading이 아니다!

(만약 해야할 필요가 있다면, Lazy-loading으로 만들면 안된다. )


따라서, Lazy-loading module의 경우, 일반적인 sub-module의 제약사항에 더불어 추가적으로, 다음의 조건이 필요하지 않나... 싶다.(아직 좀더 많은 공부가 필요하다.)

- App. singleton provider 를 사용하면 안된다.

- module이 loading되었음을 가정한, "외부 => module" 로 communication이 없어야 한다.

<= 이거 상당히 강력한 제약사항이다!!!

그리고, 이건: "Inter-lazy-loading module간 communication이 없어야 한다." 를 의미하기도 한다.


기본적으로, 팀원 들의 팀장 에 대한 평가는 긍정적이기가 어렵다.

자신을 평가하고, 업무를 지시하는 사람에게는 당연히 불만이 생기게 되니... 어찌보면 인지상정이고 당연하다할 수 있다.

그렇다고, 팀원들이 팀장을 전부 안좋게 평가하는데, 이걸 자연스러운 현상이라고 무시할 것인가? 그것도 아닌 것 같다...

그래서 이 부분에 대해서, 개인적인 경험에 비추어 해석의 지표(?) 같은 것을 적어보고자 한다.


일단, 팀원들의 팀장에 대한 평가를 4가지로 분류한다.


적극적인 긍정(적긍)

소극적인 긍정(소긍)

소극적인 부정(소부)

적극적인 부정(적부)


'적극적'과 '소극적' 의 기준이 명확할수는 없으나, 의미는 통할 것이라고 생각한다.


개인적인 경험으로는...


"적부(< 40%) + 소부" <= 60%


까지는 정상적인 범위가 아닐까 한다. 즉 적부 가 40%정도까지, 적부 + 소부 가 60% 정도까지이다.

만약 이 수치가 60%~70% 정도라면, 좀 애매하다...


그리고,


"적부(> 50%) + 소부"  > 80%


라면, leader에게 뭔가 문제가 있다고 볼 수 있을 것 같다.


위의 수치들은 어떠한 근거도 없다. 그냥 내 경험 + 일반화 를 통해 만들어낸 수치일 뿐이다.


수치 자체보다는


"팀장에 대한 팀원의 평가는 좋기가 어렵다"는 것을 전제로, 그 정도가 지나치게 심할 경우는 확인이 필요하다.


정도로 요약하고 싶다.




+ Recent posts