Page History

...

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

.

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

다음 과정을 거칠것이다.

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

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

유행에 이끌려 함수형언어 방식을 전면 채택하지는 않을것이다. ( 스칼라를 채택한다고한들 그것은 좋은 경험이며 환영할수있지만., 리스크가 분명있다.)

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

스트리밍/람다 등과 연합할수 있는 방법이 등장하여 이것은 스칼라의 장점을 JAVA 8이후에서 어느정도 흡수 했기때문이다.

C++을 대체한다고 이것이 뒤떨어진 스펙 언어는 아니다. 템플릿/함수형언어방식/비동기처리 등은 JAVA8 이후에서나 쓸만해졌지만

C++에서는 JAVA가 생기기전부터 이미 그러한 컨셉이 있었으며 많은 언어에 영향을 주었으며 BoostIO를 통해 완성된 혜택들을 누릴수가 있다.

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

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

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

서비스 제공을 위해 SQL문 만을 호출하고 그것을 그대로 전달하는 개발 경험만 있는 개발자들과

이것을 어떻게 이해시키며 함께 협업을 할수 있는가란 것이다.

Versions Compared