Too many global variables


출처는 아래와 같다.

http://users.ece.cmu.edu/~koopman/pubs/koopman11_escsv_handouts.pdf

43개를 어떤 근거로 뽑은 것인지는 잘 모르겠지만, Engineering적인 측면에서 관심있는 것 중에서 하나를 선택해서 글을 쓰고자 한다.

8. Too many global variables

–> 전역변수를 어떻게 관리하느냐에 따라서 소프트웨어의 구조 형태가 많이 달라질 수 있다.

  • 모든 task(혹은 function)이 storage(혹은 pool)에 접근하여 모든 resource에 접근할 수 있는 아키텍처가 있을 수 있다. 가져다 쓰기는 쉽다. 다만 이 경우 전역변수에 의한 dataflow를 면밀히 관리해야 할 필요가 있다. safety시스템에 이런 아키텍처를 사용하는 것이 바람직한지에 대해서 개인적으로는 회의적이다. safety meachnism을 구현해야 하는 관점에서 봤을 때, 구현하기가 만만치 않을 것이기 때문이다. storage의 무결성을 확보해야 하는 것이 필요하고 unintended use/define을 보장해야 하는데,  이것을 구현하는 것이 만만하진 않을 것이다. 모니터링해야 하는 포인트가 너무 많고 이에 대한 오버헤드가 장난 아닐 것이다.
  • 개인적으로 선호하는 스타일인데, component라는 function의 set을 만들고 function에서 사용하는 data들은 component내에 정의하여 component에서만 사용할 수 있도록 한다. component와 component끼리의 data전달은 외부 interface를 통해서 전달할 수 있도록 한다. 이 경우 component내에 정의된 변수가 global변수이냐 아니냐에 대해 argue가 있을 수 있다고 생각하는데, global변수라고 하기에는 reduced scope으로 정의하고 restricted access가 가능하도록 지원하고 관리할 수 있기 때문에 위의 architecture보다는 훨씬 safe하다고 생각한다. monitoring overhead도 보다 적을 것이다.

소프트웨어의 architecture 설계에서 fault tolerant할 수 있도록(or safety mechanism할 수 있도록) 구현한다면, testing관점에서도 그 비용이 feasible한지를 판단할 수 있어야 한다.

아래의 link가 도움이 될 것이다.

http://betterembsw.blogspot.kr/2014/09/fail-safe-mechanisms-must-be-tested.html

 

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중