엔지니어로 가는 길

여유롭지 않으므로 의식의 흐름대로 작성하고 나중에 수정하기로 한다. 사용자에게 알려야 하는 특정 이벤트가 발생하면 문자, 알림톡, 앱 push 등의 수단을 이용하여 사용자에게 해당 이벤트가 발생했음을 비동기적으로 알린다. 사용자에게 알림을 보낼 때 관련 알림 서비스의 이슈로 인해 알림을 보내는 데 실패할 수 있다. 예를 들면, 특정 클라우드의 문자 발송 서비스를 이용하고 있을 경우 우리 서비스가 아닌 해당 클라우드와 관련한 이슈로 인해 알림을 발송하는 데 실패할 수 있다. 이러한 예외는 얼마든 발생할 수 있고, 재발송을 시도하면 되기 때문에 예외에 대한 처리도 명확하다. 또한 알림은 핵심 로직이 아니기 때문에 알림이 실패했다고 해서 이후에 있는 작업이 진행되지 않는 것도 적절하지 않다. 이러한 이유로 알..

최근에 지인에게 예외가 뭐냐는 질문을 받았다. 코드에서 예외를 다루는 건 익숙한데 예외에 대해 설명하려니 긴가민가한 부분이 있었다. ‘예외랑 에러랑 어떻게 다르더라? 예외는 이름에서 알 수 있듯 예외적인 상황과 관련이 있는데, 어디선가 예외도 정상 플로우라고 들었던 것 같은데 핸들링하고 있는 예외는 정상 플로우로 보는 거였나?’ 아래의 글에서 토비의 스프링을 읽으며 Checked exception과 Unchecked exception에 대해 간략히 정리한 적이 있는데, 이번에는 오라클 문서를 읽으며 예외가 무엇인지 기본 개념에 대해 정리해보려고 한다. JAVA Error와 Checked/Unchecked Exception Error java.lang.Error 클래스의 서브 클래스들이 해당된다. 에러는 ..

코세라에 있는 Kotlin for Java Developers를 들으며 정리한 내용이다. Table of contents 1. Hello world example 2. Variables 3. Functions 4. Control Structures 5. Exceptions "Hello, world" example 간단한 예제를 통해 코틀린의 특징을 살펴보자. fun main(args: Array) { val name = if (args.size > 0) args[0] else "Kotlin" println("Hello, $name!") } - 세미콜론이 필요없다. - 함수는 `fun`을 이용하여 정의한다. - 함수가 top level(package level)에 존재할 수 있다. - 인자가 없는 메인 함..

클린 코드에서 하나의 함수는 하나의 행동만 해야한다고 했다. 글도 마찬가지인 것 같다. 하나의 글에서는 하나의 주제만을 다루어야 한다. 최근에 글쓰기가 어렵게 느껴진 이유가 바로 주제를 확실히 정하지 않고 무작정 글을 쓰려고 했기 때문인 것 같다. 주제를 정하지 않았으니 글을 쓰다가 '이걸 주제로 할까?', '아 이걸 주제로 할까?', 왔다갔다 하면서 엉망이 되는 것이다. 코딩테스트 문제를 풀 때 풀이를 떠올리지 않고 손이 가는대로 풀다보면 엉망진창이 되듯, 글도 먼저 생각하지 않고 마구잡이로 써가다보면 글이 아니라 그냥 낙서가 되는 것 같다. 앞으로 글을 쓸 때는 그 글에서 무슨 말을 하고 싶은지, 분명하고도 간결한 하나의 주제를 정하고 글을 써야겠다.

코세라에 있는 Kotlin for Java Developers를 들으며 정리한 내용이다. 강의 소개 및 특징 - 코틀린을 배우고 싶은 자바 개발자를 위한 강의 - Kotlin/JVM(Server & Android) 플랫폼에 대해서만 다룸 - 자바와 비교했을 때 코틀린이 어떤 점이 새롭고, 어떤 점이 다른지에 초점을 맞춤 - 영어 강의 What is Kotlin? - general-purpose, FP + OOP 코틀린은 함수형 프로그래밍과 객체지향 프로그래밍을 모두 지원하는 general-purpose 언어이다. - open source JetBrains에 의해 개발된 오픈 소스 프로젝트이다. - statically typed language 자바와 마찬가지로 statically typed 언어이나 코틀..

