안녕하세요 VI Engineering 팀 김윤제입니다.Gmarket Mobile Web Vip(View Item Page = 상품 상세)를 담당하고 있는 Backend Engineer 입니다. 예전부터 쓰고자 한 내용들이 많았는데 귀차니즘이 심해서 이렇게 한 번에 몰아서 쓰게 되네요.이번 편은 지난 편 설계란 고민의 연속이다 1편에 이어 2편입니다. https://dev.gmarket.com/1041편을 보신 후에 2편을 보시는 게 많은 이해가 될 것입니다. (안 보시면 이해가 안 갈 수도 있어요)자세한 이야기는 아래에서 상세히 다루도록 하겠습니다. 최선은 무엇인가!어떤 설계가 좋은 설계인지 모듈 설계를 AS-IS와 비교하며 하나씩 살펴보도록 하겠습니다.배송 모듈지마켓에는 배송 타입이 스마일 배송, 스마일 프레시, 당일 배송, 일반 통계 배송, 설치 예약이 있습니다.각 배송 정보를 구하는 로직은 다르지만 유일한 공통점은 배송비 로직이 같다는 것입니다.AS-IS의 방식 v1, v2와 신규 플랫폼 모듈에서 나아갈 방향 TO-BE 버전을 살펴보겠습니다.[AS-IS V1][C#]public Ship getShipping(String shippingType) { if (shippingType == ShippingType.SMILE) { } else if(shippingType == ShippingType.SMILE_FRESH) { } else if(shippingType == ShippingType.EXPRESS) { } else if(shippingType == ShippingType.GENERAL_STATISTICS) { } else if(shippingType == ShippingType.INSTALL) { }}if문의 향연이 펼쳐집니다.이런 상황에서 배송 타입이 지속적으로 더 추가된다고 해보겠습니다.제트기 배송, 위성 배송이라고 가정해보겠습니다.저 밑에 추가적으로 else if 가 추가 될 것입니다.또한 그 else if 문 안에 비즈니스 로직이 들어갈 것입니다.하지만 이게 전부가 아닙니다이런 문제도 있습니다.Rider의 한계?Rider는 인텔리제이와 동일한 회사 제트브레인에서 만든 개발 툴입니다.Rider의 한계를 경험하신 분이 계실지 궁금합니다.저런 식으로 하나의 클래스 안에서 if문의 향연을 펼칠 시 코드 라인이 매우 길어져Rider가 코드 컴파일을 못한다는 점입니다.(물론 이런 케이스를 발견한 분은 얼마 안 계실 겁니다..)오류 나도 못 잡습니다. 자동완성도 안됩니다. 색깔도 인식을 못합니다. 왼쪽[문제]-오른쪽[정상] 이게 끝이 아닙니다.최악은 하나의 파일 안에서 저렇게 무한 if문을 태운다면 코드 라인도 엄청나게 길어질 뿐만 아니라비슷한 기능에 대한 협업이라도 할 시에 Commit Merge 전쟁이 발발합니다.매 기능 수정 할 때마다 Merge시 30분은 소요됩니다.즉, 유지보수가 굉장히 어려워집니다. [AS-IS V2]현재 저는 이것을 개선했습니다. 아래에 블로그는 제가 개

