오래된 고전 게임서비스 로직을 분석하기 시작하였다. 오랫동안 상위 랭크되어 운영된 값어치 있는 소스이며

지속적인 유지보수 과정속에서 OOP의 철학또한 담겨있다. 한동안 OOP와 거리를 두고 있어서

다시 객체지향적인 설계의 감각을 찾기위함도 있지만 관련 도메인지식으로 다시 돈을벌어야하는 상황이 왔기때문이다.

. 

VS의 도움을 받아 불필요한것을 모두 제거하여, 필요 분석대상을 UML로 먼저 압축을 하였으며

다음 과정을 거칠것이다.

Persitence와 사용자와 통신 프로토콜은 다음 기술로 대체할것이며 충분히 강력하고 보편화된 기술을 선택하였다.


C++→JAVA로 리팩토링을 복잡도및 추상화정도를 조금더 직관적이게 하기위해  최근 언어 스펙을 부분적으로 사용할 예정이며

유행에 이끌려 함수형언어 방식을 전면 채택하지는 않을것이다. 

스칼라선택이 한가지 예이다.  -좋은 경험이며 환영할수있지만. 리스크가 분명있다. 

OOP는 아직도 대중성이 있고 충분히 강력하며(스칼라가 OOP가 아니다란 의미는 아님)

스트리밍/람다 등과 연합할수 있는 방법이 등장하였고 이것은 스칼라의 장점을 JAVA 8이후에서 느리지만 안정적으로 흡수 했기때문이다.


JAVA를 선택한 이유는 Spring/Play Framework/Netty/JPA등을 활용하여 웹서비스영역에서 쉽게사용가능한

표준화되고 범용적인 혜택의 선택지가 다양하기 때문이다.

여기서 어려운점은 언어와 별개로 상속레벨이 3이상인것을 자유자재로  추상화하고 다뤄야하는 OOP 설계능력이 필요한데

서비스 제공을 위해 SQL문 만을 호출하고 그것을 그대로 전달하는 개발 경험만 있는 개발자들과 이것을 어떻게 이해시키며 함께 협업을 할수 있는가란  것이다.

이것을 해결하기위해 아주 특수하게 사용되는 추상적인 서비스 로직을 표준적인 방법으로 심플하게 엔진화할수 있고 문서로만 설명될수 있는 고오급 개발이 필요하다. 

성공할 자신은 없지만... 그것이 왜 필요하고 어떻게 해야할지 구상이 되었기때문에 시작을 해보려고 한다. 


과거 이러한 아키텍으로 작동되는 서비스를 설계하고 작동을 시키고 현재도 운영중에 있는것으로 알고 있지만

표준+문서+심플함과는 거리가 먼 개발코드를 작성을 하였다.


이활동은 아래 링크로 이어집니다.

Spring Cloud MicroService




  • No labels