대머리개발자

when ?동시에  병렬로 처리 하고 싶을때 -> 사실 API를 더 작은 기능으로 쪼개서 프론트-엔드에서 동시에를 쏘면 되겠다.하지만 관리 포인트도 늘어나는 등 트레이드 오프 관계이기 때문에 서버 사이드도 적절하게 처리 할 수 있어야 한다.  why ?사용자에게 좋은 쾌적한 경험을 주기 위해서지  두 작업이 병렬로 진행하지만 마무의리는 맞춰야 하는 경우와 그렇지 않는 경우가 있다. 예를들어 검색을 한다고 했을 때1. 검색어 저장2. 검색 결과 리턴 검색어 저장은 검색 결과 리턴하는데 영향도가 1도 없기 때문에결과 리턴과 상관없이 각자도생하면 된다. 이력(History)를 쌓는 경우도 동일하게 처리하면 된다.import kotlinx.coroutines.*val scope = CoroutineScope(D..

aop 는 관심사를 횡단으로 보는 것이다.모든 로직은 위에서 아래로 흘러간다. 근데 이것을 옆에서 보자는 것 이쥬. 옆으로 본다는 것에 대한 느낌을 가져야 한다. 위에서 아래로 내려가는 로직에.. 옆에서 갑자기 깜빡이 키고 새치기 해서 자기 할 일 하는 것이다. 암튼 하고자하는 바는 공통의 로직을 필요한 로직에 때려 받기 위함이다. (물론 모든 로직이 될 수도 있고) 예들들어 모든(필요한) 도메인 로직을 태우기 전에 JWT 체크를 하다던지... 로깅을 하다던지... 하는 작업일 때 깜빡이 키고 진행s! 어떤(유**) 회사의 리소스를 본적이 있었는데 ㅎㄷㄷ모든 EndPoint에서 시작하는 3줄의 로직이 무조건 똑같았다. (로깅을 하는 로직) 누군가는 처리 했어야 했는데.. 그니께.. 주식 상장을 해도..아..

애초에 완벽한 요구사항으로 나왔다면 하지만.... 그럴수... 럴수 없기 때문에 늘 확장성을 고민..해야 한다. 뭐 일단 기존 잘 사용하고 있는 기능이고@Get("/product/{style}/count")fun findAllAvailableCount(@Param("style")style: String): Mono userId의 값이 필요한 케이스가 생겼다.@Get("/product/{style}/count")fun findAvailableCount(@Param("style")style: String, @Param("userId")userId: String?): Mono { 해서 추가 @Param을 userId의 물음표로 처리만 하면 될 것 같았는데 기존코드가 안 돌아간다. 아래처럼...Mandatory..

뭐든 명시적으로 그림을 그려야한다. 추상화가 아니라면 사실 고민할 것도 없는 부분이다. ㅠ 게시판에 갑작스 비밀여부에 대한 기능이 필요했다.비밀 여부에 대한 컬럼을 새롭게 파면 아무 문제가 없다.근데 파기가 싫어진다. ㅋㅋ 납득이.. 포인트 라는 컬럼에 묻어서 사용하고 싶다.public boolean isSecretPost(Post post) { return post.getPoint() == -99;}  secret 필드를 두는 것이 혼동을 줄이고 코드의 가독성을 높일 수 있다. 분명하다.!! 당연하다.. 근데 해당 기능의 소비가 그리 많지 않고 간혹 쓴다고 하면 저장소의 낭비가 된다.물론 여기서도  QNA 게시판에서만 사용된다.. -> 운영자에게 비밀글로 문의!s즉, 발생하는 99%로의 데이터가 ..

데이터 모델링(?)을 하는 과정에서 동일한 데이터를 저장하는 것은 누가 봐도 비효율적이다. 예들들어 설문지 관련 개발한다고 하자. 설문지에 응답의 값을 그대로 저장한다고 하면 1~100명의 응답값이야 크게 문제가 없겠지만 1만명 이상의 응답값을 그대로 저장 한다면……. 그래도 뭐 크게 문제는 안 되겠지만 개발자라면..이것은 찝찝해야 한다. 그렇지 않다면 당신은 개발자가 아닐 확률이… 리팩토링 욕구가.. 아니 애초에 이렇게 설계를 하지 않겠다. 긴 문자열 응답 값을 그대로 저장하기 보단. 별도의 테이블로 관리하고 해당 value의 pk만을 저장한다면 좋겠다. 요것이 바로 정규화 과정이다. 조금더 깨끗한 조금더 우아한 코드에 대한 고민을 실력이 뿜뿜!! 단 테이블이 추가되기 때문에 비지니스 로직이.. 상당히..

fun create(targetId: Long, userId:String? = "loginId", ..){ .. } userId가 할당되지 않으면 초기값으로 "loginId"를 바인딩한다. 그럼 당연히 userId는 Null일 수가 없다고 생각하지만 null 값이 바인딩 될 수 있다.!! 그렇기 때문에 비지니스로직에서 userId를 사용할 때는 userId가 명백히 널이 아님을 다시 명시해야 한다. fun create(targetId: Long, userId:String? = "loginId", ..){ .. userId!! ...existByTargetIdAndUserId(targetId, userId, ..) ...updateTargetIdAndUserId(targetId, userId, ..) } ..

자바가 익숙했다면 묻지도 따지지도 않고 작업했던 private 멤버 변수와 getter/setter는 그냥 공식이다. f= ma 무조건하는 이유가 있다. 데이터의 무결성을 보장해 준다. 내부 상세를 숨긴다. (캡슐화) 디테일은 몰라도 남들 다 하니깐! 자바에서의 공식을 코틀린에서는 자동으로 해준다. 🌟👍 But 쓸모가 없다. 자동으로 만들어 지는 두 가지 조건 중 하나가 public 이다. data class BoardDto( public var title: String , ... } 근데 public을 사용하게 되면 어차피 직접 접근이 가능하기 때문에 실상 getter/setter가 필요 없다. 근데 굳이 왜 만들어주는거야? 전혀 쓸모가 없자뇨!! data class BoardDto( private v..

절차지향적으로 진행하면 여러모로 편하다!!! 두말하면 잔소리다. 동시에 복잡하게.. 진행 되면 돌머리인 내가 팔로우 하기가 너무 힘들다 ㅠ 그리고 기본적으로 절차적으로 해결해도 크게 무리 없다. (성능적인 리스크는 있겠지만) 물리적인 파일을 등록하면서 관련 메타 정보를 등록하고 해당 파일을 pdf로 변경하는 로직이 있다고 하자. 100메가 정도의 파워포인트 파일을 pdf로 변경한다면 꽤나 무거운 작업이 될 것이다. (파일을 업로드는 하는 시간 + PDF 변환 시간) 사용자에게도 바로 pdf를 리턴해 주지 않아도 되는 그림이기 때문에 PDF 변경 작업은 천천히 백그라운에서 작업을 하면 된다. 따라서 사용자에겐 파일 업로드만 하고 정상적인 리턴 값을 주면 된다. 각각 병렬로 진행하면 되는 부분이다. 요롤때 ..