오늘 / 당장 중요한 것 / 변할 수 있는 것 / 실용적인 것 대세 프레임워크는 시간이 흐름에 따라 얼마든지 바뀔 수 있다. 프레임워크의 사용법에 매몰되어 검색 없이 원하는 것을 바로바로 머릿속에서 꺼내 구현할 수 있도록 익히기만 한다면 당장의 생산성은 올라가겠지만, 미래의 생산성까지 보장되지는 않는다. (예를 들어, 대세 프레임워크가 바뀌게 되면 새로운 프레임워크를 익히는 데 많은 시간이 필요할 것이다. 프레임워크의 원리와 구현에 대해 알아야 해결할 수 있는 복잡하고 어려운 문제를 만나면 해결하는데 많은 시간이 필요할 것이다.) 내일 / 당장 중요하지는 않은 것 / 변하지 않는 것 / 원론적인 것 프레임워크가 풀고자 하는 문제는 시간이 지난다고 사라지지는 않는다. 새로운 프레임워크가 자신만의 방식으로 ..

클린 코드에 쌓인 먼지를 털어낸 뒤 다시 읽기 시작했다. 저자가 서문에서 이 책은 가볍게 읽을 책이 아니고 앞으로 갔다가 뒤로 갔다가 하면서, 많은 노력을 들여 코드를 최대한 이해하려고 해야 한다고 신신당부했다. 그렇게 읽어보려고 한다. 90p에 보면 GeneratePrimes 클래스가 나쁜 버전으로 주어지고, 이를 리팩터링 한 결과를 다음 페이지에 보여주고 있다. 그냥 보는 것보다는 나라면 어떻게 고칠지 생각해보고, 실제로 고쳐보고, 정답(?)과 비교해보는 게 더 좋을 것 같아서 한 번 리팩터링을 해보았다. 먼저 나쁜 버전 원본이다. public class GeneratePrimes { public static int[] generatePrimes(int maxValue) { if (maxValue >..

버전 충돌이란 하나의 dependency 그래프 내에 같은 라이브러리의 버전이 두 개 이상 존재하는 것을 말한다. 빌드툴은 버전 충돌을 해결해야 하며, 빌드툴마다 다른 버전 충돌 해결 전략을 가질 수 있다. 가장 대표적인 빌드툴에 해당하는 메이븐과 그래들은 버전 충돌 해결 전략이 다르다. 이 글에서는 버전 충돌이 무엇인지, 메이븐과 그래들에서는 각각 버전 충돌을 어떻게 해결하는지에 대해 알아본다. 참고) 메이븐에서는 버전 충돌 해결 프로세스를 dependency mediation, 그래들에서는 version conflict resolution이라고 부른다. The concepts of version resolution Version resolution란 unresolved dependency 그래프를 입..

Spring boot 2.0을 사용 중인 프로젝트의 버전을 최신 버전으로 올려보려고 한다. 간단한 일은 아니겠지만 불가능한 일도 아니다. 수많은 문제를 끊임없이 만나게 될 텐데, 문제를 만나서 해결하거나 또는 해결하지 못했다면 왜 해결하지 못했는지, 어디서 막혔는지를 잘 정리할 것이다. 최신 버전의 Spring boot를 사용하게 된다는 것은 결과이다. 어쩔 수 없는 이유로 당장 최신 버전을 사용하지 못할 수도 있다. 결과는 어쩔 수 없는 영역인데, 결과에 너무 집중하면 원하는 결과가 나오지 않았을 때 실망하게 된다. 이 일을 할 때는 Spring boot의 버전별 차이와 빌드툴에 대해 배우는 것을 목적으로 접근하려고 한다. 최신 버전을 사용할 수 있게 된다면 좋은 일이고, 그렇게 되지 않더라도 어디서 ..

기존 프로젝트에서 사용하고 있던 라이브러리나 프레임워크의 버전을 바꾸는 것은 간단한 일이 아니다. 하지만 JUnit5로 마이그레이션 하는 것은 예외인 것 같다. JUnit 4와 JUnit 5는 함께일 수 있다 https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4 JUnit 5 User Guide Although the JUnit Jupiter programming model and extension model do not support JUnit 4 features such as Rules and Runners natively, it is not expected that source code maintainers will need..