Java & Kotlin
-
객체지향적 리팩토링 맛보기Java & Kotlin 2022. 7. 3. 01:40
1) 서론 개발자에게 리팩토링은 피할 수 없는 순간일 것 같습니다. 개인적으로는 리팩토링은 숨 쉬듯이, 업무와 무관하게 이루어져야 하는 것 같기도 한다는 생각이 들기도 하는데요. 당시에는 빠르게 개발하는 것이 목적이었기 때문에 코드에 신경을 쓰지 못할 수도 있습니다. 혹은 기능 추가가 계속해서 이루어지면서, 어쩔 수 없이 정리가 필요한 순간이 올 수도 있을 것 같습니다. 이번 글에서는 임시적으로 추가한 기능이 어느 순간 중요한 기능이 되고, 지속적으로 로직 추가가 발생했던 기능을 리팩토링 한 경험을 공유드립니다. 2) 어떤 내용을 리팩토링 하나요? (모든 내용은 블로그를 위해 가정한 것들입니다. 회사와 무관합니다) 아래의 상황이라고 가정합니다. A, B 애플리케이션이 각각 다른 서버에 존재 A에서 생성된..
-
public, private은 언제 사용해야 할까?Java & Kotlin 2022. 4. 24. 18:19
1) 서론 이번에 작성할 글은 단순히 고민의 흐름을 기록하는 글입니다. 그리고 나름대로 생각을 정리했지만, 결론을 내리지는 않습니다. 오히려 같은 고민을 하는 분들의 댓글을 기다리는 글입니다. 이 글에서 이루어지는 고민은 "public과 priavte은 언제 어떻게 사용해야 할까?"입니다. 특정 기능을 개발하는데, 습관적으로 모든 함수를 private으로 작성하고 있는 제 자신을 발견했습니다. 그러다 보니 모든 기능의 테스트를 할 수 없었는데요. 이러한 방식이"정말로 이게 맞을까?"라는 의문으로 시작된 고민입니다. 2) 기본적인 public, private 개념의 차이 대부분의 언어에서 public, private 개념과 사용법은 비슷할 것입니다. 이 글에서는 Kotlin을 예제로 사용합니다. publi..
-
Optional 아무렇게나 사용하고, 장애 발생시킨 이야기Java & Kotlin 2022. 3. 15. 01:09
1) 서론 당연한 것이라고 생각하며 한 번도 의심해보지 않은 것이, 사실은 아니었던 경험이 있으신가요? 저는 TV에서 나오는 맞춤법 퀴즈를 볼 때 종종 "이게 정답이라고?" 라는 생각을 하기도 하는데요. 최근 개발을 하던 중 사용한 Java의 Optional이 저에게는 그런 존재입니다. Java8의 시대부터, 아마도 자바 개발자에게 Optional의 사용은 필수가 됐을 것 같습니다. 저는 NPE를 방지하기 위해서, 습관적으로 사용하곤 했었는데요. 이러한 Optional을 무분별하게 사용하다가, 시원하게 장애를 발생시킨 경험입니다. 2) 상황 설명 값을 조회합니다 값이 있다면, Exception 발생합니다. Post 테이블의 title이 'title'인것을 조회합니다. 데이터는 존재하지 않습니다. 앞서 '..
-
착한 가로채기, InterruptedExceptionJava & Kotlin 2022. 2. 21. 03:16
1) 서론 JVM은 Java 언어가 어떠한 운영체제와도 동작할 수 있도록 도와주는 가상 머신입니다. 기계어로 바로 변환되는 C언어와 다르게, byte code로 변환 후 필요시 native code로 변환하고 읽는데요. "Write once, Run anywhere"라는 자바 언어를 만들던 당시의 철학을 떠올려보면, 당연한 동작 방식 입니다. JVM은 단순히 코드를 변환해주는 역할만 하지 않습니다. 운영체제 위해서 애플리케이션과 메모리를 관리하는 역할도 하는데요. 특히 프로세스, 스레드 관리를 매우 철저하게 해 줍니다. GC와 같이 사용되지 않지만, 메모리에 올라와있는 코드를 정리해주기도 합니다. 특히 스레드가 deadlock에 빠졌을 때 JVM은 그냥 두고만 보지 않는데요. 이때 발생할 수 있는 Int..
-
[Intellij] Google Java auto-formatting 적용Java & Kotlin 2022. 2. 7. 01:06
1) 서론 여러 사람이 함께 코드를 작성할 때는 다양한 스타일의 코드가 작성됩니다. 같은 목적의 코드라도, 개개인의 스타일은 다를 수밖에 없는데요. 만약 큰 회사 혹은 조직이라면 통일된 코드 스타일을 만들수도 있을 것입니다. 하지만 작은 조직에서는 체계적인 코딩 스타일을 정의하는 것이 쉽지 않을 것입니다. 통일된 코딩 스타일을 정의하는데 시간을 투자하는것 보다, 빠르게 개발해서 비즈니스에 반영하는 것이 우선이라는 이유도 있을 것 같은데요. 그래서 이번에는 인텔리제이와 구글 스타일 가이드를 이용해서, 완벽하지는 않지만 손쉽게 코딩 스타일을 통일시킬 수 있는 방법을 기록합니다. 2) 구글 자바 스타일 가이드 적용 방법 https://github.com/google/styleguide (구글 스타일 가이드 저..
-
Stream은 일회용품이다.Java & Kotlin 2021. 12. 12. 23:16
1. 서론 코딩, 프로그래밍을 하는 데에는 각자의 취향이 분명 있을 것입니다. 하지만 무엇이 옳다고 말할 수는 없는데요. 다양한 프로그래밍 방식 중 저는 무엇인가를 조회할 때 각각 변수에 담아, 다시 사용하는 것을 좋아합니다. JPA에서 사용되는 쿼리 메서드를 예로 들겠습니다. 누군가는 애초에 변수 b만 들어서, a의 내용을 join으로 한 번에 가지고 오기도 합니다. 혹은 변수 자체를 만들지 않고, 바로 return에 조회하는 메서드를 사용하기도 합니다. 하지만 저는 세번째와 같이 변수에 하나하나 담아, return 하는 방식을 선호하는데요. 이유는 각각의 의도를 가진 변수명을 사용해서, 어떤 목적을 가지고 있는지 명확히 알 수 있습니다. 또한 어떤 부분에서 에러가 발생하는지 명확히 파악할 수도 있습니..
-
그래서 예외처리는요?Java & Kotlin 2021. 12. 5. 05:30
1) 서론 개발자로서 취업 후 가장 많이 배우는 것 중 하나는 예외처리일 것 같습니다. 혼자서 개발할 때는 모든 상황의 예외를 파악할 수 있습니다. "이 부분에서는 절대로 에러가 나지 않는다"라는 확신이 들기도 합니다. 왜냐하면 혼자서 정해진대로 테스트를 진행하기 때문에, 예상 가능한 문제만 발생합니다. 하지만 실제 업무에서는 절대로 예상할 수 없습니다. 당연히 들어와야 하는 파라미터가, 그냥 안 들어오는 경우도 있습니다. 사용자는 정해진대로 움직이지 않고, 복잡한 시스템은 항상 예기치 못 한 에러를 만들어냅니다. 당연히 있어야 할 것이, 당연히 없는 경우가 대부분입니다. 신입으로서 코드를 작성할 때 가장 많이 들은 질문입니다. "그래서 예외처리는요?" 2) 고작 파라미터 받는데요? 이번 글에서는 흔하게..
-
@Async, 생각보다 까다롭다.Java & Kotlin 2021. 11. 1. 00:53
1) 서론 요즘 @Async를 어느 때보다 많이 사용하고 있습니다. 사실 그동안 간단하게 애노테이션과 thread pool 설정만 하면 된다고 생각했습니다. 하지만 실제로 사용할 때 예상하는 것과 다른 흐름으로 동작하고, 은근히 까다롭다는 것을 느꼈습니다. 제가 사용하며 만난 문제점과 해결 과정을 기록합니다. 2) 문제의 코드 전체적인 콘셉트는 간단합니다. 파싱 해온 데이터를 원하는 방향으로 가공합니다. 이때 이름, 가격을 나눠서 가공하고 비동기 처리합니다. public class MainClas { public void trimAndAddWines(List names, List prices) { log.info("\n === trimAndAddWines() 시작 ==="); // @Async wineN..