주니어 개발자의 첫 오픈소스 회고

Picbel·2022년 7월 17일
0

회고

목록 보기
1/7
post-thumbnail

https://github.com/sirloin-dev/mtrace-api-client

회사 업무로 공공 오픈 API를 사용할 일이 있었다.

오픈 API임에도 오픈소스로 Api Client가 만들어져있지 않아 내가 만들기로 했다.
오픈소스로 만든다며 좀 헤매어서 생각보다 일정이 더 걸렸는데 감안 해준 회사에 감사하다.
이번 포스팅은 오픈 소스 API를 만들며 느낀 점을 회고해보는 시간이다.
더불어 처음에 코틀린으로 만들다 자바8로 포팅하였는데 정말 불편한 점이 많았다. 이 부분에 대한 내용도 들어갈 것이다.

Open Source

오픈소스란 원래 오픈소스 소프트웨어(Open Source Software, OSS)를 뜻하는 용어입니다. 오픈소스 소프트웨어는 공개적으로 액세스 할 수 있게 설계되어 누구나 자유롭게 확인, 수정, 배포할 수 있는 코드입니다.
[출처 : 레드핫 whit-is-open-source]

말 그대로 오픈소스는 누구나 공개적으로 사용할 수 있는 소프트웨어이다.
이러한 특성 덕분에 코드 퀄리티에 더 신경을 써야 했다. 그리고 코드 외에 신경 써야 할 것도 많았다.
먼저 해당 프로젝트를 그레이들로 추가해서 사용할 경우가 대부분이라 판단되어 외부 라이브러리 사용을 하지 않았다.
라이브러리 중복 import로 인한 오류를 프로젝트 사용자한테서 원천적으로 방지하고 싶었기 때문이다.
그래서 자바의 기본 기능을 최대한 활용하였다. 당연히 http클라이언트 외부 라이브러리, xml 파싱라이브러리를 사용할 수 없었다.
(자바의 java.net의 HttpClient는 자바 11에서 추가되었다.)
평소의 개발환경이랑 제일 크게 다른 점 중 하나였다. 평소엔 다른 개발자분들이 잘 만든 라이브러리를 사용만 하면 되었지만 이번엔 아니었다.

코드 퀄리티 부분으론 java pmd와 checkstyle을 적용하여서 개발하였는데 다행히 몇 개 잡히지 않았는데 3가지가 가장 기억에 남는다.

첫 번째는 final 키워드이다. checkstyle에서는 파라미터로 넘기는 모든 인자에 final을 붙이도록 하고 있다. 메서드 내부에서 재할당을 못하게 막기 위함으로 알고 있는데 불변성을 유지하기 위한 자바의 코딩 스타일로 알고 있다.

두 번째는 package-info.java 이다. 인텔리제이 자바 프로젝트에서 패키지에 들어가 new로 생성하려 하면 보던 거인데 이게 왜 쓰이나 했는데 주석 작성용 파일인 것 같다.

세 번째는 javadoc 에러 checkstyle error 중 가장 골치 아픈 게 javadoc에러였다. public이면 모든 부분에 javadoc을 달아야 했다. 또한 내부 DTO용 클래스의 필드를 private로 숨겨도 내부 필드에는 달아야 했다. 이게 외부라이브러리를 못쓰는 부분하고 시너지를 만들었는데 내부의 정보를 담고 있는 DTO를 하나 만들었다 가정을 하나 해보겠습니다.

public class anyDTO() {

  // javadoc 두번
  private String name;

  private int age;

  // javadoc 세번
  public String getName() {
    return name;
  }

  public int getAge() {
    return age;
  }
}

필드에 하나 필드에 접근하기 위한 getter에 하나 javadoc 필드 개수 * 2만큼 작성해야 했다.
개발하는 도중엔 굉장히 스트레스받은 부분이다.(똑같은 설명 또 적어야 하는 이 불편함...)
그래도 checkstyle에서 정해놓은 규칙에 다 따라서 하니 결과물은 굉장히 좋았다. 특히 회사 다른 동료분들이 주석이 상세해 보기 편하다는 말을 하였고 내부 소스코드에 접근하기 전 주석만 봐도 어떤 일 하는지
알 수 있어 좋았다 하였다.
추후 업무에서 프로젝트를 열었을 때 주석이 상세히 잘 작성되어있어 고생한 보람은 있었다.

Java와 Kotlin

이제는 Kotlin -> java로 바꾸며 느꼈던 불편한 점에 대해 좀 기술해 보려 한다.
일단 코틀린의 val과 null safety는 정말 소중하단 걸 깨달았다.
.? 의 문법을 이용한 null check는 진짜 코드를 간결하며 null에 안정적이게 만들어준다.
(자바에서 저게 안돼서 정말 코드가 길어졌다. 개발을 하며 java로 못 돌아갈 거 같단 느낌이 든 이유다)

그러나 제일 크게 java와 Kotlin을 사용하며 느낀 점은 코드의 어순의 차이이다.
어떤 말인지 이해가 잘 안 갈 것 같아 이 부분은 코드와 함께 설명하겠다.

먼저 코틀린에는 확장 함수라는 개념이 있다 일명 Extension Function

private fun List<Restaurant>.randomPickOne(): Restaurant = this.shuffled().first()

위의 코드와 같이 클래스를 확장하는 함수를 하나 만들어 선언하여 추가적인 기능을 구현한 코드이다.
그래서 코틀린에서는 다음과 같은 문법이 가능해진다.

kotlin

 fun recommendRestaurant(
 	address: Address
 ): Restaurant {
       // 레스토랑 api 콜해 가져오고 . Random으로 1개를 뽑는다.
      return getRestaurantCallApi(address).randomPickOne() 
   }

java

public Restaurant recommendRestaurant(final Address address){
    // 읽게되면 1개를 뽑는다 . 레스토랑api를 콜한것
    return randomPickOne(getRestaurantCallApi(address))
  }

아래 자바 코드보다 코틀린의 코드가 훨씬 더 보기 좋다 생각된다.
즉 코드가 좀 더 자연어에 가까운 표현력을 가능하게 해 준다.
이 부분이 생각보다 생산성에 영향을 많이 주었다.
코틀린은 정보를 꺼내 쓰는 느낌으로 코딩이 되지만
자바는 결과물을 정해놓고 맞춰가는 식의 코딩을 하게 되었다.

결론은 코틀린이 짱이라는 것이다.

profile
Software Developer

0개의 댓글