소프트웨어 복잡도 줄이기 (1)

 

 

 

예) 블록체인에서 블록을 받아서 처리하기 

- 명령적

0. 서버에 클라이언트들을 등록하고 초기화 한다. 서버는 현재 running 상태이다. 
1. 입,출력 채널을 초기화하고 시작시킨다. 현재 connected 상태이다. 
2. Recv 이벤트를 event 쓰레드풀의 쓰레드 하나를 얻어서 등록한다.
3. Recv 이벤트를 기다린다. 
4. Recv 이벤트가 오면 읽을 수 있을 만큼 읽어서 버퍼에 저장해 두고, 채널은 다시 이벤트를 기다린다. 
5. Recv 한 데이터가 너무 많으면 버퍼는 자동으로 증가 하고 적으면, 이미 읽은 버퍼의 앞쪽으로 이동해서 채워진다. 
6. 채워진 버퍼는 유저 Handler에 세션정보와 함께 보내진다.
7. 유저는 어떤 세션에서 데이터가 왔는지 확인하고  버퍼에서 데이터를 4바이트 읽어서, 헤더를 확인하고, 바디 부분을 마져 읽는다. 전체 바디가 만들어지지 않을 경우, 상태를 읽고있는 중이라고, 유지하고 중단한다. 
8. 완전한 데이터가 읽혀지면, 블록이라는 객체를 만들어서 User application으로 보낸다. 
9. 블록의 헤더를 확인한다.
10. 블록의 바디를 확인하기 시작한다.
11. 정상포매팅인지 확인한다.
12. 서명이 제대로 됬는지 확인한다.
13. 데이터의 버전 및 커밋 될 수 있는지 확인한다.
14. 데이터를 데이터베이스에 저장한다. 
15, Event Hub에 결과를 알린다.
16. 웹,앱,모니터링 시스템등에 알린다. 

- 선언적

Core application) 
서버 : 서버는 클라이언트로 부터 접근하겠다는 이벤트를 받아서, 세션이라는 이름의 객체로 만들어서 관리합니다. 
세션:  클라이언트를 세션이라고 부르며, 클라이언트의 접속 상태를 관리하고, 입출력 채널을 관리합니다.
채널:  특정 클라이언트를 지칭하는 파일디스크립터를 읽기,쓰기 이벤트로 등록하고, 이벤트를 처리합니다.
버퍼:  버퍼는 바이트 데이터를 관리하는데, 읽을 수 있는 양, 쓸 수 있는 양에 대한 정보도 제공합니다. 
유저 핸들러 :  버퍼를 받아서, 패킷을 어플리케이션 레벨로 재구성 하고, 블록객체를 만든후 User단으로 보냅니다.

User application) 
Application: 블록을 받아서 처리 합니다. 헤더를 분석해서, 구분합니다.
Verifier : 서명을 확인합니다.
Committer : 데이터의 버전 및 커밋 가능성을 데이터베이스를 통해서 검증하고 저장합니다.
Notifier : 해당 블록처리에 관한 결과를 이벤트 허브에 전송합니다. 
EventHub: 웹,앱,모니터링시스템등 여러 단말 으로 보내 줍니다.


대게 복잡도는 단순하게 할 수 없다고 합니다. (쉬운 알고리즘으로 대체 가능한 일부 제외하고) 비지니스 로직적으로는 애초에 상태가 무지 많아지기 때문에 대부분 복잡도는 대개 구성원이 모두 익숙해지거나, 더 직관적인 아키텍쳐로 바꿔야 하는 방법뿐인데요. 보통 선언적으로 프로그래밍을 하면 유지/관리에 좋다고 합니다. 위에서 언급한 명령적/선언적 예는 좀 오버를 한거이구요. 사실 "for문으로 돌리면서 이렇게, 저렇게 한다" 를 map은 전체요소를 일률적으로 변경시킨다. fillter는 일부요소를 제거한다. reduce는 개개의 요소를 하나로 묶는다. 등등의 한단계 위의 추상화된 요소들로 선언하죠. 다음 글에는 위의 예제(상태가 굉장히 복잡한데, 매우 단순화 시켜 놓음) 중 일부를 하나는 Observer or Listener or Handler 식으로 코딩하고, 하나는 FRP (함수형 기반의 반응형 파라다임) 식으로 코딩해서 비교해보도록 하겠습니다.