서론안녕하세요, 저는 “쿠키런: 킹덤” 서버팀으로 일하고 있는 지민규입니다. 이 글은 9가지 프로그래밍 언어로 배우는 타입 이론에서 이어집니다. 이번 글을 읽기 전에 먼저 읽는 것을 추천드립니다.프로그래밍에 있어 추상화만큼이나 중요한 것은 다형성입니다. 다형성으로 인해 다양한 데이터 타입과 오브젝트의 재사용이 가능해지며 필요한 코드의 양을 획기적으로 줄입니다. 다형성을 이룩하는 방법에는 여러가지가 있으며 흔히 객체 지향 프로그래밍(Object-oriented Programming)의 특징으로 다형성이 꼽히곤 하지만 사실 절차적 프로그래밍(Procedural Programming) 언어이든 함수형 프로그래밍(Functional Programming) 언어이든 다형성을 어떠한 방식으로든 지원하는 경우가 많습니다. 이번 글에서는 언어 기능으로서의 다형성들을 나열하고 비교합니다오버로딩오버로딩(Overloading)은 같은 함수명에 다른 입출력 타입들을 가진 함수를 정의하여 하나의 함수 이름으로 묶을 수 있는 기능입니다. 프로그래밍에서는 이름이 추상화의 기초 요소라는 점을 생각해보면 오버로딩은 다형성 기법이라기보다 추상화 기법에 가깝다고도 생각할 수 있습니다. 두 숫자를 받아서 합을 출력하는 함수를 int 와 float 버전으로 구현해봅시다. C의 경우 오버로딩이 없기 때문에 서로 다른 함수 이름으로 구현해야 합니다.int addInt ( int a , int b ) { return a + b ; } float addFloat ( float a , float b ) { return a + b ; }C++에서는 오버로딩이 추가되었기 때문에 다음과 같이 처리가 가능합니다.int add ( int a , int b ) { return a + b ; } float add ( float a , float b ) { return a + b ; } int a = add ( 1 , 1 ) ; float b = add ( 1.0f , 1.0f ) ;하지만 오버로딩은 남용될 가능성이 있습니다. 함수 간의 동작 차이가 클 경우 함수가 어떤 일을 할지 예측하기 어려워지며 직관성을 떨어트리고 실수로 잘못된 함수를 부를 가능성이 있습니다.int getGrade ( int score ) { return a * 2 / 100 ; } int getGrade ( string gradeString ) { return toInt ( trim ( a ) ) ; } int b = getGrade ( getScore ( ) ) ;Go와 Rust는 오버로딩이 가져오는 이점보다 위험성이 더 높다고 판단하여 오버로딩을 지원하지 않습니다.오버로딩과 유사한 기능으로는 인수 기본 값 기능입니다. 인수 기본 값이란 함수를 호출할 때 인수의 값을 지정하지 않았을 경우, 대신 기본 값을 넣어주는 기능입니다. 인수 기본 값은 하나의 함수 블록을 사용하므로 오버로딩에 비해 상대적으로 안전하나, 여전히 잘못 사용하면 버그를 가져옵니다.int getGrade ( int score = 100 ) { return

서론안녕하세요, 저는 게임 "쿠키런: 킹덤"의 서버 파트에서 근무하고 있는 지민규라고 합니다.시작하기에 앞서 어째서 이 글을 쓰게 되었는지를 말씀드리고 싶은데요, 흔히 언어는 우리의 사고를 형성한다는 말이 있습니다. 언어가 가진 문장 구조과 발성, 그리고 단어들의 형태에 따라 세상에 대한 시각이 바뀐다고 합니다.저는 다양한 프로그래밍 언어를 배우면서 비슷한 경험을 했습니다. 첫 프로그래밍 언어로 C++를 배웠을 때 C++가 가진 한계점이 제 프로그래밍 방식의 한계점이 되었었고, Go를 배웠을 때 Go가 가진 언어의 구조가 프로그래밍하기에 충분하다고 생각했었습니다. 하지만 이후 더 많은 프로그래밍 언어들을 배우면서 생각이 더 넓어지고 프로그래밍 언어들 사이의 공통점이 보이기 시작했으며, 어떻게 하면 더욱 깨끗한 코드를 구현할 수 있을지 깨달아가게 되었습니다.다양한 프로그래밍 언어를 배워야하는 이유는 단순히 프로그래밍 언어들을 적재적소에 사용할 수 있어서가 아닙니다. 다양한 프로그래밍 언어를 배우면 아키텍처 디자인을 할 때 좀 더 넓은 시각을 가질 수 있게 되며, 어떠한 코드가 이상적인 코드인지 좀 더 알게 되고 좀 더 깊은 고민을 하며 구현할 수 있게 된다고 생각합니다.이 글은 주요 프로그래밍 언어들 중 하나를 깊게 이해하고 있는 분들을 대상으로 썼습니다. 그런 분들이 좀 더 다양한 시각을 가질 수 있도록 돕기위해 제가 프로그래밍 언어들을 배우고 사용하면서 알게된 것들을 조금이나마 나눠드리고자 합니다.언어 소개C1972년에 공개되어 로우 레벨 프로그래밍 언어초창기 프로그래밍 언어라서 기능이 많지 않아 단순함C++1985년에 공개되어 C를 바탕으로 OOP 기능들이 추가된 로우 레벨 언어C와 다르게 템플릿을 지원하고 C에 비해 굉장히 많은 기능들이 붙어 복잡도가 높음Java1995년에 공개되어 C++를 바탕으로 OOP 기능을 강화한 JVM 계열 언어C++와 다르게 하이 레벨 언어에 가까우며 메모리를 직접 관리하지 않고 가비지 컬렉터를 사용함C#2000년에 공개되고 Java를 벤치마킹하여 만들어진 하이 레벨 언어Java와 많은 유사점을 가지고 있음Scala2004년에 공개된 하이 레벨, 함수형, JVM 계열 언어Java가 쓰는 JVM으로 작동하지만 함수형 프로그래밍에서 밴치마킹한 기능들이 많으며 동시에 OOP 개발도 가능함Go2009년에 공개된 하이 레벨 언어현대 프로그래밍 언어가 지원하는 기능 대다수가 존재하지 않는 대신 C와 비견될정도로 단순하며, 성능 또한 로우 레벨 언어 수준까지는 아니지만 빠른 편Rust2010년에 공개된 메모리 안전성 문제를 해결하고 타입 시스템을 강화하기 위해 만들어진 로우 레벨 언어다른 로우 레벨 언어가 갖지 못한 강화된 타입 시스템과 메모리 안전성을 강화하는 버로우 체커가 특징임Kotlin2011년에 공개된 하이 레벨, JVM 계열 언어Scala를 벤치마킹하였기에 Scala의 대다수 기능들을 가지고 있으며, 문법도 유사하지만 좀 더 OOP 계열 언어에 가까움Typescript2012년에 공개된 하이 레벨, Jav

LINE SDK 개발팀의 Wei Wang입니다. 저희는 작년 LINE DEVELOPER DAY 2018에서 새로운 LINE SDK for iOS와 LINE SDK for Android를 오픈소스로 배포했습니다. 이 SDK는 LINE 로그인과 몇 가지 API를 앱에 통합하는 기능을 제공하는데요. 이를 통해 각 앱에 따라 매력적인 사용자 경험을 만들 수 있습니다. 저희는 배포를 마친 후 게임 개발자에 대한 지원도 필요하다는 점을 깨달았습니다. 게임은 App Store와 Google Play 전체 앱 중 50% 이상을 차지하며 압도적인 수익을 창출하고 있습니다. 그래서 저희는 또 하나의 중요한 플랫폼인 Unity용 LINE SDK를 개발하기로 결정했습니다. LINE SDK for Unity는 게임 개발자가 혁신적인 차기 게임 타이틀을 개발하면서 LINE SDK를 좀 더 쉽게 사용할 수 있도록 설계했습니다. 이번 글에서는 기존 SDK for Unity를 랩핑(wrapping)하기 위해 저희가 시도했던 방법을 소개하고, iOS와 Android에 LINE SDK를 통합하는 방법을 이야기하려 합니다. LINE SDK for iOS와 LINE SDK for Android처럼 LINE SDK for Unity도 오픈소스입니다. 코드는 GitHub에서 확인할 수 있고, Unity 게임에서 LINE SDK를 사용하는 방법은 셋업 가이드를 참조해 주시기 바랍니다. 개요 저희는 Unity SDK를 제공하면서 기존 iOS와 Android용 네이티브(native) SDK를 랩핑하여 사용자가 쓰기 편한 C# 인터페이스를 제공하기로 결정했습니다. SDK 전체를 다시 구현하지 않고 기존 기능을 랩핑하면 다음과 같은 이점이 있습니다. 유지관리 비용이 절감됩니다. 기존 네이티브 SDK 코드를 재사용하면 유지관리 비용을 줄일 수 있습니다. LINE SDK는 오픈소스로 공개되어 보급률이 높고 평판도 아주 좋습니다. 네이티브 SDK를 사용하면 프로젝트의 품질이 확보될 뿐만 아니라, 네이티브 SDK의 새로운 기능이나 수정사항이 Unity SDK에 동기화됩니다. 네이티브 기능을 활용할 수 있습니다. LINE SDK의 로그인 기능을 사용하려면 LINE 앱이 설치되지 않은 경우에 사용하는 웹 뷰(WebView) 로그인이나 다른 앱과의 데이터 전송 처리 등 시스템 플랫폼의 다양한 기능이 필요합니다. 네이티브 SDK를 사용하면 이러한 문제를 네이티브에서 적절하게 대처할 수 있습니다.익숙한 조작 방법을 제공합니다. 모델과 API 정의를 C# 레벨로 제공하기 때문에 Unity 사용자는 iOS 플랫폼과 Android 플랫폼 간 차이에 상관 없이 C# 규칙대로 LINE SDK를 사용할 수 있습니다. LINE SDK for Unity의 기본 구조는 다음과 같습니다. 구현 방법 LINE SDK for Unity 구현 방법에 대해 설명하겠습니다(전체 소스코드는 GitHub에 공개되어 있습니다). Unity용 네이티브 플러그인 Unity에서는 광범위한 네이티브 플러그인이 지원됩니다. 네이티브 LINE